Seems I have missed some interesting threads on the dev list ! What is this "build plan" ? Is this related to http://docs.codehaus.org/display/MAVEN/Toolchains
I didn't find proposal / description of this mechanism on http://docs.codehaus.org/display/MAVEN/Home Nico. 2007/12/22, Jason van Zyl <[EMAIL PROTECTED]>: > > > On 22 Dec 07, at 4:49 AM 22 Dec 07, nicolas de loof wrote: > > > 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 > > > > You should sync up with John Casey as the build plan is the mechanism > by which the lifecycle can be controlled before execution. So you we > make the plan available, the plan can be altered before execution, > then the plan is executed. Imagine visually the plan in an IDE so that > the user can change anything before it does in fact execute. > > Not in favor of your general approach there, the build plan is the way > to go. > > > - 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. > > If this works for the eclipse plugin then I would build up what it is > exactly you need an put it on the proposals page. You can get > something working quickly and think about the long term. > > The plugin configuration gets tricky because you want it before > artifact resolution proper, but you may want the POM or plugin > metadata to alter the build plan. So doing it properly would really > entail putting the plugin metadata somewhere available outside the JAR > so that we don't need to pull down everything for the user to make > changes to the build plan. > > > > > > > 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] > >> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > What matters is not ideas, but the people who have them. Good people > can fix bad ideas, but good ideas can't save bad people. > > -- Paul Graham > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
