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:23:55 GMT
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.
>>> 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
>>> 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
>>>>>> 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
>>>>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> e.g. Test
>>>>>>> - right click on the script folder and create a new UIMA Ruta
>>>>>>> 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
>>>>>>> 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.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.*,
>>>>>>>>>>>    !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,
>>>>>>>>>>>  </Import-Package>
>>>>>>>>>>> Best,
>>>>>>>>>>> Peter

View raw message