Apache/maven
1
0
Fork 0
mirror of https://github.com/apache/maven.git synced 2025-02-23 19:05:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

adding description to javadoc.

Browse Source 
git-svn-id: https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk@689989 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
John Dennis Casey 2008-08-28 21:17:10 +00:00
parent c2f954ea30
commit 11c2b79ba2
1 changed files with 17 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
its/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenITmng3729MultiForkAggregatorsTest.java
View File

@ -27,12 +27,26 @@
/**
* This is a test set for <a href="http://jira.codehaus.org/browse/MNG-3729">MNG-3729</a>.
*
* @todo Fill in a better description of what this test verifies!
* <br/><br/>
* Complicated use case, but say
* you have an aggregator plugin that forks a lifecycle, and this aggregator is bound to the main lifecycle in a
* multimodule build. Further, say you call another plugin directly from the command line for this multimodule build,
* which forks a new lifecycle (like assembly:assembly).
* <br/><br/>
* When the directly invoked aggregator forks, it will force the
* forked lifecycle phase to be run for each project in the reactor, regardless of whether this causes the bound
* aggregator mojo to run multiple times. When the bound aggregator executes for the first project (this will be in an
* inner fork, two levels removed from the main lifecycle execution) it will set the executionProject to null for the
* current project (which is one of the reactorProjects member instances). On the second pass, as it tries to execute
* the inner aggregator's forked lifecycle for the second project in the reactor, one of the reactorProjects'
* project.getExecutionProject() results will be null. If any of the mojos in this inner lifecycle fork requires
* dependency resolution, it will cause a NullPointerException in the DefaultPluginManager when it tries to resolve the
* dependencies for the current project. This happened in 2.0.10-RC11 (which was the predecessor to 2.1.0-RC12, since
* the version was renamed while the release process was in mid-execution). It did not happen in 2.0.9, and was fixed in
* 2.1.0-RC12.
*
* @author <a href="mailto:brianf@apache.org">Brian Fox</a>
* @author jdcasey
*
*/
public class MavenITmng3729MultiForkAggregatorsTest
extends AbstractMavenIntegrationTestCase