Maven 2 & 3

FATAL ERROR and NPE on start

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: 2.0.9
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
  • Complexity:
    Intermediate
  • Number of attachments :
    5

Description

Any mvn command does give me the following error message
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Business Rules Extractor
[INFO] Business Rules Extractor core functions
[INFO] COBOL Parser and ANTLR Tools
[INFO] Business Rules Extractor data model
[INFO] Documentation Extractor module
[INFO] Extractor module
[INFO] Business Rules Navigator
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building Business Rules Extractor
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164)
at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366)
at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168)
at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253)
at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197)
at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
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:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
at java.lang.reflect.Method.invoke(Method.java:612)
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: 1 second
[INFO] Finished at: Fri May 16 13:10:16 EDT 2008
[INFO] Final Memory: 6M/19M
[INFO] ------------------------------------------------------------------------

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-3618 maven 2.0.9 return NPE on Linux with IBM JVM 1.6.0 SR1

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4080 running mvn fails on IBM JDK 6 with NullPointerException

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-3753 ArtifactResolverDiagnoser.diagnose() fails with NPE if nested IOException has no detail message

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Erik Putrycz added a comment -

It might be a jdk specific bug, the same execution works with the sun jdk.

Show
Erik Putrycz added a comment - It might be a jdk specific bug, the same execution works with the sun jdk.
Hide
Permalink
Jörg Schaible added a comment -

There seems a general problem with Maven running on IBM JDKs (also 1.5 and 1.4.2), at least on Linux. See http://article.gmane.org/gmane.comp.jakarta.commons.devel/99692/match=ibm+maven

Show
Jörg Schaible added a comment - There seems a general problem with Maven running on IBM JDKs (also 1.5 and 1.4.2), at least on Linux. See http://article.gmane.org/gmane.comp.jakarta.commons.devel/99692/match=ibm+maven
Hide
Permalink
Vincent Siveton added a comment -

I could reproduce it with Harmony

#java -version
Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software Foundation or its licensors, as applicable.
java version "1.5.0"
pre-alpha : not complete or compatible
svn = r629320, (Feb 20 2008), Windows/em64t/msvc 1400, release build
http://harmony.apache.org
Show
Vincent Siveton added a comment - I could reproduce it with Harmony #java -version Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software Foundation or its licensors, as applicable. java version "1.5.0" pre-alpha : not complete or compatible svn = r629320, (Feb 20 2008), Windows/em64t/msvc 1400, release build http://harmony.apache.org
Hide
Permalink
Vincent Siveton added a comment -

Forgot to say that works fine with IBM JDK 1.5 and BEA JRockit 1.5, twice under Windows box.

Show
Vincent Siveton added a comment - Forgot to say that works fine with IBM JDK 1.5 and BEA JRockit 1.5, twice under Windows box.
Hide
Permalink
Vincent Siveton added a comment -

Here is a fix.
Erik, could test it with your project and apache-maven-2.0.10-SNAPSHOT ?

Show
Vincent Siveton added a comment - Here is a fix. Erik, could test it with your project and apache-maven-2.0.10-SNAPSHOT ?
Hide
Permalink
Benjamin Bentmann added a comment -

Out of curiosity: Why are the null checks only required for certain JREs? I mean, a null is a null and hence its occurrence during the iterations should fail for everybody, shouldn't it?

Show
Benjamin Bentmann added a comment - Out of curiosity: Why are the null checks only required for certain JREs? I mean, a null is a null and hence its occurrence during the iterations should fail for everybody, shouldn't it?
Hide
Permalink
Vincent Siveton added a comment -

Hi Benjamin,

Yes you are right on the ideas but you forgot that JDK impl is vendor specific.
The following is the more simplest patch but I don't know the potential side effects so I proposed null check.

Index: src/main/java/org/apache/maven/project/ModelUtils.java
===================================================================
--- src/main/java/org/apache/maven/project/ModelUtils.java	(revision 658692)
+++ src/main/java/org/apache/maven/project/ModelUtils.java	(working copy)
@@ -240,7 +240,7 @@
                             idx = 0;
                         }
 
-                        results.addAll( idx, missingFromResults );
+                        results.addAll( missingFromResults );
 
                         missingFromResults.clear();
                     }

Have a glance on sun [1] and harmony [2] for the addAll() impl.

[1] http://cycleserv2.csail.mit.edu/Harpoon/srcdoc/java/util/ArrayList.html#442
[2] http://www.jdocs.com/harmony/5.M5/java/util/ArrayList.html#170

Show
Vincent Siveton added a comment - Hi Benjamin, Yes you are right on the ideas but you forgot that JDK impl is vendor specific. The following is the more simplest patch but I don't know the potential side effects so I proposed null check. Index: src/main/java/org/apache/maven/project/ModelUtils.java =================================================================== --- src/main/java/org/apache/maven/project/ModelUtils.java (revision 658692) +++ src/main/java/org/apache/maven/project/ModelUtils.java (working copy) @@ -240,7 +240,7 @@ idx = 0; } - results.addAll( idx, missingFromResults ); + results.addAll( missingFromResults ); missingFromResults.clear(); } Have a glance on sun [1] and harmony [2] for the addAll() impl. [1] http://cycleserv2.csail.mit.edu/Harpoon/srcdoc/java/util/ArrayList.html#442 [2] http://www.jdocs.com/harmony/5.M5/java/util/ArrayList.html#170
Hide
Permalink
Erik Putrycz added a comment - - edited

Stupid question... Where can I download and install apache-maven-2.0.10-SNAPSHOT?
Is there a binary distribution like the official one for the snapshot?

I raised this issue on the IBM forums but no answer so far since it is not related to a compilation issue. If this really comes from the addAll method, I'm shocked that the JDK compatibility suites are not capturing this one.
maven 2.0.9 works indeed fine with jrockit and the sun jdk but I believe they share more of the same implementation code unlike the IBM one.

Show
Erik Putrycz added a comment - - edited Stupid question... Where can I download and install apache-maven-2.0.10-SNAPSHOT? Is there a binary distribution like the official one for the snapshot? I raised this issue on the IBM forums but no answer so far since it is not related to a compilation issue. If this really comes from the addAll method, I'm shocked that the JDK compatibility suites are not capturing this one. maven 2.0.9 works indeed fine with jrockit and the sun jdk but I believe they share more of the same implementation code unlike the IBM one.
Hide
Permalink
Vincent Siveton added a comment -

AFAIK we dont have a snapshot space
So go to [1], and just build it [2]

[1] https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x
[2] http://maven.apache.org/guides/development/guide-building-m2.html

Show
Vincent Siveton added a comment - AFAIK we dont have a snapshot space So go to [1] , and just build it [2] [1] https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x [2] http://maven.apache.org/guides/development/guide-building-m2.html
Hide
Permalink
Benjamin Bentmann added a comment -

but you forgot that JDK impl is vendor specific.

The terms "implementation" and "vendor specific" are inheritly related, that's no news. My concern was that besides some vendor-specific differences under the hood, every JRE impl must obey the contracts imposed by the API.

After some investigation, the problem boils down to a JRE bug just like Erik assumed, i.e. the null value should never appear in the plugin list iterated by Maven and it is not Maven's fault that it does. Take the following code snippet:

Collection coll = Arrays.asList( new String[] { "1", "2" } );

List list = new ArrayList();

list.add( "a" );
list.add( 0, "b" );
list.add( 0, "c" );
list.add( 0, "d" );
list.add( 0, "e" );
list.add( 0, "f" );
list.add( 0, "g" );
list.add( 0, "h" );
list.add( 0, "i" );

list.addAll( 6, coll );

System.out.println( System.getProperty( "java.vendor.url" ) );
System.out.println( list.size() );
System.out.println( list );
System.out.println( list.contains( null ) );

On a Sun JDK the following output is observed:

http://java.sun.com/
11
[i, h, g, f, e, d, 1, 2, c, b, a]
false

In contrast, on harmony-jdk-629320 I observed

http://harmony.apache.org
12
[i, h, g, f, e, d, 1, 2, d, c, b, null]
true

