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 >
