[
http://jira.codehaus.org/browse/MNG-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-4133:
----------------------------
Attachment: 0003-MNG-4133-still-working-on-resolving-all-ITs.-One-r.patch
0002-MNG-4133-Working-on-fine-tuning-the-new-extension.patch
0001-MNG-4133-Splitting-out-extensions-into-a-separate.patch
These patches represent my best progress toward resolving classloading problems
in this issue. The root problem seems to be the discrepancy between the
location from which the component definition was loaded, and the location from
which the class was loaded, in cases where a component requirement from a
shared artifact is used in two different wagons. In this case, the ssh-exe
wagon was added tot he extension container when it was brought in as a build
extension, which triggered the addition of ssh-common too. However, ssh-common
was also in the core container where it supported the scp wagon (non-external).
>From what I could tell, the scpexe wagon _would have_ worked fine in this
>case, and the scp wagon would not have, IF IT WEREN'T FOR THE WAY WAGONS ARE
>REGISTERED WITH THE WAGON MANAGER. In registering wagons, the components are
>looked up in a map using container.lookupMap(..), which instantiates, wires,
>etc. all wagons in the system. This means that even if a wagon isn't used at
>all, it will be loaded to complete this step. If instead we used
>container.getComponentDescriptors( role ) we could get a map that still is
>keyed by role-hint (which is what we really want...the keys), WITHOUT loading
>all wagons unnecesarily.
However, even just deferring this still leaves open the door for
classloading/component-loading issues, as described above. If the scpexe build
extension were added under this scenario, and then the scp wagon were used,
there would still be an error. This is what the patches are meant to address;
however, by segregating all wagons into the extension container, we eliminate
the ability to load something like the ScpWagon.class inside of a
plugin...unless ScpWagon.class is loaded from the plugin container, which will
lead to a ClassCastException if the plugin tries to cast to that class using a
wagon from WagonManager.
I don't have a solution to this problem, except to say that it looks like it
may involve some hideous classrealm inheritance from core -> extensions ->
plugin, which is what I had done when I refactored extension-loading in Maven
trunk. That was a very large change, and this looks like it's shaping up the
same way.
The patches are the best progress without getting into that, and I also have a
GIT repository with a MNG-4133 branch in it, at
http://www.commonjava.org/gitroots/maven-2.2.x.git
Maybe someone else can help figure out this last piece of the puzzle.
> ssh-external wagon can not be overridden on its own
> ---------------------------------------------------
>
> Key: MNG-4133
> URL: http://jira.codehaus.org/browse/MNG-4133
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 2.1.0
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.2.x
>
> Attachments:
> 0001-MNG-4133-Splitting-out-extensions-into-a-separate.patch,
> 0002-MNG-4133-Working-on-fine-tuning-the-new-extension.patch,
> 0003-MNG-4133-still-working-on-resolving-all-ITs.-One-r.patch
>
>
> when a project only overrides the ssh-external wagon, it causes the wagon-ssh
> that is built in to fail to load (probably because of a classloading conflict
> with ssh-common). See the linked issue for details.
> A couple of fixes are needed here:
> - don't crash the entire extension loading mechanism because one extension
> failed to load
> - possibly shade the common ssh JAR in the core so it doesn't cause the
> conflict in the first place.
--
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
