You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Nigel Magnay (JIRA)" <ji...@codehaus.org> on 2007/11/14 14:17:25 UTC
[jira] Created: (MNG-3284) Cached plugins are used, even when the
specifically declared
Cached plugins are used, even when the specifically declared
-------------------------------------------------------------
Key: MNG-3284
URL: http://jira.codehaus.org/browse/MNG-3284
Project: Maven 2
Issue Type: Bug
Components: Dependencies, Plugins and Lifecycle
Affects Versions: 2.0.7
Reporter: Nigel Magnay
Priority: Critical
Attachments: pluginbug.tar
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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127005 ]
John Casey commented on MNG-3284:
---------------------------------
I've applied the latest patch, and everything (including the IT that Brian committed) seems happy.
I'd like to provide one caveat to all of this, though:
plugin-level dependencies still cannot vary for a single plugin version in the same build. This is a particular problem when using the ant-run plugin. I'll see if I can dig up the issue (I'm sure it's been logged), and link it here. I've also got a simple test project that I can attach to the issue, which is what I've used to verify that this is indeed fixed in the Maven 2.1 code.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127565 ]
John Casey commented on MNG-3284:
---------------------------------
When I built this locally, then installed it and tried to build again with the version I just built, I got the following:
[INFO] Internal error in the plugin manager getting plugin 'org.apache.maven.plugins:maven-shade-plugin': Failed to create plugin container for plugin 'Plugin [org.apache.maven.plugins:maven-shade-plugin]': Cannot create child container, because child named 'maven-shade-plugin:org.apache.maven.plugins:1.0-beta-2-SNAPSHOT' already exists in parent 'app0'.
I haven't reproduced Brian's problem above, but this in itself signals that the patch is not careful enough to avoid duplication of plugin containers. We need to take some more time and build up a better test suite for this issue, to guard against all the different problems that can occur when you start changing the plugin classloading scheme.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127241 ]
John Casey commented on MNG-3284:
---------------------------------
I verified this also. I get the same result, except for me 2123 and 2861 are failing, but Brian tells me these are failing on his copy (with 3284 rolled back).
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127562 ]
Brian Fox commented on MNG-3284:
--------------------------------
Tried again. My test results locally are nearly identical to hudson:
Mine:
Tests in error:
testitMNG2277(org.apache.maven.integrationtests.MavenITmng2277AggregatorAndResolutionPluginsTest)
testit0104(org.apache.maven.integrationtests.MavenIT0104Test)
testit0075(org.apache.maven.integrationtests.MavenIT0075Test)
testit0074(org.apache.maven.integrationtests.MavenIT0074Test)
testit0073(org.apache.maven.integrationtests.MavenIT0073Test)
testit0071(org.apache.maven.integrationtests.MavenIT0071Test)
testit0068(org.apache.maven.integrationtests.MavenIT0068Test)
testit0064(org.apache.maven.integrationtests.MavenIT0064Test)
testit0049(org.apache.maven.integrationtests.MavenIT0049Test)
testit0046(org.apache.maven.integrationtests.MavenIT0046Test)
testit0045(org.apache.maven.integrationtests.MavenIT0045Test)
testit0041(org.apache.maven.integrationtests.MavenIT0041Test)
testit0040(org.apache.maven.integrationtests.MavenIT0040Test)
testit0027(org.apache.maven.integrationtests.MavenIT0027Test)
testit0022(org.apache.maven.integrationtests.MavenIT0022Test)
testit0018(org.apache.maven.integrationtests.MavenIT0018Test)
testit0012(org.apache.maven.integrationtests.MavenIT0012Test)
Hudson:
https://ci.sonatype.org/job/Maven-2.0.x-ITs/30/console
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126871 ]
Brian Fox commented on MNG-3284:
--------------------------------
perfect timing...i just finished merging in the IT.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Magnay updated MNG-3284:
------------------------------
Attachment: mng3284-usingCachedPlugins.tar
Convert JUnit test to maven integration test
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126696 ]
Brett Porter commented on MNG-3284:
-----------------------------------
this looks good to me - if you have a chance could you turn the reproduction into the integration test format?
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3284) Cached plugins are used,
even when the specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126889 ]
brianfox edited comment on MNG-3284 at 3/11/08 1:48 PM:
---------------------------------------------------------
Attaching an svn patch (MNG-3284.patch) by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash:
INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215)
If you can fix the patch and reattach, then we can include for 2.0.9
was (Author: brianfox):
Attaching an svn patch by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash:
INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215)
If you can fix the patch and reattach, then we can include for 2.0.9
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann closed MNG-3284.
----------------------------------
Assignee: Benjamin Bentmann (was: John Casey)
Resolution: Fixed
Fix Version/s: (was: 2.0.11)
3.0-alpha-1
2.1.0
Fixed in [r591391|http://svn.eu.apache.org/viewvc?view=rev&revision=591391] and [r744497|http://svn.eu.apache.org/viewvc?view=rev&revision=744497], respectively.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Benjamin Bentmann
> Priority: Critical
> Fix For: 2.1.0, 3.0-alpha-1
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Magnay updated MNG-3284:
------------------------------
Attachment: maven-bug-2.tar
This is an easy-to-reproduce test :
Build the module mojo
Build the module mojo2
then from top level do
mvn install
it should use 2 different versions, you can observe that it only uses one.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Attachments: maven-bug-2.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127575 ]
John Casey commented on MNG-3284:
---------------------------------
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.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.10
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126778 ]
Brian Fox commented on MNG-3284:
--------------------------------
any chance you can make that patch against svn?
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox updated MNG-3284:
---------------------------
Attachment: MNG-3284.patch
Attaching an svn patch by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash:
INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found.
at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329)
at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215)
If you can fix the patch and reattach, then we can include for 2.0.9
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Magnay updated MNG-3284:
------------------------------
Attachment: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch
This is my initial attempt at a fix, which seems to work for me.
The plugin coordinator and manager change to always use versioned identifiers (rather than 'key' which doesn't include the version).
There's some mention of version not being included - but this was never an issue (fixed already?). If there is a counterexample of where this fix won't work, I'd be happy to work a bit further on it...
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Magnay updated MNG-3284:
------------------------------
Attachment: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn
I think this should apply with SVN (if that's what you meant?) - it's the same patch but with --no-prefix; I'm told tortoiseSVN is a bit picky about patch formats..
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox updated MNG-3284:
---------------------------
Fix Version/s: 2.0.9
Identified as blocker to upgrading. Lets try to include this (even has an IT)
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127184 ]
Nigel Magnay commented on MNG-3284:
-----------------------------------
Hmm - that's confusing me.
On my machine, both trunk and trunk-1 (without and with the patch respectively) both only have 1 IT failure, in testitMNG2861 - I've updated the core-it tests and rebuilt, so I don't see why I get different results.
So I must be doing something wrong; I'm currently re-running on my machine with the same commandline that I can see from the hudson build to see what happens.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126881 ]
Brian Fox commented on MNG-3284:
--------------------------------
patch doesn't work, it still has git junk in there. I'll try to do it manually
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127185 ]
Nigel Magnay commented on MNG-3284:
-----------------------------------
I've just executed the following:
svn co -r 636941 https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x /tmp/maven-2.0.x
cd /tmp/maven-2.0.x
mvn clean install -B -U -e -Dmaven.repo.local=/tmp/maven-2.0.x.repo -Pstrict,run-its -Dsurefire.useFile=false
And still things seem to be happy bar 2861..
?
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127597 ]
Nigel Magnay commented on MNG-3284:
-----------------------------------
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
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.10
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127282 ]
Brian Fox commented on MNG-3284:
--------------------------------
we will retry the patch once everything is stabilized. I know that as soon as I rolled it back, everything was ok, both on my machine and the hudson one and the error was the same as I saw when I applied it originally.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nigel Magnay updated MNG-3284:
------------------------------
Attachment: plugin.diff
Ok - I've re-rolled the patch, and tried to execute it as an SVN diff.
I've run it against the current set of 2.0.9 ITs and it seems to work.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: Brian Fox
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey closed MNG-3284.
---------------------------
Resolution: Fixed
Applied the latest patch, and everything seems good.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox reopened MNG-3284:
----------------------------
This is still causing problems. See the IT output here: https://ci.sonatype.org/job/Maven-2.0.x-freestyle/18/console
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.9
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MNG-3284:
----------------------------
Fix Version/s: (was: 2.0.9)
2.0.10
We simply cannot be certain of this patch without more tests to check that the plugin classloaders are being constructed correctly. We're seeing too many different problems that are hard to reproduce consistently. It also will probably be useful to look at the documentation for the plugin and extension classloading refactor that I did for 2.1, once I get those docs done (next on my TODO list once 2.0.9 is staged).
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.10
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Nigel Magnay (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127570 ]
Nigel Magnay commented on MNG-3284:
-----------------------------------
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?
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.10
>
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, plugin.diff, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3284) Cached plugins are used, even when the
specifically declared
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126698 ]
Brett Porter commented on MNG-3284:
-----------------------------------
I'm not sure MNG-3217, MNG-3013 is related to this, but the other certainly is. I think this fix is going to be safe in the cases where it works and no worse in the cases where it doesn't. From what I remember, the plugin manager will still cache the containers based on a less comprehensive key so you might not get a complete solution with this.
I do think this would require some more comprehensive testing but is worth reviewing.
> Cached plugins are used, even when the specifically declared
> -------------------------------------------------------------
>
> Key: MNG-3284
> URL: http://jira.codehaus.org/browse/MNG-3284
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.7
> Reporter: Nigel Magnay
> Priority: Critical
> Attachments: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, maven-bug-2.tar, pluginbug.tar
>
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira