Maven Eclipse Plugin
  1. Maven Eclipse Plugin
  2. MECLIPSE-37

eclipse:eclipse should execute in a later phase than "generate-sources"

    Details

      Description

      the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources)
      as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots.

      If it runs later, added paths will be written correctly to the .classpath.

      Suggested phase is "test"

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          28d 18h 39m 1 fabrizio giustina 28/Dec/05 07:14
          Closed Closed Reopened Reopened
          41d 2h 22m 1 kenneyw 07/Feb/06 09:37
          Reopened Reopened Closed Closed
          3213d 5h 10m 1 Michael Osipov 25/Nov/14 14:47
          Mark Thomas made changes -
          Workflow jira [ 12957968 ] Default workflow, editable Closed status [ 12994730 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 23:47:18 UTC 2015 [ 1428277638729 ]
          Mark Thomas made changes -
          Workflow jira [ 12720465 ] Default workflow, editable Closed status [ 12750992 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 10:00:37 UTC 2015 [ 1428228037919 ]
          Michael Osipov made changes -
          Fix Version/s 3.0 [ 14137 ]
          Michael Osipov made changes -
          Resolution Won't Fix [ 2 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          Hide
          Michael Osipov added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Michael Osipov added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.
          Arnaud HERITIER made changes -
          Assignee Arnaud Heritier [ aheritier ]
          Hide
          Oleksandr Maksymchuk added a comment -

          As maven 2.1 is out is there any updates?

          Show
          Oleksandr Maksymchuk added a comment - As maven 2.1 is out is there any updates?
          Barrie Treloar made changes -
          Fix Version/s 3.0 [ 14137 ]
          Fix Version/s 2.6 [ 14163 ]
          Hide
          Barrie Treloar added a comment -

          This can't be done in Maven 2.0.x. May have to wait for Maven 2.1 or 3.0

          Show
          Barrie Treloar added a comment - This can't be done in Maven 2.0.x. May have to wait for Maven 2.1 or 3.0
          Hide
          Barrie Treloar added a comment -

          I'd appreciate comments to http://www.nabble.com/MECLIPSE-37-creating-a-new-custom-lifecycle-for-m-eclipse-p-td20846234.html as I've come to the conclusion that I dont know how to implement this and that it is most likely impossible to create a custom lifecycle.

          Show
          Barrie Treloar added a comment - I'd appreciate comments to http://www.nabble.com/MECLIPSE-37-creating-a-new-custom-lifecycle-for-m-eclipse-p-td20846234.html as I've come to the conclusion that I dont know how to implement this and that it is most likely impossible to create a custom lifecycle.
          Benjamin LERMAN made changes -
          Attachment patch-eclipse-eclipse [ 37456 ]
          Hide
          Benjamin LERMAN added a comment -

          the attached patch set the lifecycle of the plugin to initialize, generate-sources, generate-resources, generate-test-sources, generate-test-resources

          Show
          Benjamin LERMAN added a comment - the attached patch set the lifecycle of the plugin to initialize, generate-sources, generate-resources, generate-test-sources, generate-test-resources
          Hide
          Benjamin Bentmann added a comment -

          With regard to MENFORCER-42, we should probably only execute generate-* phases and exclude anything else, in particular validate.

          Show
          Benjamin Bentmann added a comment - With regard to MENFORCER-42 , we should probably only execute generate-* phases and exclude anything else, in particular validate .
          Arnaud HERITIER made changes -
          Fix Version/s 2.5.2 [ 14163 ]
          Arnaud HERITIER made changes -
          Assignee fabrizio giustina [ fgiust ] Arnaud Heritier [ aheritier ]
          Hide
          Arnaud HERITIER added a comment -

          I agree. I proposed this quickly. I don't think we need process-* and *-integration-test phases.

          Show
          Arnaud HERITIER added a comment - I agree. I proposed this quickly. I don't think we need process-* and *-integration-test phases.
          Hide
          Benjamin Bentmann added a comment -

          I think we'll create a custom lifecycle for the eclipse plugin with following phases :

          Hm, never thought about this, looks like a great idea! Just two questions:

          Do we really need the process-* phases? For instance, process-resources is usually used to copy the files over to "target/classes", it doesn't create new source folders, does it? Especially if one has many resources (think about the core-it's to name just one example) excluding this phase would safe further time.

          Likewise, is including *-integration-test sensible? For instance, many of the Maven plugins use pre-integration-test to install the JAR to a test repo or - even more time consuming - to create a staging repo.

          Hence, maybe just:

          <phases>
            <phase>validate</phase>
            <phase>initialize</phase>
            <phase>generate-sources</phase>
            <phase>generate-resources</phase>
            <phase>generate-test-sources</phase>
            <phase>generate-test-resources</phase>
          </phases>
          
          Show
          Benjamin Bentmann added a comment - I think we'll create a custom lifecycle for the eclipse plugin with following phases : Hm, never thought about this, looks like a great idea! Just two questions: Do we really need the process-* phases? For instance, process-resources is usually used to copy the files over to "target/classes", it doesn't create new source folders, does it? Especially if one has many resources (think about the core-it's to name just one example) excluding this phase would safe further time. Likewise, is including *-integration-test sensible? For instance, many of the Maven plugins use pre-integration-test to install the JAR to a test repo or - even more time consuming - to create a staging repo. Hence, maybe just: <phases> <phase> validate </phase> <phase> initialize </phase> <phase> generate-sources </phase> <phase> generate-resources </phase> <phase> generate-test-sources </phase> <phase> generate-test-resources </phase> </phases>
          Hide
          Arnaud HERITIER added a comment -

          I think we'll create a custom lifecycle for the eclipse plugin with following phases :

                      <phases>
                        <phase>validate</phase>
                        <phase>initialize</phase>
                        <phase>generate-sources</phase>
                        <phase>process-sources</phase>
                        <phase>generate-resources</phase>
                        <phase>process-resources</phase>
                        <phase>generate-test-sources</phase>
                        <phase>process-test-sources</phase>
                        <phase>generate-test-resources</phase>
                        <phase>process-test-resources</phase>
                        <phase>pre-integration-test</phase>
                        <phase>post-integration-test</phase>
                      </phases>
          

          WDYT ?

          Show
          Arnaud HERITIER added a comment - I think we'll create a custom lifecycle for the eclipse plugin with following phases : <phases> <phase> validate </phase> <phase> initialize </phase> <phase> generate-sources </phase> <phase> process-sources </phase> <phase> generate-resources </phase> <phase> process-resources </phase> <phase> generate-test-sources </phase> <phase> process-test-sources </phase> <phase> generate-test-resources </phase> <phase> process-test-resources </phase> <phase> pre-integration-test </phase> <phase> post-integration-test </phase> </phases> WDYT ?
          Hide
          Benjamin Bentmann added a comment -

          Currently I think only a new mojo can do the trick since the @execute phase is not runtime configurable.

          +1, there should be a simple mojo (eclipse:eclipse) that is always capable of generating the project metadata regardless or compilation errors.

          Show
          Benjamin Bentmann added a comment - Currently I think only a new mojo can do the trick since the @execute phase is not runtime configurable. +1, there should be a simple mojo ( eclipse:eclipse ) that is always capable of generating the project metadata regardless or compilation errors.
          Hide
          Arnaud HERITIER added a comment -

          A patch is provided in MECLIPSE-409

          Show
          Arnaud HERITIER added a comment - A patch is provided in MECLIPSE-409
          Mark Hobson made changes -
          Link This issue is duplicated by MECLIPSE-409 [ MECLIPSE-409 ]
          Hide
          nicolas de loof added a comment -

          Just a comment about "Kenney Westerhof - 06/oct./06 07:51 PM
          First - only the generate-* phases should add (test)compileSourceRoots. "

          I had to create a plugin to run the castor MappingTool. This one process class file to generate XML mappings.
          It then fit naturaly in the process-classes phase, and REQUIRE the sources to be compiled prior to execution

          Show
          nicolas de loof added a comment - Just a comment about "Kenney Westerhof - 06/oct./06 07:51 PM First - only the generate-* phases should add (test)compileSourceRoots. " I had to create a plugin to run the castor MappingTool. This one process class file to generate XML mappings. It then fit naturaly in the process-classes phase, and REQUIRE the sources to be compiled prior to execution
          Hide
          nicolas de loof added a comment -

          I searched a way to plug in the DefaultArtifactResolver to "register" the modules as artifacts and bypass dependency issues, but this is realy too complex for me...

          Show
          nicolas de loof added a comment - I searched a way to plug in the DefaultArtifactResolver to "register" the modules as artifacts and bypass dependency issues, but this is realy too complex for me...
          Hide
          nicolas de loof added a comment -

          Simply moving the generate-* phases prior to compile doesn't fully solve issues with the eclipsePlugin. Any generate plugin that requires dependencyResolution (example : maven-ear-plugin) will require other project artifacts present in the local repo to create the eclipse configuration.

          In such case, there is no way to configure eclipse to fix a broken project.

          A complete fix would require a new early phase for plugins to DECLARE generated source folders. This would change the default lifecycle and requires many plugins updates.

          Another option could be that the reactor automagically registers modules as pseudo-artifacts and ignores them during dependency resolution. There would still be an issue with projects that have attached artifacts (example : test-jar) that may be set as dependencies on other modules. In such case the reactor should also ignore type and classifier...

          Show
          nicolas de loof added a comment - Simply moving the generate-* phases prior to compile doesn't fully solve issues with the eclipsePlugin. Any generate plugin that requires dependencyResolution (example : maven-ear-plugin) will require other project artifacts present in the local repo to create the eclipse configuration. In such case, there is no way to configure eclipse to fix a broken project. A complete fix would require a new early phase for plugins to DECLARE generated source folders. This would change the default lifecycle and requires many plugins updates. Another option could be that the reactor automagically registers modules as pseudo-artifacts and ignores them during dependency resolution. There would still be an issue with projects that have attached artifacts (example : test-jar) that may be set as dependencies on other modules. In such case the reactor should also ignore type and classifier...
          nicolas de loof made changes -
          Link This issue relates to MECLIPSE-252 [ MECLIPSE-252 ]
          Arnaud HERITIER made changes -
          Component/s Dependencies resolution and build path [ 12262 ]
          Hide
          Kenney Westerhof added a comment -

          First - only the generate-* phases should add (test)compileSourceRoots.

          The problem is that the generate-test* phases are after the compile phase.

          Possible solution: let the eclipse:eclipse mojo specify a custom lifecycle that reorders the phases, or even drops the compile/test phases
          altogether.

          Show
          Kenney Westerhof added a comment - First - only the generate-* phases should add (test)compileSourceRoots. The problem is that the generate-test* phases are after the compile phase. Possible solution: let the eclipse:eclipse mojo specify a custom lifecycle that reorders the phases, or even drops the compile/test phases altogether.
          Hide
          fabrizio giustina added a comment -

          the change has been reverted in version 2.2, so that now the plugin doesn't need projects to compile.
          The original issue tracked here (being able to add source folders in a later phase) is so reopened, and we will continue to discuss it in order to design a better solution.

          A snapshot with this change has been deployed at:
          http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.2-SNAPSHOT/maven-eclipse-plugin-2.2-20060402.070500-1.jar

          Show
          fabrizio giustina added a comment - the change has been reverted in version 2.2, so that now the plugin doesn't need projects to compile. The original issue tracked here (being able to add source folders in a later phase) is so reopened, and we will continue to discuss it in order to design a better solution. A snapshot with this change has been deployed at: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.2-SNAPSHOT/maven-eclipse-plugin-2.2-20060402.070500-1.jar
          Brett Porter made changes -
          Workflow Maven [ 44750 ] Maven New [ 51969 ]
          Hide
          Alexandre Poitras added a comment -

          I don't like the eclipse:eclipse goal to be automatically linked to a phase, because I can't generate my projets when the source code doesn't compile. How about not giving one by default but give the option to specify it in the plugin configuration section.

          Show
          Alexandre Poitras added a comment - I don't like the eclipse:eclipse goal to be automatically linked to a phase, because I can't generate my projets when the source code doesn't compile. How about not giving one by default but give the option to specify it in the plugin configuration section.
          Hide
          Mark Hobson added a comment -

          This change impairs the use of eclipse:eclipse somewhat for the reasons detailed by Kenney above - would it not be better for the average user to revert back to generate-resources whilst the design issues are resolved?

          Show
          Mark Hobson added a comment - This change impairs the use of eclipse:eclipse somewhat for the reasons detailed by Kenney above - would it not be better for the average user to revert back to generate-resources whilst the design issues are resolved?
          fabrizio giustina made changes -
          Fix Version/s 2.1 [ 12172 ]
          Hide
          fabrizio giustina added a comment -

          remove fix-version for further discussions

          Show
          fabrizio giustina added a comment - remove fix-version for further discussions
          Hide
          Kenney Westerhof added a comment -

          Yup.. but probably the most flexible one. There are tons of other solutions, like
          adding a MojoConfigurator class for each mojo (optionally ofcourse), or add a
          configure()/updateProject() method to each mojo that will update the sourceroots. Depending on
          the dry run parameter either execute() or configure()/updateProject() would be called.

          To be backwards compatible a simple solution like this might work:

          • add a mode parameter to the execute tag: @execute phase="..." mode="configureProject"
          • don't call execute() on the mojo but a final method in the AbstractMojo, depending on the value of the mode parameter:
          • either public final void executeMojo for normal executions, that will just call the abstract method execute()
          • or public void configureProject() that will by default also call execute() but can be overridden in
            the mojo's to update the project with sourceroots etc..

          I think this will ensure backwards compatibility and allow for future expansions on mojo execution
          to extract other metadata, like ant code snippets for the Ant plugin.

          Show
          Kenney Westerhof added a comment - Yup.. but probably the most flexible one. There are tons of other solutions, like adding a MojoConfigurator class for each mojo (optionally ofcourse), or add a configure()/updateProject() method to each mojo that will update the sourceroots. Depending on the dry run parameter either execute() or configure()/updateProject() would be called. To be backwards compatible a simple solution like this might work: add a mode parameter to the execute tag: @execute phase="..." mode="configureProject" don't call execute() on the mojo but a final method in the AbstractMojo, depending on the value of the mode parameter: either public final void executeMojo for normal executions, that will just call the abstract method execute() or public void configureProject() that will by default also call execute() but can be overridden in the mojo's to update the project with sourceroots etc.. I think this will ensure backwards compatibility and allow for future expansions on mojo execution to extract other metadata, like ant code snippets for the Ant plugin.
          Hide
          John Casey added a comment -

          it might be good to define a sort of "dry-run" switch for plugins to follow, which would ask them not to modify anything, just to add the compile source roots, etc that they would have added, so that plugins like this can do their job more accurately.

          That's sort of a big design issue, though.

          Show
          John Casey added a comment - it might be good to define a sort of "dry-run" switch for plugins to follow, which would ask them not to modify anything, just to add the compile source roots, etc that they would have added, so that plugins like this can do their job more accurately. That's sort of a big design issue, though.
          kenneyw made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Hide
          Kenney Westerhof added a comment -

          The idea behind the eclipse plugin is that you can develop on a project.

          Right now, I checked out a new version of a project I'm working on. Somebody messed it up
          and now it doesn't compile. I want to edit the faulty classes in Eclipse but I don;t have any .project
          files. So I run mvn eclipse:eclipse. That fails because the project doesn't compile.

          Now I cannot fix the bugs because the plugin that should make metadata ABOUT the project
          tries to compile it first which makes no sense.

          I understand that test-resources should also be present in eclipse, but this solution limits
          the usage of eclipse on maven projects and is not backwards compatible in my opinion.

          I'd like to see this change reverted, and maybe add a comandline switch to include/exclude
          test resources when generating project resources. Currently I think only a new mojo can do the trick
          since the @execute phase is not runtime configurable.

          Maybe it's time to review the generate-test-resource phase. Is it per definition necessary to have
          compiled src/main sources present in this phase? If so, why? If not, shouldn't the generate-test-(re)sources
          be run right after the process-resources? I.e. move them before the compile phase?

          Another solution might be to make the @execute phase configurable somehow, and specify an option
          to the eclipse:eclipse plugin to NOT generate test resources and stick with the generate-resources
          phase.
          the process-resources

          Show
          Kenney Westerhof added a comment - The idea behind the eclipse plugin is that you can develop on a project. Right now, I checked out a new version of a project I'm working on. Somebody messed it up and now it doesn't compile. I want to edit the faulty classes in Eclipse but I don;t have any .project files. So I run mvn eclipse:eclipse. That fails because the project doesn't compile. Now I cannot fix the bugs because the plugin that should make metadata ABOUT the project tries to compile it first which makes no sense. I understand that test-resources should also be present in eclipse, but this solution limits the usage of eclipse on maven projects and is not backwards compatible in my opinion. I'd like to see this change reverted, and maybe add a comandline switch to include/exclude test resources when generating project resources. Currently I think only a new mojo can do the trick since the @execute phase is not runtime configurable. Maybe it's time to review the generate-test-resource phase. Is it per definition necessary to have compiled src/main sources present in this phase? If so, why? If not, shouldn't the generate-test-(re)sources be run right after the process-resources? I.e. move them before the compile phase? Another solution might be to make the @execute phase configurable somehow, and specify an option to the eclipse:eclipse plugin to NOT generate test resources and stick with the generate-resources phase. the process-resources
          fabrizio giustina made changes -
          Fix Version/s 2.1 [ 12172 ]
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Assignee fabrizio giustina [ fgiust ]
          Hide
          fabrizio giustina added a comment -

          phase changed to "generate-test-resources" as suggested by Trygve

          Show
          fabrizio giustina added a comment - phase changed to "generate-test-resources" as suggested by Trygve
          Jason van Zyl made changes -
          Workflow jira [ 44153 ] Maven [ 44750 ]
          Hide
          Trygve Laugstøl added a comment -

          I think setting phase to "generate-test-resources" should do the trick.

          Show
          Trygve Laugstøl added a comment - I think setting phase to "generate-test-resources" should do the trick.
          fabrizio giustina made changes -
          Affects Version/s 2.0 [ 12171 ]
          Jason van Zyl made changes -
          Component/s maven-eclipse-plugin [ 11797 ]
          Type Improvement [ 4 ] Bug [ 1 ]
          Affects Version/s 2.0 [ 11703 ]
          Project Maven 2 [ 10500 ] Maven 2.x Eclipse Plugin [ 11133 ]
          Fix Version/s 2.0.3 [ 12107 ]
          Workflow Maven [ 42752 ] jira [ 44153 ]
          Key MNG-1707 MECLIPSE-37
          Brett Porter made changes -
          Field Original Value New Value
          Fix Version/s 2.0.1 [ 12000 ]
          Fix Version/s 2.0.2 [ 12107 ]
          Hide
          Mark Donszelmann added a comment -

          sorry, my misunderstanding of that tag. Please correct the subject of this issue, I do not seem to have privs to do so.

          Indeed the eclipsePlugin has this tag as well.

          However I do thing that it needs a later phase here, because other plugins may add
          paths to the compileSourceRoots and testCompileSourceRoots.

          phases such as process-sources, process-test-sources (which may filter some files and put the result elsewhere).
          should not be neglected.

          Looking at the default lifecycle I guess that the "test" phase (or just before) should be executed as part of the
          eclipse:eclipse goal, to make sure one has all the paths for sources, test-sources, resources and test-resources.

          I may be wrong...

          Show
          Mark Donszelmann added a comment - sorry, my misunderstanding of that tag. Please correct the subject of this issue, I do not seem to have privs to do so. Indeed the eclipsePlugin has this tag as well. However I do thing that it needs a later phase here, because other plugins may add paths to the compileSourceRoots and testCompileSourceRoots. phases such as process-sources, process-test-sources (which may filter some files and put the result elsewhere). should not be neglected. Looking at the default lifecycle I guess that the "test" phase (or just before) should be executed as part of the eclipse:eclipse goal, to make sure one has all the paths for sources, test-sources, resources and test-resources. I may be wrong...
          Hide
          Brett Porter added a comment -

          it doesn't run in any phase.

          What I did in the idea plugin was to run generate-sources as part of the idea plugin:

          @execute phase="generate-sources"

          Show
          Brett Porter added a comment - it doesn't run in any phase. What I did in the idea plugin was to run generate-sources as part of the idea plugin: @execute phase="generate-sources"
          Mark Donszelmann created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark Donszelmann
            • Votes:
              7 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development