Maven
  1. Maven
  2. MNG-3284

Cached plugins are used, even when the specifically declared

    Details

    • Number of attachments :
      7

      Description

      In the attached project, you can build module A, then build module B, but the top level aggregator project will fail at B.

      The reason this happens is that maven seems to cache plugins. When B is built in isolation, all things are fine - but when built in aggregation, one of the plugins that it uses has already been instantiated, and so it uses that one. This is incorrect, since the declared version is different in B, and is relying on functionality not present in the version declared in A.

      I have seen similar behaviour when a plugin relies on other plugins to get work done - all of a sudden a build mysteriously stops working, because of a completely unrelated plugin.

      This is pretty painful because

      • it's possible to get into a 'no solution', where one project relies on one behaviour so can't upgrade, and one project relies on new behaviour, so can't downgrade.
      • you get builds that work OK in isolation, but not in their project. This is bad. Also builds tied together in bigger aggregator projects can fail in mysterious ways (mysterious because the user /has/ specified the plugin version, and maven has ignored them, or it's a plugin dependency that got there first)
      • subtle build ordering changes can cause new failures (the example has B depend on A - but the bug might only manifest itself in certain build orders that change even when B and A don't).
      1. 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch
        14 kB
        Nigel Magnay
      2. 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn
        14 kB
        Nigel Magnay
      3. maven-bug-2.tar
        40 kB
        Nigel Magnay
      4. MNG-3284.patch
        14 kB
        brianfox brianfox
      5. mng3284-usingCachedPlugins.tar
        50 kB
        Nigel Magnay
      6. plugin.diff
        14 kB
        Nigel Magnay
      7. pluginbug.tar
        10 kB
        Nigel Magnay

        Issue Links

          Activity

          Hide
          Nigel Magnay added a comment -

          That's ok - I'll keep plugging away at getting the tests to pass..

          Unfortunately - my tests seem to work. I must be doing something wrong.

          I'm doing
          mvn clean install
          from maven-2.0.x

          then mvn clean test (or mvn clean test -e -U -B -Prun-its)
          from maven-2.0.x/maven-core-it-runner

          I see the same tests running as in hudson, I see
          mng2744checksumVerification
          failing
          but the testit* working.

          Is there some external dependency I need to recompile? How come testitMNG2277 fails for Brian Fox but not for hudson ? Could there be some change /difference in the IT framework that I'm not picking up?

          Show
          Nigel Magnay added a comment - That's ok - I'll keep plugging away at getting the tests to pass.. Unfortunately - my tests seem to work. I must be doing something wrong. I'm doing mvn clean install from maven-2.0.x then mvn clean test (or mvn clean test -e -U -B -Prun-its) from maven-2.0.x/maven-core-it-runner I see the same tests running as in hudson, I see mng2744checksumVerification failing but the testit* working. Is there some external dependency I need to recompile? How come testitMNG2277 fails for Brian Fox but not for hudson ? Could there be some change /difference in the IT framework that I'm not picking up?
          Hide
          John Casey added a comment -

          I'm not sure why this is failing in so many different ways, but I can say that the ITs were all passing in the three environments we tested: mine, hudson, and Brian's. When we applied the patch again (today, merged from Brian's rollback on Friday/Saturday/whenever it was), we got three different failure profiles on three different machines. Yours makes four where something is failing.

          On my side, it seemed like all the ITs ran when I did the following:

          1. svn up core-integration-testing
          2. cd core-integration-testing && mvn clean install
          3. cd maven-2.0.x && mvn -P run-its,strict clean install

          Then, when I installed the newly-built copy of maven into my apps directory (just a local directory structure I have where things like Maven live), and tried to build the maven-2.0.x project once again (#3 above) using that newly-installed version, it failed with the error I gave above (two of my entries back, about the child container already existing when calling the shade plugin). To me, this is an indication that we don't have sufficient test coverage, if that error could slip by, regardless of whether all the ITs succeed or not.

          Show
          John Casey added a comment - I'm not sure why this is failing in so many different ways, but I can say that the ITs were all passing in the three environments we tested: mine, hudson, and Brian's. When we applied the patch again (today, merged from Brian's rollback on Friday/Saturday/whenever it was), we got three different failure profiles on three different machines. Yours makes four where something is failing. On my side, it seemed like all the ITs ran when I did the following: 1. svn up core-integration-testing 2. cd core-integration-testing && mvn clean install 3. cd maven-2.0.x && mvn -P run-its,strict clean install Then, when I installed the newly-built copy of maven into my apps directory (just a local directory structure I have where things like Maven live), and tried to build the maven-2.0.x project once again (#3 above) using that newly-installed version, it failed with the error I gave above (two of my entries back, about the child container already existing when calling the shade plugin). To me, this is an indication that we don't have sufficient test coverage, if that error could slip by, regardless of whether all the ITs succeed or not.
          Hide
          Nigel Magnay added a comment -

          Out of interest, what platform are you / hudson running ?

          I've tried my build on linux and OS X (though both with maven 2.0.8 and 1.5.0_13) and get the same result - it seems there's something odd. I'll try some JVM variants and windows tomorrow and try and find why I get different test resutls

          Show
          Nigel Magnay added a comment - Out of interest, what platform are you / hudson running ? I've tried my build on linux and OS X (though both with maven 2.0.8 and 1.5.0_13) and get the same result - it seems there's something odd. I'll try some JVM variants and windows tomorrow and try and find why I get different test resutls
          Hide
          John Casey added a comment -

          Pushing to 2.0.11 so we can have a smaller set of high-value issues to target for the next release (2.0.10).

          Show
          John Casey added a comment - Pushing to 2.0.11 so we can have a smaller set of high-value issues to target for the next release (2.0.10).
          Hide
          Benjamin Bentmann added a comment -

          Fixed in r591391 and r744497, respectively.

          Show
          Benjamin Bentmann added a comment - Fixed in r591391 and r744497 , respectively.

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Nigel Magnay
            • Votes:
              8 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: