uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-2560) Eclipse m2e complains about unmapped maven plugins
Date Thu, 18 Apr 2013 20:06:13 GMT

    [ https://issues.apache.org/jira/browse/UIMA-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635610#comment-13635610
] 

Marshall Schor commented on UIMA-2560:
--------------------------------------

I've now been able to confirm the following:

Using the Component Descriptor Editor as a guinea pig - 

With the changes in the branch for this Jira, in a 4.2.2 version of Eclipse, it works like
this:
  - the Eclipse "build" (menu -> project -> clean, for instance) of the uimaj-ep-runtime,
produces a target/classes/META-INF/MMANIFEST.MF which has the following ideas:
  -- The classpath is set to include the dependent JARs.
  -- The Jars are not actually copied to the target/classes (This is because the copy-dependencies
has been disabled for m2e)
  -- There's a new stanza: "Embedded-Artifacts" which has metadata needed by Eclipse to dynamically,
at run time, find the right Jars, according to FELIX-3061.

I insured that the uimaj-ep-runtime project had an empty target (manually deleting target/)
and then did the project-clean in Eclipse, which quickly built a new MANIFEST.MF, and no Jar.

Then I set up a Eclipse-Application Launch configuration, specifying it should use the workspace
version of uimaj-ep-runtime (even though it had no Jars), and made sure it didn't have any
loading of any other runtime Jar for uimaj-ep-runtime.  Launched it, and tried out the CDE
- it worked fine - so it was finding and loading the classes using the extra metadata in the
Embedded-Artifacts stanza.

I also confirmed, by deleting jars for uimaj-ep-desceditor (the CDE) and entries for that
in my .m2 repository for the 2.4.1-SNAPSHOT version which is the one being specified, that
Eclipse was doing the following:  When loading the uimaj-ep-runtime, it dynamically substituted
the dependent project's target/classes files for the JARs, and changed the bundle classpath
to reference those in the workspace.  So, this allows testing of new plugin work, without
first building the JARs. :-)

I repeated this on 3.7.2, and it didn't work - That level of Eclipse doesn't have the capability
to make use of this new stanza - and that's documented here: https://github.com/sonatype/m2eclipse-tycho/commit/52acd659504dfb55306f6d06d569f7d2f8752cfc
where it says "<Embed-Dependency> support requires PDE corresponding to Juno M2 or later"
(Juno is 4.2).

I then tried building the uimaj-ep-runtime using maven, outside of Eclipse.  After one small
bug fix (the uimaj-parent pom was setting the version of the maven-bundle-plugin to 2.3.4
- I removed that and the uima parent pom succeeded in picking the latest version 2.3.7), the
build worked.  Here, the copy dependencies (not unpack) step and the jar step were executed
by Maven (they were skipped in the Eclipse build).

So, the main issue with the new way is that it doesn't work with 3.7.2, due to Eclipse launch
missing support for Embed-Dependency.  Unfortunately, 4.2.2 gives me some problems running
in the debugger (previously reported), and I've heard others also have some issues.
(Note: My testing (so far) is only on the CDE)
(Apologies if I'm reporting what others have already found out; at least I'm "confirming"
things and personally understanding more details :-) ). 

I think the changes involved here, provided you install m2e for 3.7.2 from the latest m2e
spot (and *not* from the included m2e that comes with 3.7.2), are "backward-compatible" with
3.7.2 - in the sense that they should compile OK in Eclipse (but not produce working JARs).
 A work-around for 3.7.2 would involve running the maven build outside of Eclipse, which actually
builds the jars, and then manually copying the needed jars to the Eclipse Dropins, and restarting
Eclipse.  Then you need to specify in your Eclipse-application launch configuration to use
the plugin you dropped in instead of the one in the workspace.  I think that's more or less
what people are doing today, with earlier-than-Juno versions of Ecilpse.  

If this sounds right, then I would propose we re-integrate the changes, and let people use
this work-around with 3.7.2, or work the "better" way with 4.2.2 or later if they can get
the later versions to work well for what they're doing. 


                
> Eclipse m2e complains about unmapped maven plugins
> --------------------------------------------------
>
>                 Key: UIMA-2560
>                 URL: https://issues.apache.org/jira/browse/UIMA-2560
>             Project: UIMA
>          Issue Type: Bug
>          Components: Build, Packaging and Test
>    Affects Versions: parent-pom-4
>            Reporter: Richard Eckart de Castilho
>            Assignee: Richard Eckart de Castilho
>             Fix For: parent-pom-5
>
>
> Recent versions of Eclipse m2e complain about Maven plugins in the UIMA master pom not
being covered by m2e lifecycle plugins:
> * uima-build-helper-maven-plugin
> * maven-dependency-plugin
> Add m2e metadata to the master POM to handle these.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message