• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • maven-plugin
    • None
    • Platform: All, OS: All

      We're using Maven 2 to build our modules. I've created the projects in
      Hudson and set a build trigger to build whenever a SNAPSHOT dependency
      is built. Unfortunately, it doesn't appear to do this in a
      breadth-first dependency order.

      i.e.

      All of our projects bar one have as a parent our company wide pom,
      which defines repositories, profiles, etc.

      If this project is built, it kicks of a build for the world, but lots
      of them are built repeatedly.

      e.g. Project Common contains our common POM.

      Project Alpha depends on Project Gamma and Project Common.
      Project Gamma depends on Project Common only.

      If Project Common gets built, Project Alpha seems to get built next
      (due to alphabetic ordering somewhere?), then Project Gamma is built,
      and the Project Alpha is built again, since Project Gamma has just
      been built.

      When we have 20 projects, this gets a little inefficient, with certain
      projects being built 3 or 4 times when they really only should be
      built once.

        1. maven-plugin.hpi
          2.20 MB
        2. patch.txt
          19 kB
        3. patch.txt
          18 kB
        4. patch V1.2.diff
          14 kB
        5. patch V1.3.diff
          20 kB

          [JENKINS-2736] Inefficient build order for Maven2 projects

          Andrew Bayer added a comment -

          jabley - I'd suggest just running mvn in hudson/main - you don't need to build
          all the plugins.

          Andrew Bayer added a comment - jabley - I'd suggest just running mvn in hudson/main - you don't need to build all the plugins.

          mdonohue added a comment -

          If the patch was checked in on the 11th, does that mean Hudson 1.316 contains the
          maven2 plugin with this patch?

          mdonohue added a comment - If the patch was checked in on the 11th, does that mean Hudson 1.316 contains the maven2 plugin with this patch?

          Andrew Bayer added a comment -

          Yes, I believe it should be in 1.316.

          Andrew Bayer added a comment - Yes, I believe it should be in 1.316.

          Andrew Bayer added a comment -

          Ok, I finally got a chance to put together a testbed for this, and it mostly
          works. The "block build when dependency is building" logic doesn't seem to work
          quite right, though, so we still end up with excessive builds - i.e., in my
          testbed, hudson/main/pom.xml kicks off both hudson/main/cli and
          hudson/main/core, which it should just kick off hudson/main/cli, since
          hudson/main/core depends on cli. Trying to figure out what's going on in there now.

          Andrew Bayer added a comment - Ok, I finally got a chance to put together a testbed for this, and it mostly works. The "block build when dependency is building" logic doesn't seem to work quite right, though, so we still end up with excessive builds - i.e., in my testbed, hudson/main/pom.xml kicks off both hudson/main/cli and hudson/main/core, which it should just kick off hudson/main/cli, since hudson/main/core depends on cli. Trying to figure out what's going on in there now.

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/AbstractMavenBuild.java
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/AbstractMavenProject.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=19980
          Log:
          JENKINS-2736 Tweaked a couple things - should now check to see if (a) any upstream projects of a dependency are also in the list of builds to be kicked off, and if there are any, skip this dependency's build (since it'll get kicked off later), and (b) any upstream projects of a dependency are currently in queue or building, and if so, skips this dependency's build. These could possibly be folded in together, but I've got them separate for now.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/AbstractMavenBuild.java trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/AbstractMavenProject.java http://fisheye4.cenqua.com/changelog/hudson/?cs=19980 Log: JENKINS-2736 Tweaked a couple things - should now check to see if (a) any upstream projects of a dependency are also in the list of builds to be kicked off, and if there are any, skip this dependency's build (since it'll get kicked off later), and (b) any upstream projects of a dependency are currently in queue or building, and if so, skips this dependency's build. These could possibly be folded in together, but I've got them separate for now.

          Andrew Bayer added a comment -

          I think I've got this actually fixed! It's still not entirely perfect (I'm
          running into some strangeness in Hudson's logic for determining
          upstream/downstream dependencies in the first place, but that's a separate
          issue), but it's working. This'll be live in 1.317.

          Andrew Bayer added a comment - I think I've got this actually fixed! It's still not entirely perfect (I'm running into some strangeness in Hudson's logic for determining upstream/downstream dependencies in the first place, but that's a separate issue), but it's working. This'll be live in 1.317.

          Code changed in hudson
          User: : abayer
          Path:
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=19981
          Log:
          JENKINS-2736 Updating changelog for issue 2736

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=19981 Log: JENKINS-2736 Updating changelog for issue 2736

          Andrew Bayer added a comment -

          Additional testing on one Maven project with multiple modules, using the "build
          modules in parallel" option, has shown it to still be a little overeager in
          kicking off builds - I'm still trying to nail down exactly why.

          Andrew Bayer added a comment - Additional testing on one Maven project with multiple modules, using the "build modules in parallel" option, has shown it to still be a little overeager in kicking off builds - I'm still trying to nail down exactly why.

          Andrew Bayer added a comment -

          Ah. It was because I copied in the wrong private build. Whoopsie. All is good.

          Andrew Bayer added a comment - Ah. It was because I copied in the wrong private build. Whoopsie. All is good.

          Andrew Bayer added a comment -

          Fixed in 1.317.

          Andrew Bayer added a comment - Fixed in 1.317.

            abayer Andrew Bayer
            jabley jabley
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: