Maven
  1. Maven
  2. MNG-3580

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          Vincent Siveton added a comment -
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: