Maven 2 & 3

Classloader problem loading jars from build extensions

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.4
  • Fix Version/s: 2.0.5
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

When running "mvn install" and "mvn testwagonscm:test" in the attached test case you get a ClassCastException although the Class to assign to and the assigned one are the same. The problem seems to be that they come from different classloaders. This problem makes the project-info-report:scm goal fail.

Same as MNG-2225, but using build extensions instead of jars in M2_HOME

Issue Links

Activity

Hide
Carlos Sanchez added a comment -

This breaks generation of site when wagon-scm is in the build extensions, eg. to deploy the site to svn or cvs for Collabnet (dev.java.net)

When running site Maven tries always to instantiate projec-info-report mojos before checking in the pom for "exclude default reports" option.

The only way to generate the site was install the project-info-report plugin after removing the class ScmReport. It has to go under the same groupId, org.apache.maven.plugins, which makes it a real hack

Show
Carlos Sanchez added a comment - This breaks generation of site when wagon-scm is in the build extensions, eg. to deploy the site to svn or cvs for Collabnet (dev.java.net) When running site Maven tries always to instantiate projec-info-report mojos before checking in the pom for "exclude default reports" option. The only way to generate the site was install the project-info-report plugin after removing the class ScmReport. It has to go under the same groupId, org.apache.maven.plugins, which makes it a real hack
Hide
John Casey added a comment -

This would require some heavy refactoring to introduce a new way to manage artifacts in the core classloader during the resolution process. See MNG-2225 for more information.

Show
John Casey added a comment - This would require some heavy refactoring to introduce a new way to manage artifacts in the core classloader during the resolution process. See MNG-2225 for more information.
Hide
Carlos Sanchez added a comment -

Another worst problem is that it causes the release:prepare to fail too

Show
Carlos Sanchez added a comment - Another worst problem is that it causes the release:prepare to fail too
Hide
Carlos Sanchez added a comment -

New patch with less snapshots

Show
Carlos Sanchez added a comment - New patch with less snapshots
Hide
Brett Porter added a comment -

this caused some problems with the release plugin because jdom was in the root container (via wagon-webdav), but jaxen was not (because it is optional, so it was not caught by the resolution I added).

I have an alternate solution putting extensions in a child container like plugins which is working. I will clean up and commit tomorrow.

This could be reviewed and handled differently for trunk given the changes to plexus and classworlds. I'll examine that separately.

Show
Brett Porter added a comment - this caused some problems with the release plugin because jdom was in the root container (via wagon-webdav), but jaxen was not (because it is optional, so it was not caught by the resolution I added). I have an alternate solution putting extensions in a child container like plugins which is working. I will clean up and commit tomorrow. This could be reviewed and handled differently for trunk given the changes to plexus and classworlds. I'll examine that separately.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: