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 Thu, 05 Sep 2013 10:41:28 GMT
On 04.09.2013 21:24, Marshall Schor wrote:
> Well, there is the work-around for 3.7.2 :-)
> (dropping the updated (if it is updated) jar into the dropins folder, and
> changing the launcher to use it.)

Yes and no. Its quite annoying to debug the code within the jars in the
dropins folder. Sometimes, when started from sources, the code
replacement works and I can change ruta-core while running the workbench.


> -Marshall
> On 9/4/2013 2:10 PM, Peter Klügl wrote:
>> 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 :-(
>> Peter
>> 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
>>>> [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
>>>>> 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
>>>>> 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
>>>>>> 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
>>>>>>>> uima-tooling (was 2.4.1, but I do not think that makes a
>>>>>>>> - created project, created script file, created test file,
>>>>>>>> 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
>>>>>>>>>> FileURLConnection.connect() line: 101"
>>>>>>>>>> and a stack trace in the console:
>>>>>>>>>> FileURLConnection.connect() line: 101 [local variables
>>>>>>>>>> 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
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>> - use eclipse 3.7.2 with subclipse, m2e with
>>>>>>>>>>> - 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,
>>>>>>>>>>>>>>>    !edu.emory.mathcs.backport.java.util.concurrent,
>>>>>>>>>>>>>>>    !groovy.lang, !javax.annotation,
>>>>>>>>>>>>>>>    !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.parsers, !javax.xml.stream,
>>>>>>>>>>>>>>>    !javax.xml.stream.events,
>>>>>>>>>>>>>>>    !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.aspectj.*, !org.codehaus.groovy.*,
!org.hibernate.* ,
>>>>>>>>>>>>>>>    !org.joda.*, !org.jruby.*,
>>>>>>>>>>>>>>>    !org.springframework.instrument,
>>>>>>>>>>>>>>>    !org.w3c.dom, !org.xml.sax,
!org.xml.sax.ext, !org.xml.sax.helpers
>>>>>>>>>>>>>>>  </Import-Package>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>> Peter

View raw message