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:15:46 GMT
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