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 02:51:42 GMT

Here's a fundamental question / confusion I'm having.

It looks like the ruta-ep-engine is a collection of plain Jars packaged up as
one big OSGi bundle exporting a bunch of packages needed by Ruta. The reason
this packaging is needed is to turn these non-OSGi Jars into (one) OSGi Bundle
(Jar), so that Eclipse bundle resolution mechanism can knit these together with
other dependencies other OSGi plugins might need.

Since the uimaj-ep-runtime Jar is already an Eclipse / OSGi bundle, I think
there's no reason to embed it.  It will just be another exporter of packages
that other bundles can "import". 

I ran the build the way it is currently set up (without uimaj-ep-runtime being
embedded), and I also ran the ruta-eclipse-update-site build so I could really
install the result.

Then I used the resulting update site to install ruta into a 3.7.2 Eclipse with
UIMA 2.4.2 Eclipse tools (including the uimaj-ep-runtime).

It appeared to install OK, and I tried to follow your instructions for testing. 
This seemed to work, no obvious errors, but when I tried to run, I may not have
set things up right because I got:

a connect window with a message "Source not found for
FileURLConnection.connect() line: 101"
and a stack trace in the console:
FileURLConnection.connect() line: 101 [local variables unavailable]
FileURLConnection.getInputStream() line: 189
XMLInputSource.<init>(URL) line: 120
Ruta.wrapAnalysisEngine(URL, String, boolean String) line: 96
RutaLauncher.main(String[]) line: 119

What did I do wrong?

Anyways, no obvious mis-linkages; Is this what you expect from running as an
installed plugin (not in Eclipse App Debug mode)?



On 9/3/2013 12:34 PM, Peter Klügl wrote:
> 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)
>>>> things to the target/classes to be JARed up (at a later time, perhaps, if
>>>> packaging type for the POM is "Jar".
>>>> The POM could say the packaging type is "bundle", but we use "jar" - this
>>>> the bundle plugin from doing the Jar, and allows the mvn Jar plugin to do
>>>> (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;
>>>> 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:
>>>> 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,
>>>> 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
> Best,
> Peter
>> -Marshall
>>>> This latter thing is what allows Eclipse to find the packages inside the
>>>> 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
>>>> Dependencies element
>>>> Does that work for you?  If not, please describe what's not working.  See
>>>> 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