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

"Use private Maven repository" sometimes prevents upstream/downstream resolution

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

      I have a bunch of Maven2 projects that depend on each other, each built separately
      by Hudson. Before we upgraded to 1.318 and selected "Use private Maven repository"
      for these projects, they correctly found their upstream/downstream dependencies
      and built in the right order. Now, a change to any one project only builds it.

      I have an aggregation project that runs (sonar, findbugs, pmd etc) on a top-level
      pom over all these projects, also with a private Maven repository, and it
      correctly identifies modules and kicks off dependent builds (although I'd rather
      it didn't!), so the fact that the sub-modules don't is a bit strange.

          [JENKINS-4155] "Use private Maven repository" sometimes prevents upstream/downstream resolution

          Andrew Bayer added a comment -

          Couple questions - which version of Hudson had you upgraded from? 1.317 or
          earlier? Were you using the private Maven repos before upgrading to 1.318? (The
          description phrasing isn't entirely clear on this) The aggregation project - are
          you saying that it's kicking off the non-aggregate projects as downstream
          builds? Could you give me a quick sense of how your projects (the individual
          projects and the aggregate project) are set up, in re: top-level/modules and
          intended upstream/downstream relationships? I've got a feeling this involves
          fingerprints for the build artifacts getting confused, but I'm not entirely sure.

          Andrew Bayer added a comment - Couple questions - which version of Hudson had you upgraded from? 1.317 or earlier? Were you using the private Maven repos before upgrading to 1.318? (The description phrasing isn't entirely clear on this) The aggregation project - are you saying that it's kicking off the non-aggregate projects as downstream builds? Could you give me a quick sense of how your projects (the individual projects and the aggregate project) are set up, in re: top-level/modules and intended upstream/downstream relationships? I've got a feeling this involves fingerprints for the build artifacts getting confused, but I'm not entirely sure.

          agenticarus added a comment -

          I was on 1.317, and was not using private Maven repos before that (only found
          they existed from the Changelog for 1.318!)

          The aggregate project is kicking off non-aggregate ones
          My projects are as follows:

          foo

          • pom.xml - aggregation pom [interfaces, config, bar, baz as modules]
          • interfaces/
          • pom.xml - interfaces pom [no dependencies]
          • config/
          • pom.xml - config pom [depend on interfaces]
          • bar/
          • pom.xml - bar pom [depend on interfaces, config]
          • baz/
          • pom.xml - baz pom [depend on interfaces, config]

          I have five hudson projects, one for each subproject with subversion SCM set up
          to poll their directories, and one for the aggregator with SCM polling as well.

          If I check in a change to interfaces, both interfaces and aggregator build, but
          the project build config for interfaces does not list config, bar and baz as
          downstream projects (it DOES list the aggregator as an upstream though). Once
          the aggregator builds, interfaces, config, bar and baz build too.

          Config, Bar and Baz do not list Interfaces as an upstream project.

          Also, if any of these projects fail with test failures they are not marked as
          Unstable, but that may be completely unrelated.

          This whole setup has grown rather organically so it's possible I'm duplicating a
          lot of effort, so any suggestions on an approved way of doing this are
          appreciated (I'm happy to get rid of the top level aggregator hudson project for
          example, but like the violations warnings)

          agenticarus added a comment - I was on 1.317, and was not using private Maven repos before that (only found they existed from the Changelog for 1.318!) The aggregate project is kicking off non-aggregate ones My projects are as follows: foo pom.xml - aggregation pom [interfaces, config, bar, baz as modules] interfaces/ pom.xml - interfaces pom [no dependencies] config/ pom.xml - config pom [depend on interfaces] bar/ pom.xml - bar pom [depend on interfaces, config] baz/ pom.xml - baz pom [depend on interfaces, config] I have five hudson projects, one for each subproject with subversion SCM set up to poll their directories, and one for the aggregator with SCM polling as well. If I check in a change to interfaces, both interfaces and aggregator build, but the project build config for interfaces does not list config, bar and baz as downstream projects (it DOES list the aggregator as an upstream though). Once the aggregator builds, interfaces, config, bar and baz build too. Config, Bar and Baz do not list Interfaces as an upstream project. Also, if any of these projects fail with test failures they are not marked as Unstable, but that may be completely unrelated. This whole setup has grown rather organically so it's possible I'm duplicating a lot of effort, so any suggestions on an approved way of doing this are appreciated (I'm happy to get rid of the top level aggregator hudson project for example, but like the violations warnings)

          agenticarus added a comment -

          It definitely it appears the aggregator project is causing this issue, as a
          separate project that 'config' depends on is correctly set as upstream/downstream.

          I'll disable the aggregator for the moment

          agenticarus added a comment - It definitely it appears the aggregator project is causing this issue, as a separate project that 'config' depends on is correctly set as upstream/downstream. I'll disable the aggregator for the moment

          Andrew Bayer added a comment -

          I'm betting that if you drill down to the interfaces module in the aggregator
          project, you'll find that it has the config/bar/baz projects as downstreams,
          though I could be wrong. I have a creeping feeling this is somehow the result of
          my change to the POM parsing logic to use the private repositories at that stage
          of things - that's the only change in 1.318 I can think of which would cause
          this. I'm going to attach a private build of maven-plugin with that
          functionality removed - if you could try it out in your system and see if you're
          still getting this at that point, I'd appreciate it. Oh, and the best way to be
          sure it'll actually use the new copy of maven-plugin rather than the bundled one
          is to copy it over both the maven-plugin.hpi in $HUDSON_HOME/plugins and the
          one in the hudson/WEB-INF/plugins directory wherever it is you have Hudson
          deployed - make sure to make a backup copy of the original maven-plugin.hpi so
          you can get rid of my whackiness. =)

          Andrew Bayer added a comment - I'm betting that if you drill down to the interfaces module in the aggregator project, you'll find that it has the config/bar/baz projects as downstreams, though I could be wrong. I have a creeping feeling this is somehow the result of my change to the POM parsing logic to use the private repositories at that stage of things - that's the only change in 1.318 I can think of which would cause this. I'm going to attach a private build of maven-plugin with that functionality removed - if you could try it out in your system and see if you're still getting this at that point, I'd appreciate it. Oh, and the best way to be sure it'll actually use the new copy of maven-plugin rather than the bundled one is to copy it over both the maven-plugin.hpi in $HUDSON_HOME/plugins and the one in the hudson/WEB-INF/plugins directory wherever it is you have Hudson deployed - make sure to make a backup copy of the original maven-plugin.hpi so you can get rid of my whackiness. =)

          Andrew Bayer added a comment -

          Created an attachment (id=820)
          1.319-SNAPSHOT with POM parser no longer using private repository

          Andrew Bayer added a comment - Created an attachment (id=820) 1.319-SNAPSHOT with POM parser no longer using private repository

          agenticarus added a comment -

          As far as I can tell, this has had little effect. My 'interface' project now
          doesn't have the aggregator as an upstream project, but also doesn't have anything
          else listed as a downstream.

          agenticarus added a comment - As far as I can tell, this has had little effect. My 'interface' project now doesn't have the aggregator as an upstream project, but also doesn't have anything else listed as a downstream.

            Unassigned Unassigned
            agenticarus agenticarus
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: