For those who didn't follow my provious post, the issue is about IDE-support plugins that require a previously-built project to setup the dev environment. When the source code is broken, you have to fix it under VI / notepad.
I experimented Kenney Westerhof<http://jira.codehaus.org/secure/ViewProfile.jspa?name=kenneyw>idea, as exposed in MECLIPSE-37 : - I created a ConfigureMojo interface with single method configureProject() - I updated AbsractMojo to do nothing on this method - I enhanced JavaMojoDescriptorExrtaction to support a new @configure phase="" that was the simple part ;-) I now need to update maven core to support a "configure" lifecycle execution mode, so that the eclipse plugin can trigger a forked lifecycle in sort of "dry run" mode. In this mode, the lifecycle should not fail when resolving dependencies, or maybe not honnor @requiresDependecyResolution at all. Existing Mojos will not be affected, and updated ones will declare generated folders or any other setting usefull at configuration-time. What is the good place to add such a "configure" (dry-run) support ? It would require to enlarge the (allready long) DefaultLifecycleExecutor.forkProjectLifecycle method for the "if ( mojoDescriptor.getConfigurePhase() != null)" case. It would also require to bypass the DefaultPluginManager.executeMojo "if ( mojoDescriptor.isDependencyResolutionRequired )" Maybe the simplier would be to cerate a DryRunLifecycleExecutor and DryRunPluginManager ? Any suggestion is welcome... Nico. 2007/12/14, nicolas de loof <[EMAIL PROTECTED]>: > > Hello, > > some MECLIPSE issues are related to the phase executed by the eclipse > plugin to collect generated-* folders. > > Here is a simple example of the side-effect of this strategy > > pom.xml > |_ ear project > |_ jar project > |_ war project > > Lets supose the jar project is broken and can't compile. > > Checking the project from svn and running mvn eclipse:eclipse fails, as > the maven-ear-plugin has @RequireDependencyResolustion(test) (is this really > required ?) on GenerateApplicationXMLMojo > > mvn install also fails as the jar plugin is broken > > There is NO way to configure eclipse and fix the project ! > > My first idea is to find some hook in the ArtifactResolver (or other) to > register the multiproject modules as "fake" artifacts, so that dependency > resolution doesn't fail. I looked at DefaultArtifactResolver ... but is far > too complex for me and can't find where the Artifact objects are created, > and how the associated File object could be hacked > > A cleaner fix would be to have an early phase for generate-* Mojos to > register generated folders... but hits requires changes on most plugins - > maybe could be planned for maven 2.1 ? > > Any suggestion ? > > Nico. >
