[
http://jira.codehaus.org/browse/MNG-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146330#action_146330
]
John Casey commented on MNG-3729:
---------------------------------
This problem seems to be related to situations in which one mojo forks to a
lifecycle phase, such that two or more mojos are executed in that forked
lifecycle. When the first one uses the reactorProjects (or is marked as an
aggregator), then all the projects in the reactor have their executionProject
set to null, which means that if a successive mojo execution tries to make use
of that executionProject (usually by forking yet another level of lifecycle
execution on each project in the reactor), the project used in that execution
will be null.
One solution would be to maintain a fresh set of project instances for use in a
lifecycle (be it forked or main-execution) that are interdependent in the same
ways that the original project instances were. Then, whenever it comes time to
fork a new lifecycle, the existing project-set is pushed onto a stack, a new
set is created derived from the last, the executionProject and inter-project
references are restored within that set, and it is used. When the forked
execution is finished, the current project set is discarded (or, made available
to the mojo that caused the execution fork, THEN discarded), and the last
project-set to be pushed to the stack is popped out for continued use.
Unfortunately, some plugins - like the javadoc plugin - depend on the project
instances available through \${reactorProjects} having a valid value for
getExecutionProject(), which means they expect to get the main-line project
instances from the reactorProjects parameter, then to have to traverse into the
executionProject. While this logic doesn't take into account multiple levels of
execution forking, it's also encoded in released plugins, so any near-term
solution should avoid upsetting that balance.
The easiest fix for now is to avoid ever resetting the executionProject
property on a project to null, and stop checking whether this executionProject
is null before creating a new one during the setup activities for a forked
execution...simply set it forcefully. There may be another way to make the
MavenProject instance "fake" an executionProject by returning itself if it
doesn't have a separate one, which would probably preserve the functionality of
the javadoc plugin while still allowing us to implement the push-pop method WRT
reactorProject sets, but for an advanced release candidate to do this I believe
would be a really bad idea. I'll create a new issue to address this later in
the 2.x series somewhere.
For now, we'll avoid setting executionProject to null, and brute-force the
setting of new executionProject instances per-fork.
> Maven 2.0.10-RC10 fails with NPE on assembly:assembly
> -----------------------------------------------------
>
> Key: MNG-3729
> URL: http://jira.codehaus.org/browse/MNG-3729
> Project: Maven 2
> Issue Type: Bug
> Affects Versions: 2.0.10
> Environment: Mac OS X 10.5.4
> Reporter: Thorsten Möller
> Fix For: 2.0.10
>
> Attachments: bin.xml, pom.xml
>
>
> Multi-module project fails with NPE on assembly:assembly (assembly plugin
> used 2.2-beta-1; 2.2-beta-2 can not be used because of
> http://jira.codehaus.org/browse/MASSEMBLY-314 bug)
> Command used was "mvn clean install assembly:assembly eclipse:eclipse".
> Same configuration (see attached POM) works with Maven 2.0.9. Below you will
> find relevant excerpt from the build trace.
> Note: Some internal/irrelevant information were removed from attached POM.
> Additionally, assembly descriptor of default assembly is attached.
> Best regards,
> Thorsten
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building OSIRIS Next
> [INFO] task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Preparing assembly:assembly
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building OSIRIS Next
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [enforcer:enforce {execution: enforce-maven}]
> [INFO] [tools:copy-legal-files {execution: install-legal-files}]
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] null
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
>
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 55 minutes 18 seconds
> [INFO] Finished at: Mon Aug 25 17:18:11 CEST 2008
> [INFO] Final Memory: 36M/126M
> [INFO]
> ------------------------------------------------------------------------
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
