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:43:45 GMT
JarJar may not be the one I meant to mention hereā€¦ probably it was One-Jar [3]

-- Richard

[3] http://www.ibm.com/developerworks/library/j-onejar/

On 25.10.2013, at 18:41, Richard Eckart de Castilho <rec@apache.org> wrote:

> 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.).
> 
> Cheers,
> 
> -- 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
> 


Mime
View raw message