Add a new dry-run mode to DefaultLifecycleExecutor (was : how to bypass dependency resolution ?)

[nicolas de loof <ni...@apache.org>]

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 <ni...@apache.org>:
>
> 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.
>