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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >
