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
>>>
>
|