which is just incorrect.

Facit: Here is nothing to fix in Maven. I wouldn't ever consider a workaround since this would require to review all code spots that use ArrayList and not just the one class ModelUtils where the JRE bug manifested itself for the first time. The JRE vendor is responsible to fix this.

Show
Benjamin Bentmann added a comment - but you forgot that JDK impl is vendor specific. The terms "implementation" and "vendor specific" are inheritly related, that's no news. My concern was that besides some vendor-specific differences under the hood, every JRE impl must obey the contracts imposed by the API. After some investigation, the problem boils down to a JRE bug just like Erik assumed, i.e. the null value should never appear in the plugin list iterated by Maven and it is not Maven's fault that it does. Take the following code snippet: Collection coll = Arrays.asList( new String [] { "1" , "2" } ); List list = new ArrayList(); list.add( "a" ); list.add( 0, "b" ); list.add( 0, "c" ); list.add( 0, "d" ); list.add( 0, "e" ); list.add( 0, "f" ); list.add( 0, "g" ); list.add( 0, "h" ); list.add( 0, "i" ); list.addAll( 6, coll ); System .out.println( System .getProperty( "java.vendor.url" ) ); System .out.println( list.size() ); System .out.println( list ); System .out.println( list.contains( null ) ); On a Sun JDK the following output is observed: http://java.sun.com/ 11 [i, h, g, f, e, d, 1, 2, c, b, a] false In contrast, on harmony-jdk-629320 I observed http://harmony.apache.org 12 [i, h, g, f, e, d, 1, 2, d, c, b, null] true which is just incorrect. Facit: Here is nothing to fix in Maven. I wouldn't ever consider a workaround since this would require to review all code spots that use ArrayList and not just the one class ModelUtils where the JRE bug manifested itself for the first time. The JRE vendor is responsible to fix this.
Hide
Permalink
Vincent Siveton added a comment -

FYI on IBM, the result is

http://www.ibm.com/
11
[i, h, g, f, e, d, 1, 2, c, b, a]
false

So, we found an issue in Harmony (HARMONY-5839) but no clue for IBM....

I agree with you that it is the contract of the vendor to respect the JDK.

Show
Vincent Siveton added a comment - FYI on IBM, the result is http://www.ibm.com/ 11 [i, h, g, f, e, d, 1, 2, c, b, a] false So, we found an issue in Harmony (HARMONY-5839) but no clue for IBM.... I agree with you that it is the contract of the vendor to respect the JDK.
Hide
Permalink
Benjamin Bentmann added a comment -

but no clue for IBM....

My code snippet was specially crafted to trigger the faulty code path in Harmony. There might just be a similar bug in the IBM JRE that simply is not revealed by the test snippet. As far as I can tell after some debugging through Maven, Maven itself is not inserting nulls into the plugin list so somebody else seems to do... If you really want to know, you could simply set a break point on ModelUtils.java:243 and verify the results list is properly populated by ArrayList.addAll().

Show
Benjamin Bentmann added a comment - but no clue for IBM.... My code snippet was specially crafted to trigger the faulty code path in Harmony. There might just be a similar bug in the IBM JRE that simply is not revealed by the test snippet. As far as I can tell after some debugging through Maven, Maven itself is not inserting nulls into the plugin list so somebody else seems to do... If you really want to know, you could simply set a break point on ModelUtils.java:243 and verify the results list is properly populated by ArrayList.addAll() .
Hide
Permalink
Erik Putrycz added a comment -

According to http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=206283
this bug is fixed in Harmony Mile Stone 6 and will be fixed in IBM JDK 6.0 SR2.
Hard to believe such nasty bugs can be present in JDK code without being caught by a test suite.

Erik.

Show
Erik Putrycz added a comment - According to http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=206283 this bug is fixed in Harmony Mile Stone 6 and will be fixed in IBM JDK 6.0 SR2. Hard to believe such nasty bugs can be present in JDK code without being caught by a test suite. Erik.
Hide
Permalink
Brett Porter added a comment -

as I understand it, we resolved this to be a JRE bug

Show
Brett Porter added a comment - as I understand it, we resolved this to be a JRE bug
Hide
Permalink
Jörg Schaible added a comment -

Just for the records, I tried to build commons-jxpath-1.3 RC4 from source with M209 under Gentoo and all three currently available IBM compiler generations failed (1.4.2.11, 1.5.0.7, 1.6.0.1), but each time differently:

joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.4
Now using ibm-jdk-bin-1.4 as your user JVM
joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Commons JXPath
[INFO]    task-segment: [clean, package]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: org.codehaus.plexus:plexus-utils

Reason: Failed to build model from file '/home/joehni/.m2/repository/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom'.
Error: 'null' for project org.codehaus.plexus:plexus-utils


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Sat Jul 05 13:47:04 CEST 2008
[INFO] Final Memory: 7M/16M
[INFO] ------------------------------------------------------------------------
joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.5
Now using ibm-jdk-bin-1.5 as your user JVM
joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Commons JXPath
[INFO]    task-segment: [clean, package]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
---------------------------------------------------
constituent[0]: file:/usr/share/maven-bin-2.0/lib/maven-2.0.9-uber.jar
---------------------------------------------------
java.lang.NullPointerException
        at java.lang.String.indexOf(String.java:792)
        at java.lang.String.indexOf(String.java:770)
        at org.apache.maven.usability.ArtifactResolverDiagnoser.diagnose(ArtifactResolverDiagnoser.java:53)
        at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:84)
        at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:754)
        at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:701)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:135)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:618)
        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)
joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.6
Now using ibm-jdk-bin-1.6 as your user JVM
joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Commons JXPath
[INFO]    task-segment: [clean, package]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
        at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164)
        at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366)
        at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168)
        at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61)
        at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852)
        at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253)
        at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265)
        at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197)
        at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
        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:287)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
        at java.lang.reflect.Method.invoke(Method.java:612)
        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: 2 seconds
[INFO] Finished at: Sat Jul 05 13:48:10 CEST 2008
[INFO] Final Memory: 2M/7M
[INFO] ------------------------------------------------------------------------

Waiting for 1.6 SR 2

Show
Jörg Schaible added a comment - Just for the records, I tried to build commons-jxpath-1.3 RC4 from source with M209 under Gentoo and all three currently available IBM compiler generations failed (1.4.2.11, 1.5.0.7, 1.6.0.1), but each time differently: joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.4 Now using ibm-jdk-bin-1.4 as your user JVM joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Commons JXPath [INFO] task-segment: [clean, package] [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: org.codehaus.plexus:plexus-utils Reason: Failed to build model from file '/home/joehni/.m2/repository/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom'. Error: 'null' for project org.codehaus.plexus:plexus-utils [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6 seconds [INFO] Finished at: Sat Jul 05 13:47:04 CEST 2008 [INFO] Final Memory: 7M/16M [INFO] ------------------------------------------------------------------------ joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.5 Now using ibm-jdk-bin-1.5 as your user JVM joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Commons JXPath [INFO] task-segment: [clean, package] [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ --------------------------------------------------- constituent[0]: file:/usr/share/maven-bin-2.0/lib/maven-2.0.9-uber.jar --------------------------------------------------- java.lang.NullPointerException at java.lang.String.indexOf(String.java:792) at java.lang.String.indexOf(String.java:770) at org.apache.maven.usability.ArtifactResolverDiagnoser.diagnose(ArtifactResolverDiagnoser.java:53) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:84) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:754) at org.apache.maven.DefaultMaven.logError(DefaultMaven.java:701) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:135) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) 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) joehni@paddy ~/java/commons-jxpath-1.3-src $ java-config -s ibm-jdk-bin-1.6 Now using ibm-jdk-bin-1.6 as your user JVM joehni@paddy ~/java/commons-jxpath-1.3-src $ mvn clean package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building Commons JXPath [INFO] task-segment: [clean, package] [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] null [INFO] ------------------------------------------------------------------------ [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java:164) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleBuildInheritance(DefaultModelInheritanceAssembler.java:366) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:852) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:197) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) 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:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39) at java.lang.reflect.Method.invoke(Method.java:612) 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: 2 seconds [INFO] Finished at: Sat Jul 05 13:48:10 CEST 2008 [INFO] Final Memory: 2M/7M [INFO] ------------------------------------------------------------------------ Waiting for 1.6 SR 2
Hide
Permalink
Joakim Erdfelt added a comment - - edited

