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 Wed, 04 Sep 2013 19:23:08 GMT

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?
>
> 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>
Here's why:

The operation you're doing is packaging some non-OSGi "modules" as OSGi bundles.

When you do that, you take a plain Jar, let's say commons-logging, and declare
that it's entire contents are being added to the bundle.  These contents (you
can sort of see from the pom for this) include classes which depend on
org.apache.avalon.... things.

Now, you're particular use of that Jar doesn't call any methods which, in turn,
would end up referencing classes in ..avalon..  So, to shrink the size of the
ruta-ep-engine, you don't specify <Embed-Transitive>true</Embed-Transitive>
(which might have otherwise embedded a whole lot of other things), and you
depend on knowning what sub-parts of these Jars you're using, and taking the
responsibility to insure any needed dependencies you explicitly include.

Maven tries to support this kind of use case via two elements in the dependency
element: the <optional> and the <excludeDependencies>.  But I'm guessing that
the maven bundle plugin ignores these when computing what a bundle might need to
import - it needs to import everything it references, but doesn't define.

So, including commons-logging results in an import of the avalon package.  This
isn't (yet) a problem... it just marks the ruta-ep-engine as needing this
resolved when it is loaded.

So the problem happens at load time, because there is (at least in my test
system) no bundle that exports the avalon package.  So the ruta-ep-bundle can't
be resolved by the OSGi loading mechanism.  When I took out all the import
blockers, the test of workbench gave a long list of non-resolved packages. 
Those are (I assume) what led you to put negated imports to block them.

This is all an artifact of how the original functions you included by including
the jar were packaged together - some you wanted, others are just there.  And
the bundle plugin doesn't seem to know how to tell which ones you don't need,
automatically - so you have to explicitly tell it.

-Marshall

>
> Best,
>
> Peter
>


Mime
View raw message