UIMA
  1. UIMA
  2. UIMA-2560

Eclipse m2e complains about unmapped maven plugins

    Details

      Description

      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.

        Activity

        Hide
        deprecated (use "rec") added a comment -

        There is already a section for m2e in the parent-pom-4, but is is commented without and reason being given in the POM and neither in the commit comments. I activated it and it appears to remove the m2e complaints.

        Marshall Schor, can you comment why this section is not active? It appears you commented it out.

        Show
        deprecated (use "rec") added a comment - There is already a section for m2e in the parent-pom-4, but is is commented without and reason being given in the POM and neither in the commit comments. I activated it and it appears to remove the m2e complaints. Marshall Schor , can you comment why this section is not active? It appears you commented it out.
        Hide
        Marshall Schor added a comment -

        I was fooling around with this earlier, without complete understanding , made some progress, but didn't have enough time to really test things out. So I commented it out until further understanding / tests could be done.

        Show
        Marshall Schor added a comment - I was fooling around with this earlier, without complete understanding , made some progress, but didn't have enough time to really test things out. So I commented it out until further understanding / tests could be done.
        Hide
        deprecated (use "rec") added a comment -

        There is a nasty problem in uimaj-ep-runtime that possibly warrants a separate issue to be tracked in. I'll mention it here on account of having stumbled across it while activating the m2e metadata and not being sure how to proceed:

        During the Maven build, the unpack-dependencies goal is invoked to extract the non-OSGi uimaj runtime artifacts (uimaj-core, uimaj-cpe, etc.) to target/classes.

        When this step is activated in Eclipse via a configuration section for m2e, an error is produced. Due to m2e's workspace artifact resolution feature, the location of these runtime artifacts refers to folders, not to JAR files:

        Error unpacking file: WORKSPACE/uimaj/uimaj-core/target/classes to: WORKSPACE/uimaj/uimaj-ep-runtime/target/classes
        org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. (org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack-dependencies:unpackDependentJars:process-sources)
        

        For the build of the uimaj-ep-* modules to work, even in Eclipse, this copying of JARs seems to be mandatory, because the other projects import packages from the uimaj-ep-runtime module. I don't quite understand the interaction between the Maven and the PDE build/metadata here.

        For example the uimaj-ep-jcasgen module:

        uimaj-ep-jcasgen has a "compile" dependency on uimaj-tools in the POM and "provided" on several Eclipse artifacts. In the plugin.xml, it imports the "...uima.tools.jcasgen" package, several Eclipse packages and adds a plug-in dependency on the org.eclipse.core.runtime.

        I doesn't seem to be the case that "compile" dependencies from the pom are embedded into OSGi artifacts, hence the import of the "...uima.tools.jcasgen" package. Then, why aren't all the dependencies in the pom marked as "provided"?

        Are the dependencies on non-OSGi artifacts like uimaj-core a workaround to the unpack-dependencies goal not working a expected in an Eclipse build? The dependency on uimaj-ep-runtime is commented out, but it just says "don't depend on the runtime plugin", it doesn't explain why.

        Although, everything appears to compile fine, I roughly remember having had problems with that in the past when trying to run/debug UIMA Eclipse plugins getting exceptions because uimaj-ep-runtime didn't contain any classes unless a command line Maven build was run on the whole uimaj project before.

        Did anybody try to fix the uimaj-ep-runtime build in Eclipse? It appears that using Embed-Dependency [1] to include the non-OSGi dependencies in the uimaj-ep-runtime would be a good approach. Looks like this should be compatible with m2e [2] (minus bugs in m2e).

        [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-Embeddingdependencies
        [2] http://web.archiveorange.com/archive/v/sSAtK3rEfyzyIoZNsPxN

        Show
        deprecated (use "rec") added a comment - There is a nasty problem in uimaj-ep-runtime that possibly warrants a separate issue to be tracked in. I'll mention it here on account of having stumbled across it while activating the m2e metadata and not being sure how to proceed: During the Maven build, the unpack-dependencies goal is invoked to extract the non-OSGi uimaj runtime artifacts (uimaj-core, uimaj-cpe, etc.) to target/classes. When this step is activated in Eclipse via a configuration section for m2e, an error is produced. Due to m2e's workspace artifact resolution feature, the location of these runtime artifacts refers to folders, not to JAR files: Error unpacking file: WORKSPACE/uimaj/uimaj-core/target/classes to: WORKSPACE/uimaj/uimaj-ep-runtime/target/classes org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. (org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack-dependencies:unpackDependentJars:process-sources) For the build of the uimaj-ep-* modules to work, even in Eclipse, this copying of JARs seems to be mandatory, because the other projects import packages from the uimaj-ep-runtime module. I don't quite understand the interaction between the Maven and the PDE build/metadata here. For example the uimaj-ep-jcasgen module: uimaj-ep-jcasgen has a "compile" dependency on uimaj-tools in the POM and "provided" on several Eclipse artifacts. In the plugin.xml, it imports the "...uima.tools.jcasgen" package, several Eclipse packages and adds a plug-in dependency on the org.eclipse.core.runtime. I doesn't seem to be the case that "compile" dependencies from the pom are embedded into OSGi artifacts, hence the import of the "...uima.tools.jcasgen" package. Then, why aren't all the dependencies in the pom marked as "provided"? Are the dependencies on non-OSGi artifacts like uimaj-core a workaround to the unpack-dependencies goal not working a expected in an Eclipse build? The dependency on uimaj-ep-runtime is commented out, but it just says "don't depend on the runtime plugin", it doesn't explain why. Although, everything appears to compile fine, I roughly remember having had problems with that in the past when trying to run/debug UIMA Eclipse plugins getting exceptions because uimaj-ep-runtime didn't contain any classes unless a command line Maven build was run on the whole uimaj project before. Did anybody try to fix the uimaj-ep-runtime build in Eclipse? It appears that using Embed-Dependency [1] to include the non-OSGi dependencies in the uimaj-ep-runtime would be a good approach. Looks like this should be compatible with m2e [2] (minus bugs in m2e). [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-Embeddingdependencies [2] http://web.archiveorange.com/archive/v/sSAtK3rEfyzyIoZNsPxN
        Hide
        deprecated (use "rec") added a comment -

        The Embed-Dependency is already used in uimaj-ep-runtime. I wonder what the unpack-dependencies goal is supposed good for...

        Show
        deprecated (use "rec") added a comment - The Embed-Dependency is already used in uimaj-ep-runtime. I wonder what the unpack-dependencies goal is supposed good for...
        Hide
        deprecated (use "rec") added a comment -

        Created branches of uimaj and build for this issue because these changes should be well tested and may need amendments:

        • Upgraded maven-bundle-plugin to 2.3.7 which is required for m2e to support the Embed-Dependency directive (see FELIX-3061). Note this may require the m2e tycho plugin to work properly. I tried running the CAS Editor before this change and got ClassNotFound exceptions. After the upgrade, the classes were found.
        • Removed inline from the Embed-Dependency directive in uimaj-ep-runtime, because inlined artifacts are not supported by FELIX-3061. Is there a special reason for inlining?
        • Removed maven-dependeny-plugin/unpack-dependencies execution from uimaj-ep-runtime.
        • Ignoring any runs of the maven-dependency-plugin in the master pom. Affects docbook processing and profiles build simple project binary assembly and build OSGi bundle for annotator. Docbook processing is probably not required in Eclipse builds. I didn't fully investigate the purpose of the plugin in the profiles, possibly it shouldn't even be in the OSGi profile (see comments above on uimaj-ep-runtime).
        • Goals for plugins maven-remote-resources-plugin and uima-build-helper-maven-plugin activated per m2e configuration in master pom.
        Show
        deprecated (use "rec") added a comment - Created branches of uimaj and build for this issue because these changes should be well tested and may need amendments: Upgraded maven-bundle-plugin to 2.3.7 which is required for m2e to support the Embed-Dependency directive (see FELIX-3061 ). Note this may require the m2e tycho plugin to work properly. I tried running the CAS Editor before this change and got ClassNotFound exceptions. After the upgrade, the classes were found. Removed inline from the Embed-Dependency directive in uimaj-ep-runtime, because inlined artifacts are not supported by FELIX-3061 . Is there a special reason for inlining? Removed maven-dependeny-plugin/unpack-dependencies execution from uimaj-ep-runtime. Ignoring any runs of the maven-dependency-plugin in the master pom. Affects docbook processing and profiles build simple project binary assembly and build OSGi bundle for annotator . Docbook processing is probably not required in Eclipse builds. I didn't fully investigate the purpose of the plugin in the profiles, possibly it shouldn't even be in the OSGi profile (see comments above on uimaj-ep-runtime). Goals for plugins maven-remote-resources-plugin and uima-build-helper-maven-plugin activated per m2e configuration in master pom.
        Hide
        Peter Klügl added a comment -

        Well, it won't work without unpack-dependencies. I don't know it for sure, but I think that the classes are not correctly embedded if they are still in their jars. Here's some information about this process: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html

        I also think that this process is quite annoying, because everytime m2e gets the idea of building the uimaj-ep-textmarker-engine or the uimaj-ep-runtime project, it breaks both jars (since the unpack-dependencies is deativated). Then, I have to build them again manually, however only after I realized that the eclipse plugins do not work correctly. I also tried to deactivate the m2e builder locally for the two projects, but that broke my complete workspace.

        Show
        Peter Klügl added a comment - Well, it won't work without unpack-dependencies. I don't know it for sure, but I think that the classes are not correctly embedded if they are still in their jars. Here's some information about this process: https://cwiki.apache.org/UIMA/building-eclipse-plugins-with-maven-bundle-plugin-and-friends.html I also think that this process is quite annoying, because everytime m2e gets the idea of building the uimaj-ep-textmarker-engine or the uimaj-ep-runtime project, it breaks both jars (since the unpack-dependencies is deativated). Then, I have to build them again manually, however only after I realized that the eclipse plugins do not work correctly. I also tried to deactivate the m2e builder locally for the two projects, but that broke my complete workspace.
        Hide
        Peter Klügl added a comment -

        My last comment was referring to your comment 13/Jan/13 20:19. I will be really happy, if your changes work without problems.

        Show
        Peter Klügl added a comment - My last comment was referring to your comment 13/Jan/13 20:19. I will be really happy, if your changes work without problems.
        Hide
        deprecated (use "rec") added a comment -

        Peter Klügl, please check out FELIX-3061 and the changes I committed to the branches. Can you be more specific what will not work without unpack-dependencies? Is this required for the Eclipse build, for the Maven build, for both?

        Show
        deprecated (use "rec") added a comment - Peter Klügl , please check out FELIX-3061 and the changes I committed to the branches. Can you be more specific what will not work without unpack-dependencies? Is this required for the Eclipse build, for the Maven build, for both?
        Hide
        Peter Klügl added a comment -

        Oh, I will

        Show
        Peter Klügl added a comment - Oh, I will
        Hide
        deprecated (use "rec") added a comment -

        Thanks for the pointer to the wiki page.

        I am not sure if the below is still true. First, I never made that experience in the past, e.g. when I was working with OSGi/PDE and wrapped existing third-party libraries as bundles, I never observed this problem. Second, the uimaj-core classes from the uimaj-ep-runtime were properly found when I ran the CAS Editor using "Run as -> Eclipse application". Of course there might be problems when running the actual JARs built with Maven that did not appear in my test run due to the m2e-tycho magic.

        The inline=true flag is set when embedding dependencies, to avoid having the bundle jar contain within itself, other jars. This flag puts the contents of the inner jars into the containing jars. This is needed because the OSGi or Eclipse mechanisms doesn't see exports coming from these jars within jars. See the statements about "Unzipping JARs" in the Eclipse Help.

        Btw, I am using Eclipse 4.2.1 (M20120914-1800), m2e 1.2.0.20120903-1050 and the Tycho Project Configurators 0.6.0.201207302152.

        Show
        deprecated (use "rec") added a comment - Thanks for the pointer to the wiki page. I am not sure if the below is still true. First, I never made that experience in the past, e.g. when I was working with OSGi/PDE and wrapped existing third-party libraries as bundles, I never observed this problem. Second, the uimaj-core classes from the uimaj-ep-runtime were properly found when I ran the CAS Editor using "Run as -> Eclipse application". Of course there might be problems when running the actual JARs built with Maven that did not appear in my test run due to the m2e-tycho magic. The inline=true flag is set when embedding dependencies, to avoid having the bundle jar contain within itself, other jars. This flag puts the contents of the inner jars into the containing jars. This is needed because the OSGi or Eclipse mechanisms doesn't see exports coming from these jars within jars. See the statements about "Unzipping JARs" in the Eclipse Help. Btw, I am using Eclipse 4.2.1 (M20120914-1800), m2e 1.2.0.20120903-1050 and the Tycho Project Configurators 0.6.0.201207302152.
        Hide
        Marshall Schor added a comment -

        Sorry to be late to this party but I'm delighted that others are grappling with these issues!

        Some details: IIRC, the builds for the OSGi runtimes was done in a slightly strange way: the maven-bundle-plugin was used in a mode which only built the MANIFEST.MF file, but didn't build any JARs. This was because the Jar building (at the time this was done) didn't do the normal things we do with all of our JAR building (via some common configuration in the UIMA parent-pom) to insert License/Notice kinds of things.

        Because of this, I think the unpack-dependencies is needed to actually put in the content into the JAR that is built.

        Show
        Marshall Schor added a comment - Sorry to be late to this party but I'm delighted that others are grappling with these issues! Some details: IIRC, the builds for the OSGi runtimes was done in a slightly strange way: the maven-bundle-plugin was used in a mode which only built the MANIFEST.MF file, but didn't build any JARs. This was because the Jar building (at the time this was done) didn't do the normal things we do with all of our JAR building (via some common configuration in the UIMA parent-pom) to insert License/Notice kinds of things. Because of this, I think the unpack-dependencies is needed to actually put in the content into the JAR that is built.
        Hide
        Marshall Schor added a comment -

        Another point: I think there's some meta-configuration for m2e which says whether or not to use projects in the workspace to resolve references, or not. It's "normally" set to use projects, so as to pick up development level changes (before JARs are created and "installed" to the .m2 repo). But you can change that.

        Another idea: how about making the unpack-dependencies step conditional on there being a Jar, and otherwise, just using the folders /target/classes?

        Show
        Marshall Schor added a comment - Another point: I think there's some meta-configuration for m2e which says whether or not to use projects in the workspace to resolve references, or not. It's "normally" set to use projects, so as to pick up development level changes (before JARs are created and "installed" to the .m2 repo). But you can change that. Another idea: how about making the unpack-dependencies step conditional on there being a Jar, and otherwise, just using the folders /target/classes?
        Hide
        deprecated (use "rec") added a comment -
        • re jar building: maybe there is another approach to JAR building that doesn't need unpack-dependencies and that can be run in a profile so that it is not enabled when run within Eclipse. For example an ant-run post-processing step.
        • re m2e disable workspace resolution: it is possible to disable that, per project even. I find workspace resolution very useful though. It will probably also be confusing and lead to unexpected effects if resolution is disabled for some projects but not for others. -1 on this one.
        • re conditional unpack-dependencies: +1 for conditional. Instead of testing for a JAR (no idea how that could be done), I suggest to test for Eclipse/m2e. There are special properties that are set during an m2e build which can be use to enable/disable profiles.
        Show
        deprecated (use "rec") added a comment - re jar building: maybe there is another approach to JAR building that doesn't need unpack-dependencies and that can be run in a profile so that it is not enabled when run within Eclipse. For example an ant-run post-processing step. re m2e disable workspace resolution: it is possible to disable that, per project even. I find workspace resolution very useful though. It will probably also be confusing and lead to unexpected effects if resolution is disabled for some projects but not for others. -1 on this one. re conditional unpack-dependencies: +1 for conditional. Instead of testing for a JAR (no idea how that could be done), I suggest to test for Eclipse/m2e. There are special properties that are set during an m2e build which can be use to enable/disable profiles.
        Hide
        Peter Klügl added a comment -

        About the branch UIMA-2560:
        I tried to build the uimaj-ep-runtime plugin, but only get an empty jar (only manifest, no classes). This happens when m2e builds the project as well as when I build it directly with maven. Where did you change the maven-bundle-plugin version? I additionally checked out parent-pom and changed the version there to 2.3.7.

        I am using Eclipse Indigo Service Release 2 20120216-1857 (RCP/RAP), m2e 1.2.0.20120903-1050 and the Tycho Project Configurators 0.6.0.201207302152.

        Show
        Peter Klügl added a comment - About the branch UIMA-2560 : I tried to build the uimaj-ep-runtime plugin, but only get an empty jar (only manifest, no classes). This happens when m2e builds the project as well as when I build it directly with maven. Where did you change the maven-bundle-plugin version? I additionally checked out parent-pom and changed the version there to 2.3.7. I am using Eclipse Indigo Service Release 2 20120216-1857 (RCP/RAP), m2e 1.2.0.20120903-1050 and the Tycho Project Configurators 0.6.0.201207302152.
        Hide
        deprecated (use "rec") added a comment -

        I also created a branch of the "build" module which contains the master parent-pom.

        Right about the JAR. The MANIFEST.MF seems correct though, just the JARs are missing.

        I re-added the dependencies plugin, but this time using copy-dependencies instead of unpack dependencies. On the command line build, that seems to create a proper JAR. In Eclipse, the copy-dependencies goal is ignored and the tycho plugin should take care of configuring the classpath properly when "Run As -> Eclipse Application" is used.

        I googled a little and it appears that the JARs are not may not be copied the maven-bundle-plugin because the packaging is set to "jar" not "bundle" - but just changing the packging didn't work either in a quick test.

        Show
        deprecated (use "rec") added a comment - I also created a branch of the "build" module which contains the master parent-pom. Right about the JAR. The MANIFEST.MF seems correct though, just the JARs are missing. I re-added the dependencies plugin, but this time using copy-dependencies instead of unpack dependencies. On the command line build, that seems to create a proper JAR. In Eclipse, the copy-dependencies goal is ignored and the tycho plugin should take care of configuring the classpath properly when "Run As -> Eclipse Application" is used. I googled a little and it appears that the JARs are not may not be copied the maven-bundle-plugin because the packaging is set to "jar" not "bundle" - but just changing the packging didn't work either in a quick test.
        Hide
        Marshall Schor added a comment -

        re: re-adding the dependencies, using copy-dependencies instead of unpack: This is probably a good thing. I recall noticing at one point that, in general, it was important to keep each embedded dependency as its own Jar, because if they were unpacked, then if each one had a LICENSE and NOTICE file, they would "overlay" one another, losing the individual JAR's information (except for the last one). It seems that, in general, the OSGi consumption mechanisms correctly support embedded Jars (within Jars).

        re: packaging set to "jar" not "bundle" - the packaging is set to JAR to avoid having the maven-bundle-plugin build the JARs, because (at the time the POMs were constructed), the bundle target didn't let you insert the LICENSE and NOTICE files into the JARs.

        Show
        Marshall Schor added a comment - re: re-adding the dependencies, using copy-dependencies instead of unpack: This is probably a good thing. I recall noticing at one point that, in general, it was important to keep each embedded dependency as its own Jar, because if they were unpacked, then if each one had a LICENSE and NOTICE file, they would "overlay" one another, losing the individual JAR's information (except for the last one). It seems that, in general, the OSGi consumption mechanisms correctly support embedded Jars (within Jars). re: packaging set to "jar" not "bundle" - the packaging is set to JAR to avoid having the maven-bundle-plugin build the JARs, because (at the time the POMs were constructed), the bundle target didn't let you insert the LICENSE and NOTICE files into the JARs.
        Hide
        Richard Eckart de Castilho added a comment -

        Filing comment by Marshall Schor which went to the dev mailing list so it doesn't get lost:

        • Upgraded maven-bundle-plugin to 2.3.7 which is required for m2e to support the Embed-Dependency directive (see FELIX-3061). Note this may require the m2e tycho plugin to work properly. I tried running the CAS Editor before this change and got ClassNotFound exceptions. After the upgrade, the classes were found.
        • Removed inline from the Embed-Dependency directive in uimaj-ep-runtime, because inlined artifacts are not supported by FELIX-3061. Is there a special reason for inlining?

        I think inlining was intended to get the artifacts included, but the copy/unpack
        dependencies also does that. So maybe not an issue?

        • Removed maven-dependeny-plugin/unpack-dependencies execution from uimaj-ep-runtime.

        now put back (as copy-dependencies)

        • Ignoring any runs of the maven-dependency-plugin in the master pom. Affects docbook processing and profiles build simple project binary assembly and build OSGi bundle for annotator. Docbook processing is probably not required in Eclipse builds. I didn't fully investigate the purpose of the plugin in the profiles, possibly it shouldn't even be in the OSGi profile (see comments above on uimaj-ep-runtime).

        I don't really understand this ... However, it's a good thing to bypass lots
        of "build" processing with m2e, where there's no point (it just slows down
        import and setup). So, for example, building the docbooks is usually not of
        interest. When it is of interest, you can always do the maven command or in
        Eclipse, right-click on the project and choose run-as mvn install, etc.

        The m2e build should just be for things in the workspace which users would want
        always up-to-date rebuilt.

        • Goals for plugins maven-remote-resources-plugin and uima-build-helper-maven-plugin activated per m2e configuration in master pom.

        This is probably not useful. These are there to follow legal release
        requirements. During local development, they would just slow things down a bit.

        Show
        Richard Eckart de Castilho added a comment - Filing comment by Marshall Schor which went to the dev mailing list so it doesn't get lost: Upgraded maven-bundle-plugin to 2.3.7 which is required for m2e to support the Embed-Dependency directive (see FELIX-3061 ). Note this may require the m2e tycho plugin to work properly. I tried running the CAS Editor before this change and got ClassNotFound exceptions. After the upgrade, the classes were found. Removed inline from the Embed-Dependency directive in uimaj-ep-runtime, because inlined artifacts are not supported by FELIX-3061 . Is there a special reason for inlining? I think inlining was intended to get the artifacts included, but the copy/unpack dependencies also does that. So maybe not an issue? Removed maven-dependeny-plugin/unpack-dependencies execution from uimaj-ep-runtime. now put back (as copy-dependencies) Ignoring any runs of the maven-dependency-plugin in the master pom. Affects docbook processing and profiles build simple project binary assembly and build OSGi bundle for annotator . Docbook processing is probably not required in Eclipse builds. I didn't fully investigate the purpose of the plugin in the profiles, possibly it shouldn't even be in the OSGi profile (see comments above on uimaj-ep-runtime). I don't really understand this ... However, it's a good thing to bypass lots of "build" processing with m2e, where there's no point (it just slows down import and setup). So, for example, building the docbooks is usually not of interest. When it is of interest, you can always do the maven command or in Eclipse, right-click on the project and choose run-as mvn install, etc. The m2e build should just be for things in the workspace which users would want always up-to-date rebuilt. Goals for plugins maven-remote-resources-plugin and uima-build-helper-maven-plugin activated per m2e configuration in master pom. This is probably not useful. These are there to follow legal release requirements. During local development, they would just slow things down a bit.
        Hide
        Peter Klügl added a comment -

        Does not work for me. I checked out the uimaj and build branch, added mapping for m2e complaints and built the projects with m2e and/or maven (run as...). m2e doesn't work at all and the maven build is not able to create a valid runtime plugin. The jar itself contains again jars, e.g., uimaj-core.jar. In Eclipse, the bundle is not able to resolve these and I get an ClassNotFoundException.

        Show
        Peter Klügl added a comment - Does not work for me. I checked out the uimaj and build branch, added mapping for m2e complaints and built the projects with m2e and/or maven (run as...). m2e doesn't work at all and the maven build is not able to create a valid runtime plugin. The jar itself contains again jars, e.g., uimaj-core.jar. In Eclipse, the bundle is not able to resolve these and I get an ClassNotFoundException.
        Hide
        Richard Eckart de Castilho added a comment -

        It is strange that you had to add any mappings.

        I cannot reproduce your problems. Here is what I did:

        • started a new workspace.
        • checked out https://svn.apache.org/repos/asf/uima/build/branches/UIMA-2560/parent-pom in Eclipse (checkout as Maven project)
        • checked out https://svn.apache.org/repos/asf/uima/uimaj/branches/UIMA-2560 on the command line, then imported into Eclipse as existing Maven project
        • created a run configuration for "uimaj-em-cas-editor"
          • launch with "plug-ins selected below only"
          • selected all "workspace" plugins (all org.apache.uima)
          • added required plugins per button
          • checked that only the workspace plugins are active and no other "org.apache.uima" plugins installed in the Eclipse platform are selected
        • ran the application
        • opened a type system descriptor in the UIMA component description editor

        No need to change any code, add any additional mappings until here and no ClassNotFoundException. Is it possible that you still had a non-branch version of uimaj or of the UIMA parent pom in your workspace?

        Then on the command line, I did:

        • cd ECLIPSE_WORKSPACE
        • cd parent-pom
        • mvn clean install
        • cd ../uimaj
        • mvn clean install

        The build runs through. After the build, I there is a file ECLIPSE_WORKSPACE/uimaj/uimaj-ep-runtime/target/org.apache.uima.runtime_2.4.1.SNAPSHOT.jar with the following contents:

         Length   Method    Size  Ratio   Date   Time   CRC-32    Name
        --------  ------  ------- -----   ----   ----   ------    ----
               0  Stored        0   0%  02-09-13 10:27  00000000  META-INF/
            7775  Defl:N     1627  79%  02-09-13 10:27  98383573  META-INF/MANIFEST.MF
          149686  Defl:N   137348   8%  02-09-13 10:26  0dc91806  jVinci-2.4.1-SNAPSHOT.jar
            1710  Defl:N      377  78%  02-09-13 10:26  dfb779c1  META-INF/DEPENDENCIES
           11560  Defl:N     3963  66%  02-09-13 10:26  495fc599  META-INF/LICENSE
             200  Defl:N      148  26%  02-09-13 10:26  7bd83ee0  META-INF/NOTICE
            1051  Defl:N      533  49%  02-09-13 10:26  c2de07ce  plugin.xml
           48677  Defl:N    44699   8%  02-09-13 10:26  c94e3bb2  uimaj-adapter-vinci-2.4.1-SNAPSHOT.jar
         1356906  Defl:N  1235722   9%  02-09-13 10:26  af1b2f83  uimaj-core-2.4.1-SNAPSHOT.jar
          341218  Defl:N   318863   7%  02-09-13 10:26  124ec17e  uimaj-cpe-2.4.1-SNAPSHOT.jar
           11529  Defl:N     9764  15%  02-09-13 10:26  b8386bde  uimaj-document-annotation-2.4.1-SNAPSHOT.jar
          526389  Defl:N   483859   8%  02-09-13 10:26  a98a1c3b  uimaj-tools-2.4.1-SNAPSHOT.jar
               0  Stored        0   0%  02-09-13 10:27  00000000  META-INF/maven/
               0  Stored        0   0%  02-09-13 10:27  00000000  META-INF/maven/org.apache.uima/
               0  Stored        0   0%  02-09-13 10:27  00000000  META-INF/maven/org.apache.uima/uimaj-ep-runtime/
           11496  Defl:N     2713  76%  02-09-13 10:06  69a5d8dd  META-INF/maven/org.apache.uima/uimaj-ep-runtime/pom.xml
             125  Defl:N      121   3%  02-09-13 10:27  fa9e535c  META-INF/maven/org.apache.uima/uimaj-ep-runtime/pom.properties
        --------          -------  ---                            -------
         2468322          2239737   9%                            17 files
        
        Show
        Richard Eckart de Castilho added a comment - It is strange that you had to add any mappings. I cannot reproduce your problems. Here is what I did: started a new workspace. checked out https://svn.apache.org/repos/asf/uima/build/branches/UIMA-2560/parent-pom in Eclipse (checkout as Maven project) checked out https://svn.apache.org/repos/asf/uima/uimaj/branches/UIMA-2560 on the command line, then imported into Eclipse as existing Maven project created a run configuration for "uimaj-em-cas-editor" launch with "plug-ins selected below only" selected all "workspace" plugins (all org.apache.uima) added required plugins per button checked that only the workspace plugins are active and no other "org.apache.uima" plugins installed in the Eclipse platform are selected ran the application opened a type system descriptor in the UIMA component description editor No need to change any code, add any additional mappings until here and no ClassNotFoundException. Is it possible that you still had a non-branch version of uimaj or of the UIMA parent pom in your workspace? Then on the command line, I did: cd ECLIPSE_WORKSPACE cd parent-pom mvn clean install cd ../uimaj mvn clean install The build runs through. After the build, I there is a file ECLIPSE_WORKSPACE/uimaj/uimaj-ep-runtime/target/org.apache.uima.runtime_2.4.1.SNAPSHOT.jar with the following contents: Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 0 Stored 0 0% 02-09-13 10:27 00000000 META-INF/ 7775 Defl:N 1627 79% 02-09-13 10:27 98383573 META-INF/MANIFEST.MF 149686 Defl:N 137348 8% 02-09-13 10:26 0dc91806 jVinci-2.4.1-SNAPSHOT.jar 1710 Defl:N 377 78% 02-09-13 10:26 dfb779c1 META-INF/DEPENDENCIES 11560 Defl:N 3963 66% 02-09-13 10:26 495fc599 META-INF/LICENSE 200 Defl:N 148 26% 02-09-13 10:26 7bd83ee0 META-INF/NOTICE 1051 Defl:N 533 49% 02-09-13 10:26 c2de07ce plugin.xml 48677 Defl:N 44699 8% 02-09-13 10:26 c94e3bb2 uimaj-adapter-vinci-2.4.1-SNAPSHOT.jar 1356906 Defl:N 1235722 9% 02-09-13 10:26 af1b2f83 uimaj-core-2.4.1-SNAPSHOT.jar 341218 Defl:N 318863 7% 02-09-13 10:26 124ec17e uimaj-cpe-2.4.1-SNAPSHOT.jar 11529 Defl:N 9764 15% 02-09-13 10:26 b8386bde uimaj-document-annotation-2.4.1-SNAPSHOT.jar 526389 Defl:N 483859 8% 02-09-13 10:26 a98a1c3b uimaj-tools-2.4.1-SNAPSHOT.jar 0 Stored 0 0% 02-09-13 10:27 00000000 META-INF/maven/ 0 Stored 0 0% 02-09-13 10:27 00000000 META-INF/maven/org.apache.uima/ 0 Stored 0 0% 02-09-13 10:27 00000000 META-INF/maven/org.apache.uima/uimaj-ep-runtime/ 11496 Defl:N 2713 76% 02-09-13 10:06 69a5d8dd META-INF/maven/org.apache.uima/uimaj-ep-runtime/pom.xml 125 Defl:N 121 3% 02-09-13 10:27 fa9e535c META-INF/maven/org.apache.uima/uimaj-ep-runtime/pom.properties -------- ------- --- ------- 2468322 2239737 9% 17 files
        Hide
        Peter Klügl added a comment -

        Works for me in Eclipse 4.2, but not in Eclipse 3.7. The plugin seems to be correctly built, but I get an exception when opening the editor.

        I remember something that if your plugin contains jars, then you may not deploy it as a jar, but have to deploy it as a folder. I don't know if this has changed with Eclsipe 4.2.

        Show
        Peter Klügl added a comment - Works for me in Eclipse 4.2, but not in Eclipse 3.7. The plugin seems to be correctly built, but I get an exception when opening the editor. I remember something that if your plugin contains jars, then you may not deploy it as a jar, but have to deploy it as a folder. I don't know if this has changed with Eclsipe 4.2.
        Hide
        Richard Eckart de Castilho added a comment -

        How about Eclipse 3.8? If that worked, would it clash in any way with TextMarker's DLTK requirements?

        Show
        Richard Eckart de Castilho added a comment - How about Eclipse 3.8? If that worked, would it clash in any way with TextMarker's DLTK requirements?
        Hide
        Richard Eckart de Castilho added a comment -

        What should we do about this? Defer it or implement it and make life easier for Eclipse 4.2+ users?

        Show
        Richard Eckart de Castilho added a comment - What should we do about this? Defer it or implement it and make life easier for Eclipse 4.2+ users?
        Hide
        Marshall Schor added a comment -

        I suggest we (a) confirm the new design doesn't work for 3.7 Eclipse, and then (b) figure out why it doesn't work and put in some simple workaround if possible for that. For instance, if the reason for not working is (as mentioned above) that embedded JARs in a plugin need to be deployed by "unpacking" the Jar when it is installed by the installer, there's an Eclipse directive for that, part of Eclipse 3.7 (Indigo) - Eclipse-BundleShape ::= ( 'jar' | 'dir' ) - see http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html.

        Show
        Marshall Schor added a comment - I suggest we (a) confirm the new design doesn't work for 3.7 Eclipse, and then (b) figure out why it doesn't work and put in some simple workaround if possible for that. For instance, if the reason for not working is (as mentioned above) that embedded JARs in a plugin need to be deployed by "unpacking" the Jar when it is installed by the installer, there's an Eclipse directive for that, part of Eclipse 3.7 (Indigo) - Eclipse-BundleShape ::= ( 'jar' | 'dir' ) - see http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html .
        Hide
        Peter Klügl added a comment -

        Sorry for my delayed response.
        I haven't tried it yet with 3.8, but I would like to keep supporting Eclipse 3.7. It would be really nice to get rid of the m2e problems for the "lib" plugins and thus we should maybe search for a workaround. I haven't tried Eclipse-BundleShape ::= 'dir' yet, but wouldn't it be problematic with the rest of the maven build? Or is it just a directive to unpack the bundle when it is installed?

        Show
        Peter Klügl added a comment - Sorry for my delayed response. I haven't tried it yet with 3.8, but I would like to keep supporting Eclipse 3.7. It would be really nice to get rid of the m2e problems for the "lib" plugins and thus we should maybe search for a workaround. I haven't tried Eclipse-BundleShape ::= 'dir' yet, but wouldn't it be problematic with the rest of the maven build? Or is it just a directive to unpack the bundle when it is installed?
        Hide
        Richard Eckart de Castilho added a comment -

        Afaik it's only used when the bundle is installed. It shouldn't make any difference to Maven. The JAR should still be created and handled by Maven as usual.

        Show
        Richard Eckart de Castilho added a comment - Afaik it's only used when the bundle is installed. It shouldn't make any difference to Maven. The JAR should still be created and handled by Maven as usual.
        Hide
        Peter Klügl added a comment -

        I played a bit around with <Eclipse-BundleShape>dir</Eclipse-BundleShape> and Eclipse 3.7.2

        • does not work for starting Eclipse within Eclipse
        • installation using a local update site works, the bundle is deployed as a folder
        • installed plugin does not work correctly: java.lang.ClassNotFoundException: org.apache.uima.resource.metadata.MetaDataObject. This is caused by different namings for the included jars. The manifest in the deployed folder refers, e.g., to uima-core.jar, but the folder contains uimaj-core-2.4.1-SNAPSHOT.jar.

        Maybe I did something wrong here, but - interestingly enough - the manifest in the java project is not equal to the manifest in the jar after "mvn clean package":

        project:

        Bundle-ClassPath: .,uimaj-core-2.4.1-SNAPSHOT.jar,uimaj-cpe-2.4.1-SNAPSH
         OT.jar,uimaj-tools-2.4.1-SNAPSHOT.jar,uimaj-adapter-vinci-2.4.1-SNAPSHO
         T.jar,jVinci-2.4.1-SNAPSHOT.jar
        Embedded-Artifacts: uimaj-core-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a=
         "uimaj-core";v="2.4.1-SNAPSHOT",uimaj-cpe-2.4.1-SNAPSHOT.jar;g="org.apa
         che.uima";a="uimaj-cpe";v="2.4.1-SNAPSHOT",uimaj-tools-2.4.1-SNAPSHOT.j
         ar;g="org.apache.uima";a="uimaj-tools";v="2.4.1-SNAPSHOT",uimaj-adapter
         -vinci-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a="uimaj-adapter-vinci";v
         ="2.4.1-SNAPSHOT",jVinci-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a="jVin
         ci";v="2.4.1-SNAPSHOT"
        

        vs

        jar:

        Bundle-ClassPath: .,uima-core.jar,jVinci.jar,uima-tools.jar,uima-adapt
         er-vinci.jar,uima-cpe.jar
        

        Is that correctly resolved in your workspace?

        Show
        Peter Klügl added a comment - I played a bit around with <Eclipse-BundleShape>dir</Eclipse-BundleShape> and Eclipse 3.7.2 does not work for starting Eclipse within Eclipse installation using a local update site works, the bundle is deployed as a folder installed plugin does not work correctly: java.lang.ClassNotFoundException: org.apache.uima.resource.metadata.MetaDataObject. This is caused by different namings for the included jars. The manifest in the deployed folder refers, e.g., to uima-core.jar, but the folder contains uimaj-core-2.4.1-SNAPSHOT.jar. Maybe I did something wrong here, but - interestingly enough - the manifest in the java project is not equal to the manifest in the jar after "mvn clean package": project: Bundle-ClassPath: .,uimaj-core-2.4.1-SNAPSHOT.jar,uimaj-cpe-2.4.1-SNAPSH OT.jar,uimaj-tools-2.4.1-SNAPSHOT.jar,uimaj-adapter-vinci-2.4.1-SNAPSHO T.jar,jVinci-2.4.1-SNAPSHOT.jar Embedded-Artifacts: uimaj-core-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a= "uimaj-core";v="2.4.1-SNAPSHOT",uimaj-cpe-2.4.1-SNAPSHOT.jar;g="org.apa che.uima";a="uimaj-cpe";v="2.4.1-SNAPSHOT",uimaj-tools-2.4.1-SNAPSHOT.j ar;g="org.apache.uima";a="uimaj-tools";v="2.4.1-SNAPSHOT",uimaj-adapter -vinci-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a="uimaj-adapter-vinci";v ="2.4.1-SNAPSHOT",jVinci-2.4.1-SNAPSHOT.jar;g="org.apache.uima";a="jVin ci";v="2.4.1-SNAPSHOT" vs jar: Bundle-ClassPath: .,uima-core.jar,jVinci.jar,uima-tools.jar,uima-adapt er-vinci.jar,uima-cpe.jar Is that correctly resolved in your workspace?
        Hide
        Richard Eckart de Castilho added a comment -

        Wait a moment... when you run "mvn clean install", you get the Bundle-ClassPath without versions in target/org.apache.uima.runtime_2.4.1.SNAPSHOT.jar? When I run "mvn clean install" on the command line, I get the versioned ones, at least with branch UIMA-2560 rev 1450292. I also have the versioned ones in uimaj-ep-runtime/META-INF/MANIFEST.MF (although I don't know what step exactly generates that file)

        Show
        Richard Eckart de Castilho added a comment - Wait a moment... when you run "mvn clean install", you get the Bundle-ClassPath without versions in target/org.apache.uima.runtime_2.4.1.SNAPSHOT.jar? When I run "mvn clean install" on the command line, I get the versioned ones, at least with branch UIMA-2560 rev 1450292. I also have the versioned ones in uimaj-ep-runtime/META-INF/MANIFEST.MF (although I don't know what step exactly generates that file)
        Hide
        Peter Klügl added a comment -

        Hmm... strange, I tested it yesterday at least three times and got evertime the same result, but I cannot reproduce it anymore now.

        Show
        Peter Klügl added a comment - Hmm... strange, I tested it yesterday at least three times and got evertime the same result, but I cannot reproduce it anymore now.
        Hide
        Peter Klügl added a comment -

        I built the runtime plugin with 3.7.2 and Eclipse-BundleShape=dir, packaged an update site (2.4.1-SNAPSHOT) and installed the features in an Eclipse 3.7.2. Works fine.

        I take a look at the problem with starting an eclipse instance using the uima workspace.

        Show
        Peter Klügl added a comment - I built the runtime plugin with 3.7.2 and Eclipse-BundleShape=dir, packaged an update site (2.4.1-SNAPSHOT) and installed the features in an Eclipse 3.7.2. Works fine. I take a look at the problem with starting an eclipse instance using the uima workspace.
        Hide
        Peter Klügl added a comment -

        I have not found the reason why the plugin won't work in a started eclipse instance. Stuff like MAVEN2_CLASSPATH_CONTAINER looks fine.

        Can someone verify, if this is really a problem in Eclipse 3.7.2? Maybe my m2e is broken.

        Show
        Peter Klügl added a comment - I have not found the reason why the plugin won't work in a started eclipse instance. Stuff like MAVEN2_CLASSPATH_CONTAINER looks fine. Can someone verify, if this is really a problem in Eclipse 3.7.2? Maybe my m2e is broken.
        Hide
        Marshall Schor added a comment -

        I'm starting to rebuild my development environment around Eclipse 4.2.2, etc., and want to use the current m2e plugins. Can we remerge this branch back into the trunk so we can avoid the m2e issues around unmapped plugins, and start using the new packaging of plugins that avoids "unpacking" them, and maybe get some of these other problems shaken out?

        Show
        Marshall Schor added a comment - I'm starting to rebuild my development environment around Eclipse 4.2.2, etc., and want to use the current m2e plugins. Can we remerge this branch back into the trunk so we can avoid the m2e issues around unmapped plugins, and start using the new packaging of plugins that avoids "unpacking" them, and maybe get some of these other problems shaken out?
        Hide
        Richard Eckart de Castilho added a comment -

        Unfortunately, I didn't have any time to look further into this issue, in particular not for installing different old versions of Eclipse and testing the scenario. It appears that the branch works with recent Eclipse versions, so I'd vote for merging unless there is a strong reason to support old Eclipse versions.

        Show
        Richard Eckart de Castilho added a comment - Unfortunately, I didn't have any time to look further into this issue, in particular not for installing different old versions of Eclipse and testing the scenario. It appears that the branch works with recent Eclipse versions, so I'd vote for merging unless there is a strong reason to support old Eclipse versions.
        Hide
        Marshall Schor added a comment -

        +1 to remerge.

        Show
        Marshall Schor added a comment - +1 to remerge.
        Hide
        Peter Klügl added a comment -

        I have problems using it with Eclipse 3.7.2 and I am rather annoyed of Eclipse 4.2.

        I could upgrade my Eclipse... so +0 from my side.

        Show
        Peter Klügl added a comment - I have problems using it with Eclipse 3.7.2 and I am rather annoyed of Eclipse 4.2. I could upgrade my Eclipse... so +0 from my side.
        Hide
        Richard Eckart de Castilho added a comment -

        Per lazy consensus, that would probably count as:

        • +1 : 2 times
        • +0 : 1 time
        • -1 : none

        and would be accepted. Marshall Schor, do you want to merge it?

        Show
        Richard Eckart de Castilho added a comment - Per lazy consensus, that would probably count as: +1 : 2 times +0 : 1 time -1 : none and would be accepted. Marshall Schor , do you want to merge it?
        Hide
        Marshall Schor added a comment -

        To get this to work with Eclipse 3.7.2 (a fresh install), the key was to *not* install m2e from the 3.7.2 Indigo update site (Indigo - http://download.eclipse.org/releases/indigo ) because that installs a "buggy" version of m2e, which I could not get to work. I had tried that first, because that's the "standard" place to go for addon components for the 3.7 release, and there's an m2e there among many others.

        Rather, install m2e from the m2e site: http://eclipse.org/m2e/download/ - I picked the "latest m2e release (recommended)" and that worked quite well.

        For the record, this is version: 1.3.1.20130219-1424 My guess: posted February 19th

        The only other plugin I initially installed into my freshly unzipped 3.7.2 was the Subclipse one. I checked out the UIMA-2560 versions of build and uimaj from the branches, and did a file->import Existing Maven projects. (well, not quite true - I had already fooled around with some editing of the base version - for instance, making the parent pom of the other projects (besides parent-pom) in the build directory point to the 5-SNAPSHOT version of the build parent-pom, so they could inherit the m2e settings.)

        When doing the import, I got some unresolved m2e connector dialogs. These I let m2e search for connectors, and it found and installed various ones, including Tycho. (The "buggy" version of m2e failed when it tried to do this). There was only one it didn't find a connector for - the remote-resources plugin.

        So for that I let it build, and then right clicked one of the errors in the Problems view that said (I don't remember the exact words) something about missing an m2e action, and did the "quick fix" pick in the menu. First I tried to have it discover m2e connectors. For the one it couldn't discover, I told it to update the pom (in my case, the common uima-wide parent pom in "build") to ignore this particular plugin (this is the one which copies boilerplate things into our Jars - standard licenses and notices). We don't need that action for Eclipse builds - and it will still be done for maven builds done outside of Eclipse.

        Peter - if you have a chance, it would be good if you could try this particular version of the m2e plugin in a fresh unzip of 3.7.2, to see if it just starts working for you ( fingers crossed )

        Show
        Marshall Schor added a comment - To get this to work with Eclipse 3.7.2 (a fresh install), the key was to * not * install m2e from the 3.7.2 Indigo update site (Indigo - http://download.eclipse.org/releases/indigo ) because that installs a "buggy" version of m2e, which I could not get to work. I had tried that first, because that's the "standard" place to go for addon components for the 3.7 release, and there's an m2e there among many others. Rather, install m2e from the m2e site: http://eclipse.org/m2e/download/ - I picked the "latest m2e release (recommended)" and that worked quite well. For the record, this is version: 1.3.1.20130219-1424 My guess: posted February 19th The only other plugin I initially installed into my freshly unzipped 3.7.2 was the Subclipse one. I checked out the UIMA-2560 versions of build and uimaj from the branches, and did a file->import Existing Maven projects. (well, not quite true - I had already fooled around with some editing of the base version - for instance, making the parent pom of the other projects (besides parent-pom) in the build directory point to the 5-SNAPSHOT version of the build parent-pom, so they could inherit the m2e settings.) When doing the import, I got some unresolved m2e connector dialogs. These I let m2e search for connectors, and it found and installed various ones, including Tycho. (The "buggy" version of m2e failed when it tried to do this). There was only one it didn't find a connector for - the remote-resources plugin. So for that I let it build, and then right clicked one of the errors in the Problems view that said (I don't remember the exact words) something about missing an m2e action, and did the "quick fix" pick in the menu. First I tried to have it discover m2e connectors. For the one it couldn't discover, I told it to update the pom (in my case, the common uima-wide parent pom in "build") to ignore this particular plugin (this is the one which copies boilerplate things into our Jars - standard licenses and notices). We don't need that action for Eclipse builds - and it will still be done for maven builds done outside of Eclipse. Peter - if you have a chance, it would be good if you could try this particular version of the m2e plugin in a fresh unzip of 3.7.2, to see if it just starts working for you ( fingers crossed )
        Hide
        Richard Eckart de Castilho added a comment -

        Did you try that with on branches of both, the uimaj tree and the parent-pom? I thought I had added all that m2e metadata there to avoid unresolvable connectors.

        Show
        Richard Eckart de Castilho added a comment - Did you try that with on branches of both, the uimaj tree and the parent-pom? I thought I had added all that m2e metadata there to avoid unresolvable connectors.
        Hide
        Marshall Schor added a comment -

        yes, I had loaded both branches - the build and the uimaj. If you start with a fresh unzip of 3.7.2 Eclipse (I use the "classic" build), then m2e discovers it's missing needed connector plugins and offers to get them. What version of 3.7.2 Eclipse build did you start with? Perhaps there's one with the connectors already as part of the download distribution.

        Show
        Marshall Schor added a comment - yes, I had loaded both branches - the build and the uimaj. If you start with a fresh unzip of 3.7.2 Eclipse (I use the "classic" build), then m2e discovers it's missing needed connector plugins and offers to get them. What version of 3.7.2 Eclipse build did you start with? Perhaps there's one with the connectors already as part of the download distribution.
        Hide
        Richard Eckart de Castilho added a comment -

        I didn't try with 3.7.2 so far, only with 4.x. I didn't wonder that it downloaded connectors, only that I apparently didn't add an "ignore" for the remote-resources plugin, for which no connector is available.

        Show
        Richard Eckart de Castilho added a comment - I didn't try with 3.7.2 so far, only with 4.x. I didn't wonder that it downloaded connectors, only that I apparently didn't add an "ignore" for the remote-resources plugin, for which no connector is available.
        Hide
        Peter Klügl added a comment -

        Installed Eclipse 3.7.2 RCP (Win64Bit), installed Subclipse, installed m2e (from site), installed scm handler, applied check out as maven project on all projects in both branch folders.

        m2e complains about:
        Description Resource Path Location Type
        Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:bundle (execution: default, phase: generate-resources) pom.xml /uima-build-resources line 107 Maven Project Build Lifecycle Mapping Problem
        Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uima-build-helper-maven-plugin line 23 Maven Project Build Lifecycle Mapping Problem
        Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uima-build-resources line 23 Maven Project Build Lifecycle Mapping Problem
        Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-eclipse-feature-runtime line 23 Maven Project Build Lifecycle Mapping Problem
        Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-eclipse-feature-tools line 23 Maven Project Build Lifecycle Mapping Problem
        Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-internal-tools line 25 Maven Project Build Lifecycle Mapping Problem

        started Eclipse application, but somehow emf wasn't installed (I even installed our 2.4.0 features and deactivated them):

        org.osgi.framework.BundleException: The bundle "org.apache.uima.jcas.jcasgenp_2.4.1.SNAPSHOT [381]" could not be resolved. Reason: Missing Constraint: Import-Package: org.eclipse.emf.codegen.jmerge; version="0.0.0"

        I will continue by fixing the dependency and then I will report back to you whether the runtime plugin is working correctly.

        Show
        Peter Klügl added a comment - Installed Eclipse 3.7.2 RCP (Win64Bit), installed Subclipse, installed m2e (from site), installed scm handler, applied check out as maven project on all projects in both branch folders. m2e complains about: Description Resource Path Location Type Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:bundle (execution: default, phase: generate-resources) pom.xml /uima-build-resources line 107 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uima-build-helper-maven-plugin line 23 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uima-build-resources line 23 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-eclipse-feature-runtime line 23 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-eclipse-feature-tools line 23 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.uima:uima-build-helper-maven-plugin:2:parse-date-time (execution: set buildYear and buildMonth, phase: validate) pom.xml /uimaj-internal-tools line 25 Maven Project Build Lifecycle Mapping Problem started Eclipse application, but somehow emf wasn't installed (I even installed our 2.4.0 features and deactivated them): org.osgi.framework.BundleException: The bundle "org.apache.uima.jcas.jcasgenp_2.4.1.SNAPSHOT [381] " could not be resolved. Reason: Missing Constraint: Import-Package: org.eclipse.emf.codegen.jmerge; version="0.0.0" I will continue by fixing the dependency and then I will report back to you whether the runtime plugin is working correctly.
        Hide
        Peter Klügl added a comment -

        Fixed the emf problem and now I get an exception when opening the cde:

        java.lang.ClassNotFoundException: org.apache.uima.collection.CollectionReaderDescription

        All my testing was only with m2e, no maven command line.

        Show
        Peter Klügl added a comment - Fixed the emf problem and now I get an exception when opening the cde: java.lang.ClassNotFoundException: org.apache.uima.collection.CollectionReaderDescription All my testing was only with m2e, no maven command line.
        Hide
        Marshall Schor added a comment -

        re: installed m2e (from site) - I presume the site was http://eclipse.org/m2e/download/.

        re: lifecycle mapping problem for remote-resources - I just now checked in an update to parent-pom to "ignore" this, so your next checkout of the build won't show this particular issue

        re: lifecycle mapping problem for uima-build-helper-maven-plugin - I also got that warning. I'm not sure yet what to do about this, if anything, since my ws seems to compile OK.

        re: emf not installed: it may have been deactivated when you deactivated the 2.4.0 uima plugins? When we normally "install" plugins from uima update sites, the install mechanism goes and gets the dependencies plugins and installs them too. I guess we'll need some kind of similar mechanism when plugins are not "installed", but rather the source projects are added to your workspace. I don't know how to do that, but it looks like there's a way, since m2e goes and gets plugins (connectors) dynamically when needed.

        Show
        Marshall Schor added a comment - re: installed m2e (from site) - I presume the site was http://eclipse.org/m2e/download/ . re: lifecycle mapping problem for remote-resources - I just now checked in an update to parent-pom to "ignore" this, so your next checkout of the build won't show this particular issue re: lifecycle mapping problem for uima-build-helper-maven-plugin - I also got that warning. I'm not sure yet what to do about this, if anything, since my ws seems to compile OK. re: emf not installed: it may have been deactivated when you deactivated the 2.4.0 uima plugins? When we normally "install" plugins from uima update sites, the install mechanism goes and gets the dependencies plugins and installs them too. I guess we'll need some kind of similar mechanism when plugins are not "installed", but rather the source projects are added to your workspace. I don't know how to do that, but it looks like there's a way, since m2e goes and gets plugins (connectors) dynamically when needed.
        Hide
        Marshall Schor added a comment -

        re - class not found:

        First of all, I cannot open the CDE in my workspace; it's not "installed". So I'm guessing, that what you're doing is launching an "Eclipse application", and picking plugin-projects to be in it. This simulates "installing" the plugins, but I believe does this by using the target/classes folder as the classpath.

        The problem with this approach is that the construction of the uimaj-ep-runtime plugin only happens when the Jar is built (which never happens, currently, in the m2e builds).

        One workaround may be to run the non-eclipse maven build for the uimaj-ep-runtime plugin (first doing a mvn install on all the projects it, in turn, needs (JARs for)). This could work if the launcher of the eclipse application can be configured to use the built JAR for uimaj-ep-runtime, instead of, or in addition to, the target/classes folder.

        Show
        Marshall Schor added a comment - re - class not found: First of all, I cannot open the CDE in my workspace; it's not "installed". So I'm guessing, that what you're doing is launching an "Eclipse application", and picking plugin-projects to be in it. This simulates "installing" the plugins, but I believe does this by using the target/classes folder as the classpath. The problem with this approach is that the construction of the uimaj-ep-runtime plugin only happens when the Jar is built (which never happens, currently, in the m2e builds). One workaround may be to run the non-eclipse maven build for the uimaj-ep-runtime plugin (first doing a mvn install on all the projects it, in turn, needs (JARs for)). This could work if the launcher of the eclipse application can be configured to use the built JAR for uimaj-ep-runtime, instead of, or in addition to, the target/classes folder.
        Hide
        Peter Klügl added a comment -

        re: installed m2e: yes, I installed it using the site and version you mentioned

        re: emf not installed: yes, that's why I installed the 2.4.0 release (update site), but emf wasn't installed. I just wanted to mention it. Normally that should work just fine.

        re: class not found: yes, I launched an Eclipe Application. That's even my normal use case when working with TextMarker.

        Shouldn't m2e be able to get everything up and working without a manual command line call?
        I already did some testing for this issue before and I thought it worked for a newer Eclipse version. Maybe I missed something, I do some more testing...

        Show
        Peter Klügl added a comment - re: installed m2e: yes, I installed it using the site and version you mentioned re: emf not installed: yes, that's why I installed the 2.4.0 release (update site), but emf wasn't installed. I just wanted to mention it. Normally that should work just fine. re: class not found: yes, I launched an Eclipe Application. That's even my normal use case when working with TextMarker. Shouldn't m2e be able to get everything up and working without a manual command line call? I already did some testing for this issue before and I thought it worked for a newer Eclipse version. Maybe I missed something, I do some more testing...
        Hide
        Peter Klügl added a comment -

        I did a manual mvn install now and the resulting jar (runtime) looks fine: inlined jars and mentions in the manifest. However, when I launch an Eclipse Application and open the CDE, I get java.lang.NoClassDefFoundError: org/apache/uima/util/InvalidXMLException, which is the common indicator that the runtime plugin is empty or its content is not resolvable.

        Does that work for you? This is the situation where I stopped my last testing: It does not work for a launched Eclipse 3.7.2, but when the plugins are installed, it works just fine.

        So, my guess would be that there is no difference between the indigo update site m2e and the m2e of the website concernign this problem.

        Show
        Peter Klügl added a comment - I did a manual mvn install now and the resulting jar (runtime) looks fine: inlined jars and mentions in the manifest. However, when I launch an Eclipse Application and open the CDE, I get java.lang.NoClassDefFoundError: org/apache/uima/util/InvalidXMLException, which is the common indicator that the runtime plugin is empty or its content is not resolvable. Does that work for you? This is the situation where I stopped my last testing: It does not work for a launched Eclipse 3.7.2, but when the plugins are installed, it works just fine. So, my guess would be that there is no difference between the indigo update site m2e and the m2e of the website concernign this problem.
        Hide
        Marshall Schor added a comment -

        A workaround (that Peter might have already discovered), plus a possible explanation to the incident where the mismatch between the uimaj-ep-runtime's embedded JAR names didn't quite match the entries in the MANIFEST.MF.

        First, the workaround: As has been previously noticed, launching an Eclipse Application from within Eclipse fails with m2e for the xxx-runtime plugins, because the Eclipse builds for these only have the manifest, no JARs or target/classes for the collection of other projects these are trying to collect.

        To work around this, for just the xxx-runtime projects, you can run mvn package, and produce the JAR (which, after the fixes in UIMA-2560, no longer copy *and unpack* the other project's JARs, they just copy the entire JAR.

        Now, for the explanation of why this sometimes works and sometimes doesn't, due to a name mismatch between the MANIFEST.MF's classpath and the actual copied JARs. The JARs are copied using Maven's copy dependendencies. This uses a Maven coordinate to get the JAR. The actual Jar then comes from your .m2 repository, or if not there, from a Snapshot Repository, or MavenCentral, etc.

        In this case, what we're looking for is a Jar named xxx-SNAPSHOT. According to Maven conventions, this could be satisfied either with an exact match, or, if the Jar is coming from a Snapshot repository, with a match where the JAR name is something like: uimaj-core-2.4.1-20130410.174534-50.jar.

        In my first try (which failed), the MANIFEST.MF had a classpath with names like uimaj-core-2.4.1-SNAPSHOT, and the copied jar file was uimaj-core-2.4.1-20130410.174534-50.jar. So, of course, the classes couldn't be found.

        The fix was to run mvn install on each of the included projects, which put into my .m2 repository files with the name
        uimaj-core-2.4.1-SNAPSHOT, etc.

        Now, running the mvn package on uimaj-ep-runtime ran the step to copy these artifacts, and Maven's artifact resolution for SNAPSHOTs found the ones with names ending in -SNAPSHOT. With this, my classpath in the MANIFEST.MF and the actual copied names, matched.

        To run, I did two things. In the "hosting" Eclipse, I put in the "dropins" directory the uimaj-ep-runtime-2.4.1-SNAPSHOT.jar, and then restarted the hosting Eclipse. Next, in my run configuration for the launcher for the Eclipse Application, in the "plugins" tab, I changed the pull-down to "Launch with plug-ins selected below only", and then in the top section (Workspace) of the selection of plugins, I uncheck the runtime plugin, and in the bottom section (Target Platform) I check the runtime plugin (coming from the dropin).

        This selection is saved, so you only need to do it once, or when you want to change something.

        With this, my launched Eclipse was able to run the CDE with no problems .

        Show
        Marshall Schor added a comment - A workaround (that Peter might have already discovered), plus a possible explanation to the incident where the mismatch between the uimaj-ep-runtime's embedded JAR names didn't quite match the entries in the MANIFEST.MF. First, the workaround: As has been previously noticed, launching an Eclipse Application from within Eclipse fails with m2e for the xxx-runtime plugins, because the Eclipse builds for these only have the manifest, no JARs or target/classes for the collection of other projects these are trying to collect. To work around this, for just the xxx-runtime projects, you can run mvn package, and produce the JAR (which, after the fixes in UIMA-2560 , no longer copy * and unpack * the other project's JARs, they just copy the entire JAR. Now, for the explanation of why this sometimes works and sometimes doesn't, due to a name mismatch between the MANIFEST.MF's classpath and the actual copied JARs. The JARs are copied using Maven's copy dependendencies. This uses a Maven coordinate to get the JAR. The actual Jar then comes from your .m2 repository, or if not there, from a Snapshot Repository, or MavenCentral, etc. In this case, what we're looking for is a Jar named xxx-SNAPSHOT. According to Maven conventions, this could be satisfied either with an exact match, or, if the Jar is coming from a Snapshot repository, with a match where the JAR name is something like: uimaj-core-2.4.1-20130410.174534-50.jar. In my first try (which failed), the MANIFEST.MF had a classpath with names like uimaj-core-2.4.1-SNAPSHOT, and the copied jar file was uimaj-core-2.4.1-20130410.174534-50.jar. So, of course, the classes couldn't be found. The fix was to run mvn install on each of the included projects, which put into my .m2 repository files with the name uimaj-core-2.4.1-SNAPSHOT, etc. Now, running the mvn package on uimaj-ep-runtime ran the step to copy these artifacts, and Maven's artifact resolution for SNAPSHOTs found the ones with names ending in -SNAPSHOT. With this, my classpath in the MANIFEST.MF and the actual copied names, matched. To run, I did two things. In the "hosting" Eclipse, I put in the "dropins" directory the uimaj-ep-runtime-2.4.1-SNAPSHOT.jar, and then restarted the hosting Eclipse. Next, in my run configuration for the launcher for the Eclipse Application, in the "plugins" tab, I changed the pull-down to "Launch with plug-ins selected below only", and then in the top section (Workspace) of the selection of plugins, I uncheck the runtime plugin, and in the bottom section (Target Platform) I check the runtime plugin (coming from the dropin). This selection is saved, so you only need to do it once, or when you want to change something. With this, my launched Eclipse was able to run the CDE with no problems .
        Hide
        Peter Klügl added a comment -

        Ah ok, but don't you have to replace the jar in the dropins folder, e.g., when you change on uimaj-core? I know, for uimaj SDK in general, this is probably not problematic, but for textmarker it is. I normally test the changes in the rule language with the ide, meaning that the engine plugin (corresponds to the runtime plugin) provides the implementation for the ide plugins. So, I would have to copy the engine jar and have no hot code replacement when debugging (not as if that works now all the time).

        Show
        Peter Klügl added a comment - Ah ok, but don't you have to replace the jar in the dropins folder, e.g., when you change on uimaj-core? I know, for uimaj SDK in general, this is probably not problematic, but for textmarker it is. I normally test the changes in the rule language with the ide, meaning that the engine plugin (corresponds to the runtime plugin) provides the implementation for the ide plugins. So, I would have to copy the engine jar and have no hot code replacement when debugging (not as if that works now all the time).
        Hide
        Marshall Schor added a comment -

        With this approach, you get a "mixed" system - the plugins that are built using the technique of copying JARs into one Jar need to be replace in the dropins folder, but other plugins, written as more "normal" eclipse ones, don't need this special treatment. But, I see your "engine" plugin depends on and includes the "core".

        So, you are correct; this isn't a good workaround. Let's think of a better one

        The ideal would not need any JARs to be built, for the plugins that are in the workspace / under development.

        There would be 2 different builds: one for development, running off of class folders (no Jars), and the other for releases and builds outside of Eclipse. The latter would operate as it does now.

        I wonder if Tycho has some special ability to do good things here?

        Show
        Marshall Schor added a comment - With this approach, you get a "mixed" system - the plugins that are built using the technique of copying JARs into one Jar need to be replace in the dropins folder, but other plugins, written as more "normal" eclipse ones, don't need this special treatment. But, I see your "engine" plugin depends on and includes the "core". So, you are correct; this isn't a good workaround. Let's think of a better one The ideal would not need any JARs to be built, for the plugins that are in the workspace / under development. There would be 2 different builds: one for development, running off of class folders (no Jars), and the other for releases and builds outside of Eclipse. The latter would operate as it does now. I wonder if Tycho has some special ability to do good things here?
        Hide
        Marshall Schor added a comment -

        Peter, do you have way (currently) that works nicely during TextMarker development, without needing to build jars of things? I'm presuming this would be something where if you changed textmarker-core, you could then just launch your testing Eclipse application and it would pick up those changes, without you needing to run special build code. If you have figured out how to do this, could you describe how it's working?

        Show
        Marshall Schor added a comment - Peter, do you have way (currently) that works nicely during TextMarker development, without needing to build jars of things? I'm presuming this would be something where if you changed textmarker-core, you could then just launch your testing Eclipse application and it would pick up those changes, without you needing to run special build code. If you have figured out how to do this, could you describe how it's working?
        Hide
        Marshall Schor added a comment -

        One more experiment: I got the textmarker-ep-engine jar to build "automatically" (that is, by Eclipse's project->clean) by changing its POMs lifecycle mapping to:
        1) not <ignore /> the copy dependencies & unpack (replace <ignore with <execute
        2) not use Tycho, but instead add an lifecycle spec to <execute/> the maven-bundle-plugin
        3) add a lifecycle spec to create the Jar

        Not sure if this is useful, though... but learning a bit more about lifecycle mappings ...

        Show
        Marshall Schor added a comment - One more experiment: I got the textmarker-ep-engine jar to build "automatically" (that is, by Eclipse's project->clean) by changing its POMs lifecycle mapping to: 1) not <ignore /> the copy dependencies & unpack (replace <ignore with <execute 2) not use Tycho, but instead add an lifecycle spec to <execute/> the maven-bundle-plugin 3) add a lifecycle spec to create the Jar Not sure if this is useful, though... but learning a bit more about lifecycle mappings ...
        Hide
        Peter Klügl added a comment -

        Due to recent events, I would postpone my efforts here a bit.

        @Marshall: No, I have no good solution for TextMarker yet. It is built like the other UIMA projects. Tycho can provide some nice stuff, but I already see two problems: the dependency to pom-first bundles and the conflicts for artifact naming (they enforce domain reverse engineering)

        Show
        Peter Klügl added a comment - Due to recent events, I would postpone my efforts here a bit. @Marshall: No, I have no good solution for TextMarker yet. It is built like the other UIMA projects. Tycho can provide some nice stuff, but I already see two problems: the dependency to pom-first bundles and the conflicts for artifact naming (they enforce domain reverse engineering)
        Hide
        Richard Eckart de Castilho added a comment -

        Unless I'm missing something fundamental, FELIX-3061 should take care of properly providing the ep-runtime bundle to "Run as -> Eclipse application" scenarios, and I had the impression that it did last time I tried the branch setup (as reported in the issue comment from 13/Jan/13 22:18 here on this issue).

        Show
        Richard Eckart de Castilho added a comment - Unless I'm missing something fundamental, FELIX-3061 should take care of properly providing the ep-runtime bundle to "Run as -> Eclipse application" scenarios, and I had the impression that it did last time I tried the branch setup (as reported in the issue comment from 13/Jan/13 22:18 here on this issue).
        Hide
        Marshall Schor added a comment -

        OK, I'll try and reproduce this for TextMarker, and then write up the details . The goals - to have a "quick" automatic build in the Eclipse environment, but have the normal build in a non-Eclipse environment. I think this will mean: in Eclipse, if the embedded dependencies are available in the workspace, to include them via their target/classes folder (no need to JAR up those projects). For non-Eclipse, I'm going to try to have this work without unpacking the embedded JARs. As I re-read the comments from 13/Jan/13 - things are slowly beginning to make more sense .

        Show
        Marshall Schor added a comment - OK, I'll try and reproduce this for TextMarker, and then write up the details . The goals - to have a "quick" automatic build in the Eclipse environment, but have the normal build in a non-Eclipse environment. I think this will mean: in Eclipse, if the embedded dependencies are available in the workspace, to include them via their target/classes folder (no need to JAR up those projects). For non-Eclipse, I'm going to try to have this work without unpacking the embedded JARs. As I re-read the comments from 13/Jan/13 - things are slowly beginning to make more sense .
        Hide
        Marshall Schor added a comment -

        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.

        Show
        Marshall Schor added a comment - 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.
        Hide
        Richard Eckart de Castilho added a comment -

        Wow, that's a really in-depth description!

        Show
        Richard Eckart de Castilho added a comment - Wow, that's a really in-depth description!
        Hide
        Marshall Schor added a comment -

        change uima-eclipse-composite-update-site pom's parent-pom back to 4 from 5-SNAPSHOT, because it doesn't need the m2e update, and should not be re-released at this point.

        Show
        Marshall Schor added a comment - change uima-eclipse-composite-update-site pom's parent-pom back to 4 from 5-SNAPSHOT, because it doesn't need the m2e update, and should not be re-released at this point.
        Hide
        Richard Eckart de Castilho added a comment -

        Any objections to deleting the branch for this issue from svn?

        Show
        Richard Eckart de Castilho added a comment - Any objections to deleting the branch for this issue from svn?
        Hide
        Marshall Schor added a comment -

        no objections from me. We can always get it back if needed.

        Show
        Marshall Schor added a comment - no objections from me. We can always get it back if needed.

          People

          • Assignee:
            Marshall Schor
            Reporter:
            Richard Eckart de Castilho
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development