Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2295

Jenkins cannot handle modules added by profiles - if profile is not activated via '-P' (was: Assertion in MavenModuleSetBuild for aggregator POM with modules provided by profile)

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None
    • Platform: All, OS: All

      The root POM of one of our Maven2 projects aggregates sub-modules which are
      defined in a set of profiles. So within this POM there's no <modules> defined
      outside of a profile.

      Building this project from the commandline via "mvn -P<profile1>,<profileN>
      clean install" is working like a charme. But using the same commandline from
      within a Hudson (build 2.251) Maven2 job the following exception occurs after
      installing the root POM and starting to clean the first of the aggregated
      sub-modules:

      [INFO] ------------------------------------------------------------------------
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] reporters.get(com.acme.vk.backend:base)==null.
      reporters=

      {com.acme.vk:base=[hudson.maven.reporters.MavenMailer@260657, hudson.maven.reporters.MavenArtifactArchiver@16339b2, hudson.maven.reporters.MavenFingerprinter@c2ea0b, hudson.maven.reporters.MavenJavadocArchiver@6a4209, hudson.maven.reporters.MavenSiteArchiver@1575b4, hudson.maven.reporters.SurefireArchiver@e284ab, hudson.maven.reporters.BuildInfoRecorder@1743073]}

      proxies=

      {com.acme.vk:base=hudson.maven.MavenModuleSetBuild$Builder$FilterImpl@118e241}

      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      java.lang.AssertionError: reporters.get(com.acme.vk.backend:base)==null.
      reporters=

      {com.acme.vk:base=[hudson.maven.reporters.MavenMailer@260657, hudson.maven.reporters.MavenArtifactArchiver@16339b2, hudson.maven.reporters.MavenFingerprinter@c2ea0b, hudson.maven.reporters.MavenJavadocArchiver@6a4209, hudson.maven.reporters.MavenSiteArchiver@1575b4, hudson.maven.reporters.SurefireArchiver@e284ab, hudson.maven.reporters.BuildInfoRecorder@1743073]}

      proxies=

      {com.acme.vk:base=hudson.maven.MavenModuleSetBuild$Builder$FilterImpl@118e241}

      at
      hudson.maven.MavenModuleSetBuild$Builder.postModule(MavenModuleSetBuild.java:573)
      at hudson.maven.MavenBuilder$Adapter.fireLeaveModule(MavenBuilder.java:284)
      at hudson.maven.MavenBuilder$Adapter.postBuild(MavenBuilder.java:242)
      at
      org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:45)
      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: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 hudson.maven.agent.Main.launch(Main.java:133)
      at hudson.maven.MavenBuilder.call(MavenBuilder.java:139)
      at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:543)
      at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:489)
      at hudson.remoting.UserRequest.perform(UserRequest.java:69)
      at hudson.remoting.UserRequest.perform(UserRequest.java:23)
      at hudson.remoting.Request$2.run(Request.java:213)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
      at java.util.concurrent.FutureTask.run(FutureTask.java:123)
      at
      java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
      at java.lang.Thread.run(Thread.java:595)

      Copying the <modules> block from one of the profiles directly into the root POM
      "fixes" this issue.

          [JENKINS-2295] Jenkins cannot handle modules added by profiles - if profile is not activated via '-P' (was: Assertion in MavenModuleSetBuild for aggregator POM with modules provided by profile)

          Testcase to reproduce bug.

          Steps when reproducing:

          • Build project (should build ok).
          • Configure the project.
          • Ste the JDK to version 5.
          • Build the project (fails). It still lists the module for 1.6.

          Attached is the console output for the failed build.

          Matthew Buckett added a comment - Testcase to reproduce bug. Steps when reproducing: Create new Maven 2 job (eg called testcase). Set Subversion as source control. Set SVN URL https://svn.oucs.ox.ac.uk/projects/vle/sakai/testcase/ Set JDK to version 6. Maven 2.2.1, pom.xml, install target. Save Build project (should build ok). Configure the project. Ste the JDK to version 5. Build the project (fails). It still lists the module for 1.6. Attached is the console output for the failed build.

          evernat added a comment -

          reproduced using buckett's testcase submitted Nov 30, 2009, and Jenkins 1.410, Maven 2.2.1, JDK 1.6 then JDK 1.5

          evernat added a comment - reproduced using buckett's testcase submitted Nov 30, 2009, and Jenkins 1.410, Maven 2.2.1, JDK 1.6 then JDK 1.5

          kutzi added a comment -

          Updated summary to describe, what the outstanding issues are.

          kutzi added a comment - Updated summary to describe, what the outstanding issues are.

          kutzi added a comment -

          I agree with Kohsuke's comment from 13/Jul/09: we should give up to determine the modules in a separate step (i.e. the PomParser) and instead only rely on the Maven execution itself (i.e. the reactor) to provide us with info about the building project and its modules.
          This would have the additional benefit of speeding up the whole build as the separate POM parsing step wouldn't be needed anymore (not sure about this last part)

          kutzi added a comment - I agree with Kohsuke's comment from 13/Jul/09: we should give up to determine the modules in a separate step (i.e. the PomParser) and instead only rely on the Maven execution itself (i.e. the reactor) to provide us with info about the building project and its modules. This would have the additional benefit of speeding up the whole build as the separate POM parsing step wouldn't be needed anymore (not sure about this last part)

          Alon Barlev added a comment - - edited

          Not sure if related or separate issue:

          As a "maven2/3 project", if I have "-U clean deploy -P profile1,profile2" as my goals and options, everything works fine.
          If I replace that with "-U clean deploy -P ${profs}" and send down "profile1,profile2" as a string parameter called "profs", I get a NPE (stack trace below). If I run this as a free-style job, it works fine with the parameter as well.

          Jenkins 1.459
          Maven 3.0.4
          JDK 1.6

          Some log output:

          Executing Maven: -B -f d:\jenkins\workspace\sandbox\sandbox\pom.xml -U clean deploy -P profile1,profile2 -Dprofs=profile1,profile2

          ...

          mavenExecutionResult exceptions not empty
          message : Internal error: java.lang.NullPointerException
          cause : null
          Stack trace :
          org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException
          at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
          at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
          at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
          at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
          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:597)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
          at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
          at hudson.maven.Maven3Builder.call(Maven3Builder.java:104)
          at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
          at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          at hudson.remoting.Request$2.run(Request.java:287)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          at java.lang.Thread.run(Thread.java:619)
          Caused by: java.lang.NullPointerException
          at hudson.maven.Maven3Builder$MavenExecutionListener.recordProjectStarted(Maven3Builder.java:286)
          at hudson.maven.Maven3Builder$MavenExecutionListener.projectStarted(Maven3Builder.java:276)
          at org.jfrog.build.extractor.maven.BuildInfoRecorder.projectStarted(BuildInfoRecorder.java:149)
          at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:71)
          at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:78)
          ... 24 more

          Alon Barlev added a comment - - edited Not sure if related or separate issue: As a "maven2/3 project", if I have "-U clean deploy -P profile1,profile2" as my goals and options, everything works fine. If I replace that with "-U clean deploy -P ${profs}" and send down "profile1,profile2" as a string parameter called "profs", I get a NPE (stack trace below). If I run this as a free-style job, it works fine with the parameter as well. Jenkins 1.459 Maven 3.0.4 JDK 1.6 Some log output: Executing Maven: -B -f d:\jenkins\workspace\sandbox\sandbox\pom.xml -U clean deploy -P profile1,profile2 -Dprofs=profile1,profile2 ... mavenExecutionResult exceptions not empty message : Internal error: java.lang.NullPointerException cause : null Stack trace : org.apache.maven.InternalErrorException: Internal error: java.lang.NullPointerException at org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:104) at hudson.maven.Maven3Builder.call(Maven3Builder.java:70) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at hudson.maven.Maven3Builder$MavenExecutionListener.recordProjectStarted(Maven3Builder.java:286) at hudson.maven.Maven3Builder$MavenExecutionListener.projectStarted(Maven3Builder.java:276) at org.jfrog.build.extractor.maven.BuildInfoRecorder.projectStarted(BuildInfoRecorder.java:149) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:71) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:78) ... 24 more

          Jay Blanton added a comment - - edited

          We are having the exact same issue. We just upgraded to the latest Hudson hoping a newer version of Hudson would resolve this issue, but it does not.

          It seems that when we run this with a Maven 2.2.12 (for instance), we receive a different type of error, but when we run with Maven 3.0.4, we receive the same error.

          We utilize the parameterized builds, so that we can minimize the amount of jobs that need to be created and taking advantage of the build form to provide the profiles (which contain modules), but this currently doesn't work (same details as Alon logged). So everytime a user would want to run a job, they would have to modify it first to hard-code the profile...or create duplicate jobs with a hard-coded profile...which really doesn't take advantage of a parameterized profile.

          The interesting part (like Alon showed) is that the Hudson console output displays that it is running the correct maven command and if you have many modules, it appears to start constructing the reactor correctly, but then Hudson dies trying to run the first module pom.

          Jay Blanton added a comment - - edited We are having the exact same issue. We just upgraded to the latest Hudson hoping a newer version of Hudson would resolve this issue, but it does not. It seems that when we run this with a Maven 2.2.12 (for instance), we receive a different type of error, but when we run with Maven 3.0.4, we receive the same error. We utilize the parameterized builds, so that we can minimize the amount of jobs that need to be created and taking advantage of the build form to provide the profiles (which contain modules), but this currently doesn't work (same details as Alon logged). So everytime a user would want to run a job, they would have to modify it first to hard-code the profile...or create duplicate jobs with a hard-coded profile...which really doesn't take advantage of a parameterized profile. The interesting part (like Alon showed) is that the Hudson console output displays that it is running the correct maven command and if you have many modules, it appears to start constructing the reactor correctly, but then Hudson dies trying to run the first module pom.

          Javatar 007 added a comment -

          might be identical, the exception "reporters.get=

          {...}

          ==null" related to maven profile seems to be the same.

          Javatar 007 added a comment - might be identical, the exception "reporters.get= {...} ==null" related to maven profile seems to be the same.

          Yves DM added a comment -

          Encountered this bug...

          Yves DM added a comment - Encountered this bug...

          same on Jenkins 1.521

          Cosmin Vacaroiu added a comment - same on Jenkins 1.521

          Patrick Decat added a comment -

          I had the same issue with Maven 3.0.4, upgrading to Maven 3.1.1 fixed it.

          Patrick Decat added a comment - I had the same issue with Maven 3.0.4, upgrading to Maven 3.1.1 fixed it.

            Unassigned Unassigned
            tjuerge tjuerge
            Votes:
            13 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: