uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: uimaFIT's TSD detection and jar bundles
Date Fri, 25 Oct 2013 16:41:15 GMT
As far as I know, there is currently no way to use uimaFIT type
system detection with fat jars build with Maven assemblies due
to the issues you describe. However, this not only applies to
uimaFIT, but also to other software with is designed in a similar
way, e.g. the Java Service Loader mechanism [1].

Afaik there are approaches which let you build a fat JAR with a custom
classloader which is loading from JARs embedded in the fat JAR [2]. I
didn't try them.

Another alternative that I have used already is, to have an assembly which
sets up a small "distribution" that comes with all the libraries in a
"lib" folder and an Ant script which serves as a bootloader.

Consider this a bug/problem with Maven assemblies, not with uimaFIT, since
placing well-known files in well-known locations is a usual habit (see also
OSGi bundles, the standard Java manifest files, etc. etc.).


-- Richard

[1] http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html
[2] http://sonatype.github.io/jarjar-maven-plugin/

On 25.10.2013, at 18:31, Mog <mog@crydee.eu> wrote:

> A common way to package java applications is to use maven and its
> assembly plugin [1] to provide ready-to-use bundles to users.
> The uimaFIT standard way to declare type system descriptions (TSD) is to
> provide it with a file types.xml in the META-INF/org.apache.uima.fit
> directory that contains patterns of TSD locations [2].
> A problem arises when one tries to bundle several uimaFIT components
> that use this mechanism, because the
> /META-INF/org.apache.uima.fit/types.xml files will be overwritten by the
> last component's types.xml file.
> I'm aware of some workarounds to this problem, eg if you only have one
> uimaFIT dependency and want to provide your own patterns additionnally
> to the ones of the dependency, you can add them as system property with
> -Dorg.apache.uima.fit.type.import_pattern=classpath*:my/pattern/*.xml.
> However, I am not sure how I would proceed to include two or more
> components that use this mechanism and my own uimaFIT project, since one
> of the two components would have an overwritten types.xml file and the
> system property trick would not work anymore.
> I guess one way to fix this issue would be to give more freedom to
> components regarding where to put the types.xml file, for example,
> instead of the pattern META-INF/org.apache.uima.fit/types.txt, we could
> use META-INF/org.apache.uima.fit/**/types.txt so that a separation by
> package would be possible.
> If there is already a standard and usable way to circumvent this
> problem, please let me know :)
> Cheers and thanks to the community for this great framework,
> Hugo Mougard
> [1] https://maven.apache.org/plugins/maven-assembly-plugin/
> [2]
> https://uima.apache.org/d/uimafit-current/tools.uimafit.book.html#ugr.tools.uimafit.typesystem

View raw message