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

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"

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

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

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

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

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.

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.

remove fix-version for further discussions

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?

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.

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

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.

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

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

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

A patch is provided in MECLIPSE-409

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.

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 ?

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>

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

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

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

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.

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

As maven 2.1 is out is there any updates?