The "checkMissingArtifactsInReactor" method is only used when the plugin is an aggregator.
The eclipse plugin may fail when it ask for execution of phase=generate-sources, as some plugins requires dependency resolution (sample : an ear having dependency on a war). But in this case, the execution is not done in reactor. To solve this issue, I have two options : - make enhancements to core and plugin api to support a new ConfigureMojo API for plugins that have to declare some project level metadatas (generated source folders, or other...). This would require a new maven release, and maybe wiat for 2.1 - change the way the eclipse plugin force a generate-resources phase to be executed. AS this is NOT done in reactor, even when the eclipse plugin does, the "*can't be resolved but has been found in the reactor*" does not occur. I've no idea how a plugin can access the current MavenSession and execute a phase/plugin, as @execute phase="" is not enough for this use case. Nico. 2007/12/20, Brian E. Fox <[EMAIL PROTECTED]>: > > 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] > >
