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 16:34:00 GMT
On 03.09.2013 18:09, Marshall Schor wrote:
> 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
>>> 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.

Have you used the sources of the runtime plugin or an installed version?
Or have you build it and put it in the dropins folder?

> 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...

Testing is greatly appreciated :-)

It's already in the trunk.
Here's what I normally do when I test the Ruta Workbench:
- use eclipse 3.7.2 with subclipse, m2e with connectors
- install uima tooling and dltk 3.0 (eclipse update site)
- checkout sandbox/ruta/trunk as maven project
- mvn clean install on ruta project
- select ruta-ep-ide -> run as eclipse application
- this will probably fail, increase the permgen space in the launch
configuration that was created: add "-XX:PermSize=64M
-XX:MaxPermSize=128M" to the vm args
- launch eclipse again
- switch to the UIMA Ruta perspective
- right click in the script explorer and create a new UIMA Ruta project,
e.g. Test
- right click on the script folder and create a new UIMA Ruta script
file, e.g. Test
- fill the script file, e.g., with "W;"

-> problems should occur here, at latest, because antlr cannot be found
for parsing the script file. Normally, the CharStream class is not found.

- create a new txt file with some words in the input folder
- select the open editor of the script file
- press the debug button (launch debug config)
- open the xmi file in the output folder
- switch to the UIMA Ruta Explain perspective
- take a look at the Applied Rules view, this view should contain some
rule matches



> -Marshall
>>> 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
>>> 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