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 15:43:58 GMT
On 04.09.2013 17:23, 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...

Hmm... I think I do not understand the maven build for the bundles well
enough.

I had initially to add some of the unused dependencies in order to get
the maven build up and running, inspired by the other uimaj plugins like
uimaj-ep-cas-editor. I do not know why maven stopped complaining after I
added, e.g., org.eclipse.equinox:app.

uimaj-ep-cas-editor actually returns:

[WARNING] Used undeclared dependencies found:
[WARNING]    org.eclipse.equinox:registry:jar:3.3.0-v20070522:provided
[WARNING]    org.eclipse:text:jar:3.3.0-v20070606-0010:provided
[WARNING]    org.eclipse.ui:workbench:jar:3.3.0-I20070608-1100:provided
[WARNING]    org.eclipse:osgi:jar:3.3.0-v20070530:provided
[WARNING]    org.eclipse:jface:jar:3.3.0-I20070606-0010:provided
[WARNING]    org.eclipse.equinox:preferences:jar:3.2.100-v20070522:provided
[WARNING]    org.eclipse.equinox:common:jar:3.3.0-v20070426:provided
[WARNING] Unused declared dependencies found:
[WARNING]    org.apache.uima:uimaj-tools:jar:2.4.3-SNAPSHOT:compile
[WARNING]    org.eclipse:ui:jar:3.3.0-I20070614-0800:provided
[WARNING]    org.eclipse.ui:ide:jar:3.3.0-I20070620:provided


Peter


> [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