Karaf
  1. Karaf
  2. KARAF-1048

make pom.xml eclipse 3.7 m2e friendly

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.10, 2.3.0, 3.0.0
    • Component/s: karaf-core
    • Labels:
      None

      Description

      currently it is impossible to import karaf projects from svn in
      eclipse 3.7 with m2e integration w/o need to manually
      provide m2e life cycle entries such as this,
      for all kinds of plugins

      ##################################

      <!-This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.->
      <plugin>
      <groupId>org.eclipse.m2e</groupId>
      <artifactId>lifecycle-mapping</artifactId>
      <version>1.0.0</version>
      <configuration>
      <lifecycleMappingMetadata>
      <pluginExecutions>
      <pluginExecution>
      <pluginExecutionFilter>
      <groupId>
      org.apache.felix
      </groupId>
      <artifactId>
      maven-bundle-plugin
      </artifactId>
      <versionRange>
      [2.3.5,)
      </versionRange>
      <goals>
      <goal>cleanVersions</goal>
      </goals>
      </pluginExecutionFilter>
      <action>
      <ignore></ignore>
      </action>
      </pluginExecution>
      </pluginExecutions>
      </lifecycleMappingMetadata>
      </configuration>
      </plugin>

      1. KARAF-1048.patch
        17 kB
        Jean-Baptiste Onofré

        Activity

        Hide
        Jean-Baptiste Onofré added a comment -

        Agree, it makes sense to include it in the "github doc".

        Show
        Jean-Baptiste Onofré added a comment - Agree, it makes sense to include it in the "github doc".
        Hide
        Andrei Pozolotin added a comment -

        got it; closed. probably should reflect this rule in "github contributor notes".

        Show
        Andrei Pozolotin added a comment - got it; closed. probably should reflect this rule in "github contributor notes".
        Hide
        Jean-Baptiste Onofré added a comment -

        We can close it. It's better that you do that as you are the author of the pull request.

        Show
        Jean-Baptiste Onofré added a comment - We can close it. It's better that you do that as you are the author of the pull request.
        Hide
        Andrei Pozolotin added a comment -

        I am curious what should be done about the original pull request
        https://github.com/apache/karaf/pull/5

        should it be closed? by whom?

        Show
        Andrei Pozolotin added a comment - I am curious what should be done about the original pull request https://github.com/apache/karaf/pull/5 should it be closed? by whom?
        Hide
        Jean-Baptiste Onofré added a comment -
        Show
        Jean-Baptiste Onofré added a comment - Adapted and applied on karaf-2.2.x: http://svn.apache.org/viewvc?view=revision&revision=1374677
        Hide
        Jean-Baptiste Onofré added a comment -
        Show
        Jean-Baptiste Onofré added a comment - Adapted and applied on karaf-2.3.x: http://svn.apache.org/viewvc?view=revision&revision=1374674
        Hide
        Andrei Pozolotin added a comment -

        great, thank you!

        Show
        Andrei Pozolotin added a comment - great, thank you!
        Show
        Jean-Baptiste Onofré added a comment - Applied on trunk: http://svn.apache.org/viewvc?view=revision&revision=1374509
        Hide
        Jean-Baptiste Onofré added a comment -

        I will review and commit.

        Show
        Jean-Baptiste Onofré added a comment - I will review and commit.
        Hide
        Andrei Pozolotin added a comment -

        JB: please commit the patch; thanks, Andrei.

        Show
        Andrei Pozolotin added a comment - JB: please commit the patch; thanks, Andrei.
        Hide
        Christian Schneider added a comment -

        I think we can move this to 3.1. Feel free to move back if you want to include it in 3.0

        Show
        Christian Schneider added a comment - I think we can move this to 3.1. Feel free to move back if you want to include it in 3.0
        Hide
        David Jencks added a comment -

        I asked on the felix list about including more m2e metadata in maven-bundle plugin and Stuart McCulloch (who ought to know said...

        1. At Karaf someone recently complained about m2e integration and pointed to http://wiki.eclipse.org/M2E_plugin_execution_not_covered which IIUC suggests that the maven-bundle-plugin could include some m2e specific metadata to help m2e figure out what it does. The karaf discussion is here: https://issues.apache.org/jira/browse/KARAF-1048 Anyone know anything about this?

        The m2e Tycho Project Configurators support the bundle lifecycle via the maven-bundle-plugin, including regenerating the manifest when classes or bnd instructions change and integration with the PDE launcher:

        https://repository.sonatype.org/content/repositories/forge-sites/m2eclipse-tycho/0.6.0/N/0.6.0.201110151902/
        ( update site, also available for installation via Eclipse->Preferences...>Maven>Discovery->Open Catalog )

        https://github.com/sonatype/m2eclipse-tycho/

        PS. if you see the warning about missing lifecycle mappings when importing your project just use the "auto select" button (or quick fix on the pom) and it should search for available connectors on the online catalog.

        Show
        David Jencks added a comment - I asked on the felix list about including more m2e metadata in maven-bundle plugin and Stuart McCulloch (who ought to know said... 1. At Karaf someone recently complained about m2e integration and pointed to http://wiki.eclipse.org/M2E_plugin_execution_not_covered which IIUC suggests that the maven-bundle-plugin could include some m2e specific metadata to help m2e figure out what it does. The karaf discussion is here: https://issues.apache.org/jira/browse/KARAF-1048 Anyone know anything about this? The m2e Tycho Project Configurators support the bundle lifecycle via the maven-bundle-plugin, including regenerating the manifest when classes or bnd instructions change and integration with the PDE launcher: https://repository.sonatype.org/content/repositories/forge-sites/m2eclipse-tycho/0.6.0/N/0.6.0.201110151902/ ( update site, also available for installation via Eclipse->Preferences... >Maven >Discovery->Open Catalog ) https://github.com/sonatype/m2eclipse-tycho/ PS. if you see the warning about missing lifecycle mappings when importing your project just use the "auto select" button (or quick fix on the pom) and it should search for available connectors on the online catalog.
        Hide
        Glen Mazza added a comment -

        @David, re "I barely use eclipse at all but in my experience mvn eclipse:eclipse is much less effective than m2e at getting a working accurate eclipse project that corresponds to the maven project structure. If the maven eclipse plugin ever catches up, great, but I'm not holding my breath."

        I almost always use Eclipse and I've used mvn eclipse:eclipse pretty much without problem for the past 3-4 years, it does the job fine for me with the CXF and Metro source bases (in terms of bringing in source libraries so I can debug within the IDE). The difference may be that I never build within the IDE, I still use a command prompt window for that. Also, the downloadSources and useProjectReferences values need to be set properly (either at command line or as shown in the DoubleIt/pom.xml here: http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep3) depending on what you want. I asked Dan K of the CXF team about that yesterday, he's also been using mvn eclipse:eclipse with both Camel and CXF source code for some time now, and doesn't have a present need to switch to m2e.

        Show
        Glen Mazza added a comment - @David, re "I barely use eclipse at all but in my experience mvn eclipse:eclipse is much less effective than m2e at getting a working accurate eclipse project that corresponds to the maven project structure. If the maven eclipse plugin ever catches up, great, but I'm not holding my breath." I almost always use Eclipse and I've used mvn eclipse:eclipse pretty much without problem for the past 3-4 years, it does the job fine for me with the CXF and Metro source bases (in terms of bringing in source libraries so I can debug within the IDE). The difference may be that I never build within the IDE, I still use a command prompt window for that. Also, the downloadSources and useProjectReferences values need to be set properly (either at command line or as shown in the DoubleIt/pom.xml here: http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep3 ) depending on what you want. I asked Dan K of the CXF team about that yesterday, he's also been using mvn eclipse:eclipse with both Camel and CXF source code for some time now, and doesn't have a present need to switch to m2e.
        Hide
        Andreas Pieber added a comment -

        OK, I've reverted my last patch since it breaks the build; there are quite more issues/fixes included here. Making the project easy to import in eclipse is not done by only adding the m2e stuff but only by cleaning up the entire pom structure. Therefore I'm sorry but I think I won't fix this on the 2.x branch because of the real work load. In addition I'm a little bit afraid of changing the pom structure for a micro release branch tbh. Maybe for 2.3.0. 3.0.0 should be eclipse friendly soon though.

        Show
        Andreas Pieber added a comment - OK, I've reverted my last patch since it breaks the build; there are quite more issues/fixes included here. Making the project easy to import in eclipse is not done by only adding the m2e stuff but only by cleaning up the entire pom structure. Therefore I'm sorry but I think I won't fix this on the 2.x branch because of the real work load. In addition I'm a little bit afraid of changing the pom structure for a micro release branch tbh. Maybe for 2.3.0. 3.0.0 should be eclipse friendly soon though.
        Hide
        Andreas Pieber added a comment -

        [pieber@prime karaf]$ git svn rebase
        M pom.xml
        M shell/console/pom.xml
        M itests/kittests/pom.xml
        r1209165 = 7e0a20c6b14ee6e3ab7cadae5bd4881353bd4389 (refs/remotes/origin/trunk)

        now let's see what have to be done for the 2.2.x branch

        Show
        Andreas Pieber added a comment - [pieber@prime karaf] $ git svn rebase M pom.xml M shell/console/pom.xml M itests/kittests/pom.xml r1209165 = 7e0a20c6b14ee6e3ab7cadae5bd4881353bd4389 (refs/remotes/origin/trunk) now let's see what have to be done for the 2.2.x branch
        Hide
        Andreas Pieber added a comment -

        well, it's rather making karaf eclipse friendly. I also often have problems with eclipse:eclipse...

        Show
        Andreas Pieber added a comment - well, it's rather making karaf eclipse friendly. I also often have problems with eclipse:eclipse...
        Hide
        Andreas Pieber added a comment -

        OK, thanks to Achim I really started using m2e again. I also account the same issue and I still don't consider it harmful adding those entries into the root pom. I'll configure the builds for master and 2.2.x. If there are no -1 I'll push them within the next days.

        Show
        Andreas Pieber added a comment - OK, thanks to Achim I really started using m2e again. I also account the same issue and I still don't consider it harmful adding those entries into the root pom. I'll configure the builds for master and 2.2.x. If there are no -1 I'll push them within the next days.
        Hide
        Andrei Pozolotin added a comment -

        @Andreas

        1) re "Therefore I'm still +1." - thank you for considering this;

        2) re "a poll might be a little bit over-engineering" - the poll
        is not specifically related to this problem, I just want to learn more
        about apache karaf community; so I would like to see something like this:

        http://www.scala-lang.org/node/273

        Poll
        What do you use to develop Scala code?
        Eclipse
        42%
        IntelliJ Idea
        22%
        Netbeans
        11%
        Emacs
        7%
        TextMate
        3%
        vim
        12%
        Crystal ball
        3%
        Total votes: 13574

        Show
        Andrei Pozolotin added a comment - @Andreas 1) re "Therefore I'm still +1." - thank you for considering this; 2) re "a poll might be a little bit over-engineering" - the poll is not specifically related to this problem, I just want to learn more about apache karaf community; so I would like to see something like this: http://www.scala-lang.org/node/273 Poll What do you use to develop Scala code? Eclipse 42% IntelliJ Idea 22% Netbeans 11% Emacs 7% TextMate 3% vim 12% Crystal ball 3% Total votes: 13574
        Hide
        Andreas Pieber added a comment -

        I finally had a chance to evaluate the problem on an empty eclipse 3.7.1. It's as simple as

        a) download eclipse 3.7.1 for java developers (or any other distribution)
        b) checkout karaf source
        c) import as existing maven project
        d) Use autoresolve to install the existing plugins

        This problem can be easily resolved by adding the Andrei's "patch" to the Karaf root pom. It's as the plugin itself states (if you let it autogenerate the section in the root pom): "This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself." I don't say that I like that those environment specific settings are stored in the pom, it's just that I don't consider them harmful as long they require only a small section in the root pom.

        This is also not really related to our plugins; we might provide own mappers for m2e but I not right now I think since other projects using Karaf can simply exclude them as we would do here for the maven-bundle-plugin.

        I don't say that I'm happy with what sonatype is doing here! We would definitely have to be very careful here to not integrating them any further; but for now I consider them as "not harmful"... Therefore I'm still +1.

        we might still want to bring this topic to the dev list getting a little bit more feedback first? I think a poll might be a little bit over-engineering of the problem

        Show
        Andreas Pieber added a comment - I finally had a chance to evaluate the problem on an empty eclipse 3.7.1. It's as simple as a) download eclipse 3.7.1 for java developers (or any other distribution) b) checkout karaf source c) import as existing maven project d) Use autoresolve to install the existing plugins This problem can be easily resolved by adding the Andrei's "patch" to the Karaf root pom. It's as the plugin itself states (if you let it autogenerate the section in the root pom): "This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself." I don't say that I like that those environment specific settings are stored in the pom, it's just that I don't consider them harmful as long they require only a small section in the root pom. This is also not really related to our plugins; we might provide own mappers for m2e but I not right now I think since other projects using Karaf can simply exclude them as we would do here for the maven-bundle-plugin. I don't say that I'm happy with what sonatype is doing here! We would definitely have to be very careful here to not integrating them any further; but for now I consider them as "not harmful"... Therefore I'm still +1. we might still want to bring this topic to the dev list getting a little bit more feedback first? I think a poll might be a little bit over-engineering of the problem
        Hide
        Andrei Pozolotin added a comment -

        @David: re "it is really inappropriate"

        1) got it; sorry!

        2) I merely started my evaluation of karaf today,
        got the source out, and reported the first issue I stumbled on;

        3) I suggest to post a poll somewhere, like:
        what ide you use? / do you use maven? / do you use m2e?
        to better understand your developers / users.

        Show
        Andrei Pozolotin added a comment - @David: re "it is really inappropriate" 1) got it; sorry! 2) I merely started my evaluation of karaf today, got the source out, and reported the first issue I stumbled on; 3) I suggest to post a poll somewhere, like: what ide you use? / do you use maven? / do you use m2e? to better understand your developers / users.
        Hide
        David Jencks added a comment -

        Andrei, it is really inappropriate to conduct discussions like this in jira comments. The mailing list is the appropriate place.

        The link you supplied, http://wiki.eclipse.org/M2E_plugin_execution_not_covered, indicates that you can fix the lifecycle problems a project at a time or in the plugins by adding m2e specific metadata. I'm suggesting that we add the m2e specific metadata to all the plugins we use. It should be the same amount of work and be useful to everyone using these plugins.

        @Glen I barely use eclipse at all but in my experience mvn eclipse:eclipse is much less effective than m2e at getting a working accurate eclipse project that corresponds to the maven project structure. If the maven eclipse plugin ever catches up, great, but I'm not holding my breath.

        Show
        David Jencks added a comment - Andrei, it is really inappropriate to conduct discussions like this in jira comments. The mailing list is the appropriate place. The link you supplied, http://wiki.eclipse.org/M2E_plugin_execution_not_covered , indicates that you can fix the lifecycle problems a project at a time or in the plugins by adding m2e specific metadata. I'm suggesting that we add the m2e specific metadata to all the plugins we use. It should be the same amount of work and be useful to everyone using these plugins. @Glen I barely use eclipse at all but in my experience mvn eclipse:eclipse is much less effective than m2e at getting a working accurate eclipse project that corresponds to the maven project structure. If the maven eclipse plugin ever catches up, great, but I'm not holding my breath.
        Hide
        Andrei Pozolotin added a comment -

        @Andreas re "What's special about the setup?"
        nothing. just enough complexity so I can not get without m2e.
        no nightmares, though

        Show
        Andrei Pozolotin added a comment - @Andreas re "What's special about the setup?" nothing. just enough complexity so I can not get without m2e. no nightmares, though
        Hide
        Andreas Pieber added a comment -

        @Glen I understood it from the beginning as Andrei stated now; and don't paint such scary pictures (... lose IDE independence as well); otherwise I can't sleep tonight because of the nightmares

        @Andrei: What's special about the setup? Isn't it enough to take a plain eclipse 3.7.1 for java developers to reproduce it?

        Show
        Andreas Pieber added a comment - @Glen I understood it from the beginning as Andrei stated now; and don't paint such scary pictures (... lose IDE independence as well); otherwise I can't sleep tonight because of the nightmares @Andrei: What's special about the setup? Isn't it enough to take a plain eclipse 3.7.1 for java developers to reproduce it?
        Hide
        Achim Nierbeck added a comment - - edited

        @Andrei: after trying this it doesn't work with the following message - This profile can not be resolved because required software could not be located.

        Show
        Achim Nierbeck added a comment - - edited @Andrei: after trying this it doesn't work with the following message - This profile can not be resolved because required software could not be located.
        Hide
        Andrei Pozolotin added a comment -

        @Glen:

        I am not asking to build karaf with m2e, merely be friendly

        re: "and this is just one declaration in a parent-level POM" - YES.

        Show
        Andrei Pozolotin added a comment - @Glen: I am not asking to build karaf with m2e, merely be friendly re: "and this is just one declaration in a parent-level POM" - YES.
        Hide
        Glen Mazza added a comment -

        @Andreas, no I think Andrei was being too quickly dismissive over the Maven Eclipse plugin, which is still alive and well. The link Andrei gave in (1) gives further cause for concern, as it seems to imply (if I'm understanding it correctly) that m2e is now doing a build process procedure different from what Maven proper would use.

        We don't use m2e (or Eclipse for that matter) to build Karaf-we use IDE-independent Maven-"mvn clean install" is the one authoritative and official way to build the application, regardless of the IDE you use. m2e is primarily a cute graphical tool for Eclipse users who don't like having a command window open for building and using mvn eclipse:eclipse to import their projects into Eclipse. Now, with the latest version m2e apparently wants to do its own build process following its own build algorithm. I'm not sure supporting multiple build processes (m2e and Maven proper) is a good idea.

        My initial concern is that m2e is requiring declarations in POM files, as well as discontinuing support of the output generated by mvn eclipse:eclipse, to get a listing in everybody's POMs with the eventual goal of requiring Eclipse and m2e usage whenever you want to build a Mavenized application. But perhaps that is unlikely, and this is just one declaration in a parent-level POM and everything's OK. If so, fine. But be careful that this doesn't get more intrusive over the poms, as we need to make more and more pom.xml changes for m2e builds to work, eventually becoming dependent on m2e as pure-Maven builds no longer work. And when you become dependent on m2e for your builds, then you lose IDE independence as well.

        Show
        Glen Mazza added a comment - @Andreas, no I think Andrei was being too quickly dismissive over the Maven Eclipse plugin, which is still alive and well. The link Andrei gave in (1) gives further cause for concern, as it seems to imply (if I'm understanding it correctly) that m2e is now doing a build process procedure different from what Maven proper would use. We don't use m2e (or Eclipse for that matter) to build Karaf- we use IDE-independent Maven -"mvn clean install" is the one authoritative and official way to build the application, regardless of the IDE you use. m2e is primarily a cute graphical tool for Eclipse users who don't like having a command window open for building and using mvn eclipse:eclipse to import their projects into Eclipse. Now, with the latest version m2e apparently wants to do its own build process following its own build algorithm. I'm not sure supporting multiple build processes (m2e and Maven proper) is a good idea. My initial concern is that m2e is requiring declarations in POM files, as well as discontinuing support of the output generated by mvn eclipse:eclipse, to get a listing in everybody's POMs with the eventual goal of requiring Eclipse and m2e usage whenever you want to build a Mavenized application. But perhaps that is unlikely, and this is just one declaration in a parent-level POM and everything's OK. If so, fine. But be careful that this doesn't get more intrusive over the poms, as we need to make more and more pom.xml changes for m2e builds to work, eventually becoming dependent on m2e as pure-Maven builds no longer work. And when you become dependent on m2e for your builds, then you lose IDE independence as well.
        Hide
        Andrei Pozolotin added a comment -

        @Achim: re "wouldn't it be easier"
        I do not know how to do what you suggest; but I sent you invite also

        Show
        Andrei Pozolotin added a comment - @Achim: re "wouldn't it be easier" I do not know how to do what you suggest; but I sent you invite also
        Hide
        Achim Nierbeck added a comment -

        wouldn't it be easier to place something like this at github/gist/..., so it's more open and more people can take a look at it?

        Show
        Achim Nierbeck added a comment - wouldn't it be easier to place something like this at github/gist/..., so it's more open and more people can take a look at it?
        Hide
        Andrei Pozolotin added a comment -

        @David, @Glen, @Andreas:

        I shared with you my current eclipse 3.7 profile via pulse:
        http://www.poweredbypulse.com/

        you can try to import karaf svn source and see what comes up.

        Show
        Andrei Pozolotin added a comment - @David, @Glen, @Andreas: I shared with you my current eclipse 3.7 profile via pulse: http://www.poweredbypulse.com/ you can try to import karaf svn source and see what comes up.
        Hide
        Andrei Pozolotin added a comment -

        @Andreas: "I think this issue is to import karaf directly into eclipse 3.7"
        yes. the idea not to store any ide meta data, such .project file
        in source repository, instead use m2e to auto make these files on import.

        Show
        Andrei Pozolotin added a comment - @Andreas: "I think this issue is to import karaf directly into eclipse 3.7" yes. the idea not to store any ide meta data, such .project file in source repository, instead use m2e to auto make these files on import.
        Hide
        Andrei Pozolotin added a comment -

        @Glen: re: "I don't see how "mvn eclipse:eclipse" can be legacy"
        both "mvn eclipse:eclipse" and "m2e" created the same eclipse ide
        files such as ".project", ".settings/*", etc
        they do it in conflicting ways; but m2e supposed to be "correct";
        for most people using eclipse 3.7 m2e comes installed there by default;
        so they will never use "mvn eclipse:eclipse"
        probably it would make sense to drop it;

        Show
        Andrei Pozolotin added a comment - @Glen: re: "I don't see how "mvn eclipse:eclipse" can be legacy" both "mvn eclipse:eclipse" and "m2e" created the same eclipse ide files such as ".project", ".settings/*", etc they do it in conflicting ways; but m2e supposed to be "correct"; for most people using eclipse 3.7 m2e comes installed there by default; so they will never use "mvn eclipse:eclipse" probably it would make sense to drop it;
        Hide
        Andrei Pozolotin added a comment -

        @David: "Shouldn't this be bugs against ..."

        the issue is not plug-in specific;
        historically maven plug-ins are created as ide-agnostic;
        but now in eclipse 3.7, when m2e integrates these plug-ins in eclipse jdt
        incremental build life cycle, m2e must know which plug-in goals to run or not

        Show
        Andrei Pozolotin added a comment - @David: "Shouldn't this be bugs against ..." the issue is not plug-in specific; historically maven plug-ins are created as ide-agnostic; but now in eclipse 3.7, when m2e integrates these plug-ins in eclipse jdt incremental build life cycle, m2e must know which plug-in goals to run or not
        Hide
        Andreas Pieber added a comment -

        @Glen: me neither, but I think Andrei meant that m2e does not longer use mvn eclipse:eclipse to create the project files, don't you?

        Show
        Andreas Pieber added a comment - @Glen: me neither, but I think Andrei meant that m2e does not longer use mvn eclipse:eclipse to create the project files, don't you?
        Hide
        Andreas Pieber added a comment -

        @Andrei:

        I'm not happy about this, but after flying over the link I think that we have to add this... Any other concerns? otherwise I'll add this to the root pom in trunk and 2.x.

        @David: I think this issue is to import karaf directly into eclipse 3.7; isn't it?

        Kind regards,
        Andreas

        Show
        Andreas Pieber added a comment - @Andrei: I'm not happy about this, but after flying over the link I think that we have to add this... Any other concerns? otherwise I'll add this to the root pom in trunk and 2.x. @David: I think this issue is to import karaf directly into eclipse 3.7; isn't it? Kind regards, Andreas
        Hide
        Glen Mazza added a comment -

        Andrei, re (2), I don't see how "mvn eclipse:eclipse" can be legacy w.r.t. m2e, as it never needed m2e to begin with. Further, it's a plugin that creates classpath and project files that Eclipse can use, so it's not an issue of Eclipse supporting it but of the plugin being up-to-date and creating project files that Eclipse can use. I don't see any indication from the Maven site that the Maven Eclipse plugin (http://maven.apache.org/plugins/maven-eclipse-plugin/) is going to be retired and no longer maintained/updated.

        Show
        Glen Mazza added a comment - Andrei, re (2), I don't see how "mvn eclipse:eclipse" can be legacy w.r.t. m2e, as it never needed m2e to begin with. Further, it's a plugin that creates classpath and project files that Eclipse can use, so it's not an issue of Eclipse supporting it but of the plugin being up-to-date and creating project files that Eclipse can use. I don't see any indication from the Maven site that the Maven Eclipse plugin ( http://maven.apache.org/plugins/maven-eclipse-plugin/ ) is going to be retired and no longer maintained/updated.
        Hide
        David Jencks added a comment -

        Shouldn't this be bugs against maven-bundle-plugin (in felix) and karaf-maven-plugin (so project that use karaf-maven-plugin don't need this configuration)?

        Show
        David Jencks added a comment - Shouldn't this be bugs against maven-bundle-plugin (in felix) and karaf-maven-plugin (so project that use karaf-maven-plugin don't need this configuration)?
        Hide
        Andrei Pozolotin added a comment -

        1) re: "why this is required" - full story:
        http://wiki.eclipse.org/M2E_plugin_execution_not_covered

        2) re: "mvn eclipse:eclipse" is now legacy,
        no longer supported with current eclipse 3.7 + m2e

        Show
        Andrei Pozolotin added a comment - 1) re: "why this is required" - full story: http://wiki.eclipse.org/M2E_plugin_execution_not_covered 2) re: "mvn eclipse:eclipse" is now legacy, no longer supported with current eclipse 3.7 + m2e
        Hide
        Andreas Pieber added a comment -

        I second Glen on that one; would be interesting why this is required... Still if this is really the only way I'm not against adding it (since it wont affect anything else and we also define/configure the mvn eclipse:eclipse plugin the poms).

        Show
        Andreas Pieber added a comment - I second Glen on that one; would be interesting why this is required... Still if this is really the only way I'm not against adding it (since it wont affect anything else and we also define/configure the mvn eclipse:eclipse plugin the poms).
        Hide
        Glen Mazza added a comment -

        Hmm, I believe others have been successfully using the m2e plugin. But might the bug be with m2e in not being able to work without such a plugin declaration? It seems strange to require all Apache projects to link to (actually, advertise) the org.eclipse.m2e plugin, especially since you can accomplish much the same Eclipse integration command-line via "mvn eclipse:eclipse".

        Show
        Glen Mazza added a comment - Hmm, I believe others have been successfully using the m2e plugin. But might the bug be with m2e in not being able to work without such a plugin declaration? It seems strange to require all Apache projects to link to (actually, advertise) the org.eclipse.m2e plugin, especially since you can accomplish much the same Eclipse integration command-line via "mvn eclipse:eclipse".

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Andrei Pozolotin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development