uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mog <...@crydee.eu>
Subject Re: uimaFIT's TSD detection and jar bundles
Date Sat, 26 Oct 2013 08:56:18 GMT
Thank you Richard for this very fast reply.

I am not used to OSGi bundles, but for the Java manifest files, it
_seemed_ to me (I emphasize seem because I am not a Java professional in
any way) that the manifest main purpose was to describe the fat jar and
was of no use to dependencies (with information such as which main class
to run and version informations and the class-path bits not relevant in
a fat jar setting). Even if this assumption is wrong (and it certainly
is), my previous point was mainly that since uimaFIT already advises to
correctly package TSDs to avoid clashes, it would be coherent to package
TSD pointers if the ability to locate them remained untouched.

Many thanks for the pointers to One-Jar, it seems to be a promising
solution indeed.

Hugo Mougard

On 10/25/2013 06:43 PM, Richard Eckart de Castilho wrote:
> 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

View raw message