I'm reopening this. (sorry brett)

This problem occurs only on maven-2.0.9 and newer code.
It does not occur with maven-2.0.5 (for example)

It also occurs on the following IBM JDK / JRE's ...

$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled)
J9VM - 20080314_17962_lHdSMr
JIT - 20080130_0718ifx2_r8
GC - 200802_08)
JCL - 20080314

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled)
J9VM - 20060501_06428_lHdSMR
JIT - 20060428_1800_r8
GC - 20060501_AA)
JCL - 20060511a

java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled)
J9VM - 20080523_019691_lHdSMr
JIT - r9_20080522_1822
GC - 20080521_AC)
JCL - 20080522_01

/* Sorry about the multi-edits, my old keyboard apparently didn't survive the move without some gremlins */

Show
Joakim Erdfelt added a comment - - edited I'm reopening this. (sorry brett) This problem occurs only on maven-2.0.9 and newer code. It does not occur with maven-2.0.5 (for example) It also occurs on the following IBM JDK / JRE's ... $ java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20080315 (SR7)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20080315 (JIT enabled) J9VM - 20080314_17962_lHdSMr JIT - 20080130_0718ifx2_r8 GC - 200802_08) JCL - 20080314 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr2-2008527_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20080523_19691 (JIT enabled, AOT enabled) J9VM - 20080523_019691_lHdSMr JIT - r9_20080522_1822 GC - 20080521_AC) JCL - 20080522_01 /* Sorry about the multi-edits, my old keyboard apparently didn't survive the move without some gremlins */
Hide
Permalink
Brett Porter added a comment -

sure, if it's triggered by a change on the Maven end then we should look into whether it's fixable

Show
Brett Porter added a comment - sure, if it's triggered by a change on the Maven end then we should look into whether it's fixable
Hide
Permalink
Benjamin Bentmann added a comment -

I'm reopening this.

Any suggestions on how are we supposed to fix data corruption in a central collection type like ArrayList?

I built a custom Maven 2.0.9 distro from the corresponding tag which differs from the official distro only by the attached patch. The patch is adding some debug output to stderr intended to track the point where the offending null element in the ArrayList pops up. In case of harmony-629320, this was the call to ArrayList.addAll(int, Collection) in ModelUtils.java:243. Joakim, it would be interesting to see what debug logs you get for IBM JDK 1.6.

Show
Benjamin Bentmann added a comment - I'm reopening this. Any suggestions on how are we supposed to fix data corruption in a central collection type like ArrayList ? I built a custom Maven 2.0.9 distro from the corresponding tag which differs from the official distro only by the attached patch. The patch is adding some debug output to stderr intended to track the point where the offending null element in the ArrayList pops up. In case of harmony-629320, this was the call to ArrayList.addAll(int, Collection) in ModelUtils.java:243. Joakim, it would be interesting to see what debug logs you get for IBM JDK 1.6.
Hide
Permalink
Joakim Erdfelt added a comment -

Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works.

This example needs more work to show the same NPE's found in other more complex projects.

I'll attach another example when I get a use-case that is repeatable.

Show
Joakim Erdfelt added a comment - Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works. This example needs more work to show the same NPE's found in other more complex projects. I'll attach another example when I get a use-case that is repeatable.
Hide
Permalink
Benjamin Bentmann added a comment -

Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works.

OK, for this particular example, I believe the only one to blame is the POM author . The buid fails because tricky-1.1.pom is simply corrupt: According to its XML declaration, the file encoding is UTF-8. However, the octet sequence \xF8 \x6C formed by the characters "øl" is no valid UTF-8 input. The IBM JDKs before 1.6 seem to employ a strict decoder and hence abort file reading with an exception.

