Maven 2.x Eclipse Plugin

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

Details

  • Number of attachments :
    1

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

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"
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
Trygve Laugstol added a comment -

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

Show
Trygve Laugstol added a comment - I think setting phase to "generate-test-resources" should do the trick.
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
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
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.
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
fabrizio giustina added a comment -

remove fix-version for further discussions

Show
fabrizio giustina added a comment - remove fix-version for further discussions
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?
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
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
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
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...
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 -

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
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
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 -

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 -

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 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 -

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.
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
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.
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
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?

People

Vote (5)
Watch (13)

Dates

  • Created:
    Updated: