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 14:34:33 GMT
On 04.09.2013 16:10, Marshall Schor wrote:
> I found the problem:  When I got to the step:
> - right click on the script folder and create a new UIMA Ruta script file, e.g. Test
> I must have right clicked on the folder, and created used the menu pick "new
> file", instead of "new UIMA Ruta file". 
> I tried again, and can get it to run.
> So, now back to the original problem - I'll have a look at getting it to run as
> an Eclipse Application without installing it from Eclipse - that's the issue,
> correct?

Yes, I think that eclipse 3.7.2 (or m2e) cannot resolve the inlined jars
in development mode.


> -Marshall
> On 9/4/2013 8:04 AM, Peter Klügl wrote:
>> 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
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>>>>>>> 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
>>>>>>> Workbench) with Eclipse 3.7.2. I tried a lot, but the current
>>>>>>> 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
>>>>> 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
>>>>>>> dependencies, but engine has. Therefore, the generated import
section in
>>>>>>> the engine manifest contains really many packages. I really wonder
>>>>>>> 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
>>>>>>> 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
>>>>>>> one in my last mail: import the stuff I need (uima) and exclude
>>>>>>> other namespace that would have been added to the section.
>>>>>>> Well, it works now, but I am still a bit upset about how the
>>>>>>> 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.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