On Wed, Oct 21, 2009 at 9:13 AM, aldana <[email protected]> wrote: > > for using the @execute phase=xxxx for mojo i read: > > 'This annotation can be used in a number of ways. If a phase is supplied, > Maven will execute a parallel lifecycle ending in the specified phase. ....' > > further more ${executedProject} is made available. > > but what is the sense of executing a parallel lifecycle and creating a new > property ${executedProject}? is ${executedProject} the mutable pendant to > ${project}? could you name some uses cases and when a plugin should use this > option (afaik jetty-plugin is using such a @execute phase).
You might be better off on the dev list for this question. I'm no expect but I think what I am telling you is correct. However... >From >http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations "When this goal is invoked, it will first invoke a parallel lifecycle, ending at the given phase. If a goal is provided instead of a phase, that goal will be executed in isolation. The execution of either will not affect the current project, but instead make available the ${executedProject} expression if required. An alternate lifecycle can also be provided: for more information see the documentation on the build lifecycle." An example of where the parallel lifecycle is used is the site lifecycle (see http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference) In order to build the reports for the site (e.g. junit reports) the input files need to be available. By using something like @execute phase="test" lifecycle="default" the site plugin is able to invoke maven internally on this lifecycle/goal and hence all the files needed for the current plugin will be available. In order to separate the current plugins execution environment from the parallel lifecycle separate project variables are used. Current plugin's project = ${project} Execute phase project = ${executedProject} Be aware that this behaviour is often considered broken because the executed build phase has often already happened but the @execute causes it to be run again, so the same phase are run twice. An example of this I think is unit test coverage, it often needs to instrument the unit test code so it will fork a new build lifecycle (which re-runs everything up to test again) to do the coverage reports. For site it is often the case that you have already just run "mvn install" and hence everything you need is available and this can be especially frustrating if your integration tests take a long time (15 minutes or more). This is also one of the reasons why you see two goals in a plugin that do the same thing, but one will have a "-only" suffix. e.g surefire-report:report-only Where the "-only" goal doesn't run a parallel lifecycle. I believe Maven 3 will be attempting to define this better to avoid these issues. Hope that helps. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
