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 19:24:18 GMT
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.)

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 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
>>>> references to org.antlr.runtime things, including CharStream.
>>>> In the Eclipse source for that project (ruta-ep-ide), I thought I would see
>>>> 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
>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>>>>> 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 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 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
>>>>>>>>>> - 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
>>>>>>>>>>>> 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
>>>>>>>>>>>>>>  <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.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