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 Sun, 27 Oct 2013 14:50:59 GMT
I opened an issue for this:

https://issues.apache.org/jira/browse/UIMA-3385

I still don't think its an uimaFIT issue, but it's certainly an
issue to users of uimaFIT. So it may be wise to address this as
long as it doesn't hurt.

-- Richard

On 26.10.2013, at 10:56, Mog <mog@crydee.eu> wrote:

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


Mime
View raw message