Reproducing the NPE is the remaining challenge...

Show
Benjamin Bentmann added a comment - Attaching a project with a simple case that shows that the IBM JDK fails while the SUN JDK works. OK, for this particular example, I believe the only one to blame is the POM author . The buid fails because tricky-1.1.pom is simply corrupt: According to its XML declaration, the file encoding is UTF-8. However, the octet sequence \xF8 \x6C formed by the characters "øl" is no valid UTF-8 input. The IBM JDKs before 1.6 seem to employ a strict decoder and hence abort file reading with an exception. Reproducing the NPE is the remaining challenge...
Hide
Permalink
Joakim Erdfelt added a comment -

Attaching MNG-3580-maven-core.patch

This patch adds a JUnit test to the maven-core project that demonstrates one of the NPEs encountered while operating within the IBM JDK.

NOTE: This patch does not fix the issue, just adds a Unit test to tickle one of the bugs.

Show
Joakim Erdfelt added a comment - Attaching MNG-3580 -maven-core.patch This patch adds a JUnit test to the maven-core project that demonstrates one of the NPEs encountered while operating within the IBM JDK. NOTE: This patch does not fix the issue, just adds a Unit test to tickle one of the bugs.
Hide
Permalink
Benjamin Bentmann added a comment -

Thanks Joakim for the test, so we have tracked down the NPE from ArtifactResolverDiagnoser to an actual Maven bug: MNG-3753

The remaining question: Is the originally reported NPE from ModelUtils still reproducible with latest IBM JDK 1.6 SR2?

Show
Benjamin Bentmann added a comment - Thanks Joakim for the test, so we have tracked down the NPE from ArtifactResolverDiagnoser to an actual Maven bug: MNG-3753 The remaining question: Is the originally reported NPE from ModelUtils still reproducible with latest IBM JDK 1.6 SR2?
Hide
Permalink
Joakim Erdfelt added a comment -

Once I roll in the patch from MNG-3573, I can now see the error messages for bad parent pom information.

The original ModelUtils NPE goes away if I fix the bad parent pom information on the corporate repository.

So, the result of all of this is ...

1) ModelUtils iterates thru a parentPlugins List that has a null entry.
2) The null entry occurs due to a pom parsing error on bad UTF8 encoding.
2.a) The IBM JDK allows this null entry to be created in the List.
3) The root cause of the null entry (the bad parsing) is incorrectly reported to the system as a Unable to Find Artifact.
4) The crucial information, "There is a bad pom" is not communicated, to the user, or the system.

I think we can close this Jira, apply MNG-3753, and create a new Jira for clearer error messages on bad poms.
Funny enough, better error messages on bad poms has (kinda) been started as MNG-3392

Show
Joakim Erdfelt added a comment - Once I roll in the patch from MNG-3573, I can now see the error messages for bad parent pom information. The original ModelUtils NPE goes away if I fix the bad parent pom information on the corporate repository. So, the result of all of this is ... 1) ModelUtils iterates thru a parentPlugins List that has a null entry. 2) The null entry occurs due to a pom parsing error on bad UTF8 encoding. 2.a) The IBM JDK allows this null entry to be created in the List. 3) The root cause of the null entry (the bad parsing) is incorrectly reported to the system as a Unable to Find Artifact. 4) The crucial information, "There is a bad pom" is not communicated, to the user, or the system. I think we can close this Jira, apply MNG-3753 , and create a new Jira for clearer error messages on bad poms. Funny enough, better error messages on bad poms has (kinda) been started as MNG-3392
Hide
Permalink
Jon Sharp added a comment -

I can confirm that upgrading to IBM JDK 1.6 SR2 (on ppc) fixed this issue for me.

Show
Jon Sharp added a comment - I can confirm that upgrading to IBM JDK 1.6 SR2 (on ppc) fixed this issue for me.
Hide
Permalink
Brett Porter added a comment -

re-closing per last 2 comments

Show
Brett Porter added a comment - re-closing per last 2 comments

People

  • Assignee:
    Brett Porter
    Reporter:
    Erik Putrycz
Vote (2)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: