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 18:10:41 GMT
It's sad. I hoped you find something I missed.

I already switched to Eclipse 4.3 and also told others to do so. 4.3 is
better than 4.2, but still not as smooth as 3.7 :-(


On 04.09.2013 17:54, Marshall Schor wrote:
> 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] ------------------------------------------------------------------------
>> 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
>>>>> 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
>>>>> 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
>>>>>>>> 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
>>>>>>> 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:
>>>>>>>> RutaLauncher.main(String[]) line: 119
>>>>>>>> What did I do wrong?
>>>>>>> What is the structure of your Ruta project? Is the script you
>>>>>>> within a source (script) folder?
>>>>>>> The message surprises me a bit. Was there an xmi file in the
>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>> - 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
>>>>>>>>>>> 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.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.*,
>>>>>>>>>>>>>    !org.antlr.stringtemplate,
>>>>>>>>>>>>>    !org.apache.avalon.framework.logger,
>>>>>>>>>>>>>    !org.apache.commons.pool,
>>>>>>>>>>>>>    !org.apache.commons.pool.impl,
>>>>>>>>>>>>>    !org.apache.log, !org.apache.log4j,
>>>>>>>>>>>>>    !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,
>>>>>>>>>>>>>  </Import-Package>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Peter

View raw message