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 Thu, 05 Sep 2013 10:39:25 GMT
Thanks, that filled the remaining gaps.


On 04.09.2013 21:23, 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?
>> 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
> 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

View raw message