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 12:04:57 GMT
Hmm, cannot reproduce it.

Here's what I did:

- mvn clean package the update site in Eclipse 3.7.2
- installed the feature in another Eclipse 3.7.2 that already contains
uima-tooling (was 2.4.1, but I do not think that makes a difference)
- created project, created script file, created test file, launched
debug, checked rule matches

In your case, there was no exception? The line in the ruta code is:

XMLInputSource in = new XMLInputSource(descriptorUrl);

Best,

Peter


On 04.09.2013 13:41, Peter Klügl wrote:
> 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.
>
>
> Peter
>
>> -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
>>>>>> 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
>>>
>>> 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 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
>>>>>>>


Mime
View raw message