uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: uima.runtime layout vs ruta.engine layout
Date Tue, 03 Sep 2013 16:09:41 GMT

On 9/3/2013 11:26 AM, Peter Klügl wrote:
> 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 same
>> 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.
 I tested 3.7.2 eclipse with 2.4.2 uima, and that worked OK.  So I think this
approach does work.

If you can make an SVN branch with this kind of approach, I'll offer to check it
out, build it, and then (with some guidance from you :-) ) run some simple tests
that you think will show the "problem", and have a look...

>> 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.
> Best,
> Peter
>> -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