This is done automatically by the core. If you inspect the file handle of artifacts passed to a plugin in a reactor build: if the phase compile was executed, it will point to /foo/target/classes. If the phase package was executed, it will be /foo/target/foo-version.jar, and if install, it will point to the repo.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Thursday, December 20, 2007 9:57 AM To: Maven Developers List Subject: Re: how to bypass dependency resolution ? I just noticed when running release:prepare " [WARNING] The dependency: test:test2:jar:2-SNAPSHOT can't be resolved but has been found in the reactor. " This sounds like a project running in the reactor CAN bypass dependency resolution on its artifacts. Could someone explain me HOW it is done by the releaseManager and how we could port this code to IDE-plugins ? 2007/12/18, nicolas de loof <[EMAIL PROTECTED]>: > > > 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. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
