[MECLIPSE] how to bypass dependency resolution ?

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

Re: [MECLIPSE] how to bypass dependency resolution ?

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

I dive a little bit more in maven internals...

Seems the only way to avoid dependencyResolution to lookup repositories is
to have the Artifact return isResolved() == true.

Doing this requires to hack the DefaultArtifactFactory. As there is no cache
used by this class, there is no way to register Artifacts objects for any
module found by the reactor.

As an alternative, is there any way to REPLACE a plexus component AT RUNTIME
? The eclipse plugin could register a custom ArtifactFactory that builds
Artifact stubs for the current project modules.

... or maybe there is really no way to avoid dependency resolution ?

maven 2 solved the issue of dependency resolution when invoking the clean
goal.
could maven 2.1 solve the issue of dependency resolution when setting up the
developper environment ?

Do we need a new lifecycle for environment setup, so that code generation
plugins could participate ? Do we need some dedicated interface on
code-generating Mojo, so that an IDE plugin could check any module for code
generation by listing it's active plugins ?


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