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 Wed, 04 Sep 2013 11:41:07 GMT
On 04.09.2013 04:51, Marshall Schor wrote:
> Hi,
> 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).

My initial concern was that it works when installed but not when started
using the sources.

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

What is the structure of your Ruta project? Is the script you launched
within a source (script) folder?

The message surprises me a bit. Was there an xmi file in the output
folder? Maybe there was an exception and eclipse tried to jump to the
position, but couldn't find the sources.

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

Nope, it should - of course - work without any problems. I will try to
reproduce it ASAP.


> -Marshall
> 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) 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 get added to the manifest *and* are added to the bundle's Jar.
>>>>> since we're not using the bundle package, this 2nd step does something
>>>>> 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
>>>>> 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: copying
>>>>> dependencies into the target/classes spot.
>>>>> 2) add an <Embed-Dependency> statement - This does 2 things:  for
>>>>> 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
>>>>> 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
>>> 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 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
>>>>> import.  Without import-package statements, the default is to import
>>>>> 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