[
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
