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 14:10:45 GMT
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,


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 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
>>>>>>>> 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.  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
>>>>>>> (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
>>>>>>> (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,
>>>>>>> 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 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
>>>>> 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
>>>>> 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
>>>>>> the engine manifest contains really many packages. I really wonder
>>>>>> a few ones like groovy.lang, org.jruby, ... These imports are of
>>>>>> not resolved when I start eclipse with the bundle. If I restrict
>>>>>> imports to only those I need, then the bundle plugin complains and
>>>>>> 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 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