uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: uima.runtime layout vs ruta.engine layout
Date Tue, 03 Sep 2013 15:26:34 GMT
On 03.09.2013 16:58, Marshall Schor wrote:
> On 9/2/2013 1:17 PM, Peter Klügl wrote:
>> Hi,
>> I had a hard time to adapt the ruta.engine bundle to the new layout,
>> which we use in the runtime plugin.
>> Can someone explain to me the import section in the manifest of the
>> runtime plugin? Why doesn't that cause problems either when starting
>> eclipse or when building it with maven?
> hmmm, let's see how much I can remember :-)
> The bundle plugin can do 2 different things: 1) prepare a manifest, and 2) add
> things to the target/classes to be JARed up (at a later time, perhaps, if the
> packaging type for the POM is "Jar".
> The POM could say the packaging type is "bundle", but we use "jar" - this keeps
> the bundle plugin from doing the Jar, and allows the mvn Jar plugin to do that
> (which, in turn, allows us to follow the apache conventions for what goes into a
> Jar).
> The bundle plugin is typically driven by "export-package" statements.  These
> these get added to the manifest *and* are added to the bundle's Jar.  Except,
> since we're not using the bundle package, this 2nd step does something slightly
> different - it adds (if not already present) the package to the target/classes
> (to be eventually added to the Jar in a later Maven step).  What gets added
> includes whatever can be found with that package name in the sources
> (non-existent for runtime-plugins) and the dependency jars.
> However, for the runtime plugin, we don't want to add classes individually; we
> want to include entire sub-jars in our to-be-built-Jar.
> To support this, the bundle plugin has two instructions.
> 1) replace <Export-Package> with <_exportcontents>.  This does exactly the
> thing as Export-Package for the manifest, but doesn't do any actions re: copying
> dependencies into the target/classes spot.
> 2) add an <Embed-Dependency> statement - This does 2 things:  for each
> dependency, it (a) copies the Jar into the target/classes, at some "path" - we
> use "" as the path - so these jars are copied directly into target/classes, and
> will be zipped up by the subsequent mvn jar plugin.
> The 2nd thing it does is it adds to the manifest a Bundle-Classpath element,
> specifying all the jars that got embedded, with the right "path" inside the
> enclosing Jar.

I am quite sure that this does not work if you launch an eclipse (Ruta
Workbench) with Eclipse 3.7.2. I tried a lot, but the current trunk
works now only with newer eclipse installations.

> This latter thing is what allows Eclipse to find the packages inside the bundle
> inside the inner Jars.
> With this approach, no "import-package" statements are used, unless you need to
> specify some non-default kind of resolution, or "negate" some part of the
> import.  Without import-package statements, the default is to import all
> dependent packages. 
> So, I would try: replace import-package with _exportcontents, and add the Embed
> Dependencies element
> Does that work for you?  If not, please describe what's not working.  See the
> uimaj-ep-runtime pom for an example of this.

Yes, I looked at uimaj-ep-runtime and adapted ruta-ep-engine.

I do not know if I can summarize all problems :-(

I think the main difference is that runtime does not have any real
dependencies, but engine has. Therefore, the generated import section in
the engine manifest contains really many packages. I really wonder about
a few ones like groovy.lang, org.jruby, ... These imports are of course
not resolved when I start eclipse with the bundle. If I restrict the
imports to only those I need, then the bundle plugin complains and stops
with an error.

The only solution I found was to specify the import section like that
one in my last mail: import the stuff I need (uima) and exclude every
other namespace that would have been added to the section.

Well, it works now, but I am still a bit upset about how the bundle
plugin handles the import section and wonder why, e.g., the runtime
plugin needs an import section (in the manifest) at all.



> -Marshall
>> I got my plugin to work, but do not really know why. I had to added
>> something like the following to the maven-bundle-plugin:
>>  <Import-Package>
>>    org.apache.uima.*,
>>    !antlr, !bsh, !com.jamonapi, !com.sun.net.httpserver,
>>    !edu.emory.mathcs.backport.java.util.concurrent,
>>    !groovy.lang, !javax.annotation, !javax.ejb,
>>    !javax.el, !javax.inject,
>>    !javax.interceptor, !javax.jms,
>>    !javax.management, !javax.management.modelmbean,
>> !javax.management.openmbean,
>>    !javax.management.remote,
>>    !javax.naming, !javax.persistence.spi, !javax.rmi, !javax.servlet,
>>    !javax.swing, !javax.swing.border,
>>    !javax.swing.event, !javax.swing.text, !javax.swing.tree,
>> !javax.validation,
>>    !javax.validation.bootstrap,
>>    !javax.validation.metadata, !javax.xml.namespace,
>>    !javax.xml.parsers, !javax.xml.stream,
>>    !javax.xml.stream.events, !javax.xml.stream.util,
>>    !javax.xml.transform, !javax.xml.transform.sax,
>>    !javax.xml.transform.stax,
>>    !javax.xml.ws, !joptsimple, !net.sf.cglib.*, !net.sf.ehcache.*,
>>    !org.antlr.stringtemplate,
>>    !org.apache.avalon.framework.logger,
>>    !org.apache.commons.pool,
>>    !org.apache.commons.pool.impl,
>>    !org.apache.log, !org.apache.log4j, !org.apache.log4j.xml,
>>    !org.aspectj.*, !org.codehaus.groovy.*, !org.hibernate.* ,
>>    !org.joda.*, !org.jruby.*, !org.omg.CORBA,
>>    !org.springframework.instrument,
>>    !org.w3c.dom, !org.xml.sax, !org.xml.sax.ext, !org.xml.sax.helpers
>>  </Import-Package>
>> Best,
>> Peter

View raw message