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 15:54:39 GMT
I found the previous investigation in the comments to uima-2560.

I can confirm that when running with the ruta-ep-engine built with embedded jars
approach, that this doesn't work for 3.7.2.  I think what happens is the launch
configuration puts the target/classes folder into the bundle classpath, and the
bundle classpath loader is missing the facility to work with embedded jars
there.  This is fixed in later Eclipse releases.

As the comment in uima-2560, this is even extended in 4.2 (?) versions of
Eclipse to work even if the Jars aren't in the target/classes, using some new
kinds of manifest instruction which specifies where to get the jars from maven.

I also found that if I copied just the ruta-ep-engine's built Jar file (with
embedded Jars) into Eclipse's "dropins" folder and restarted, and then changed
the Eclipse Application "launch" configuration to (a) launch with plug-ins
selected below only, and then *unchecked* in the "Workspace" section the
ruta-ep-engine, and *checked* in the Target Platform section the
org.apache.uima.ruta.engine, which causes the Jar to be used, then the launcher
worked find in 3.7.2.

-Marshall



On 9/4/2013 11:23 AM, Marshall Schor wrote:
> never mind- found it via doing mvn dependency:tree.
>
> mvn dependency:analyze reports warnings; I don't know if these are OK or not...
>
> [INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ ruta-ep-ide ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]    org.eclipse.equinox:registry:jar:3.5.101:provided
> [WARNING]    org.eclipse:jface:jar:3.7.0:provided
> [WARNING]    org.eclipse.ui:workbench:jar:3.7.1:provided
> [WARNING]    org.eclipse:osgi:jar:3.7.2:provided
> [WARNING]    org.eclipse.equinox:common:jar:3.6.0:provided
> [WARNING]    org.apache.uima:uimaj-core:jar:2.4.2:compile
> [WARNING]    org.antlr:antlr-runtime:jar:3.5:compile
> [WARNING] Unused declared dependencies found:
> [WARNING]    org.eclipse.dltk.validators:core:jar:3.0.0:provided
> [WARNING]    org.eclipse:ui:jar:3.7.0:provided
> [WARNING]    org.eclipse.swt:org.eclipse.swt.win32.win32.x86:jar:3.2.1:provided
> [WARNING]    org.eclipse.equinox:app:jar:1.3.100:provided
> [WARNING]    org.eclipse.emf.ecore:xmi:jar:2.7.0:provided
> [WARNING]    org.eclipse.jdt:launching:jar:3.6.1:provided
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
>
> On 9/4/2013 11:15 AM, Marshall Schor wrote:
>> ok, working on trying to understand the 1st class-not-found - the antlr char
>> stream one.
>> (I got that when I tried to run.)
>>
>> I see that comes from trying to load the RutaSourceParser java class, which has
>> references to org.antlr.runtime things, including CharStream.
>>
>> In the Eclipse source for that project (ruta-ep-ide), I thought I would see a
>> dependency on org.antlr.runtime in the dependencies section - but it's commented
>> out.
>>
>> I don't see how this dependency is being put on the build path (it is on the
>> build path, I checked).  Can you enlighten me on this?
>>
>> -Marshall
>> On 9/4/2013 10:34 AM, Peter Klügl wrote:
>>> 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.
>>>
>>> Peter
>>>
>>>> -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 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