Maven 2 & 3

Maven 2.0.10-RC10 fails with NPE on assembly:assembly

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.10
  • Fix Version/s: 2.1.0-M1
  • Component/s: None
  • Labels:
    None
  • Environment:
    Mac OS X 10.5.4
  • Complexity:
    Intermediate
  • Number of attachments :
    2

Description

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] ------------------------------------------------------------------------

Attachments

  1. XML File
    bin.xml
    26/Aug/08 10:49 AM
    3 kB
    Thorsten Möller
  2. XML File
    pom.xml
    26/Aug/08 10:49 AM
    14 kB
    Thorsten Möller

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

The latest RC is RC11: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/
Could you check if it suffers from this, too?

Show
Benjamin Bentmann added a comment - The latest RC is RC11: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Could you check if it suffers from this, too?
Hide
Permalink
Thorsten Möller added a comment -

Same exception also with RC11:

[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:675)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1030)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1025)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:551)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:369)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
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: 7 minutes 33 seconds
[INFO] Finished at: Tue Aug 26 18:24:29 CEST 2008
[INFO] Final Memory: 42M/126M
[INFO] ------------------------------------------------------------------------

Show
Thorsten Möller added a comment - Same exception also with RC11: [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:675) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1030) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1187) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1025) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:626) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) 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: 7 minutes 33 seconds [INFO] Finished at: Tue Aug 26 18:24:29 CEST 2008 [INFO] Final Memory: 42M/126M [INFO] ------------------------------------------------------------------------
Hide
Permalink
John Casey added a comment -

Unfortunately this just isn't enough information to debug the problem. Do you have a SVN location I could check out to grab this build and give it a try? Or, if it's proprietary, could you at least re-run the build above with the -X command-line flag, and post that output? I'm not sure what's causing the project (probably a forked-execution clone of the project in question) is null...

Show
John Casey added a comment - Unfortunately this just isn't enough information to debug the problem. Do you have a SVN location I could check out to grab this build and give it a try? Or, if it's proprietary, could you at least re-run the build above with the -X command-line flag, and post that output? I'm not sure what's causing the project (probably a forked-execution clone of the project in question) is null...
Hide
Permalink
John Casey added a comment -

I tried to reproduce this issue using the maven-core build and the information given above, but unfortunately it didn't work. I'm not sure what the difference is in execution environment, but if you could produce an archived test project setup that will display the error, I'm happy to continue debugging.

Show
John Casey added a comment - I tried to reproduce this issue using the maven-core build and the information given above, but unfortunately it didn't work. I'm not sure what the difference is in execution environment, but if you could produce an archived test project setup that will display the error, I'm happy to continue debugging.
Hide
Permalink
Thorsten Möller added a comment -

Yes, you can check out the entire project here:
http://on.cs.unibas.ch/svn/repos/on/trunk

For building you might need to add -DskipTests since one JUnit test sporadically fails (bug in the test which hasn't been fixed yet).

Best regards,
Thorsten

Show
Thorsten Möller added a comment - Yes, you can check out the entire project here: http://on.cs.unibas.ch/svn/repos/on/trunk For building you might need to add -DskipTests since one JUnit test sporadically fails (bug in the test which hasn't been fixed yet). Best regards, Thorsten
Hide
Permalink
John Casey added a comment -

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.

Show
John Casey added a comment - 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.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.