Maven 2 & 3

Classloader problem when adding jars to M2_HOME

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.4
  • Fix Version/s: 3.0-alpha-1
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

Added these jars to M2_HOME/custom to allow using scm based remote repos

http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-api/1.0-beta-2/maven-scm-api-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-manager-plexus/1.0-beta-2/maven-scm-manager-plexus-1.0-beta-2.jar
http://www.ibiblio.org/maven2/org/apache/maven/scm/maven-scm-provider-svn/1.0-beta-2/maven-scm-provider-svn-1.0-beta-2.jar
http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/wagon/wagon-scm/1.0-alpha-7-SNAPSHOT/wagon-scm-1.0-alpha-7-20060308.183410-3.jar

bin/m2.conf

main is org.apache.maven.cli.MavenCli from plexus.core.maven

set maven.home default ${user.home}/m2

[plexus.core]
load ${maven.home}/core/*.jar

[plexus.core.maven]
load ${maven.home}/custom/*.jar
load ${maven.home}/lib/*.jar

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.

Issue Links

This issue is related to:
MNG-2227 Can't use repositories in protocols other than http Major Open
MNG-2228 Classloader problem loading jars from build extensions Blocker Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

you need to filter anything in lib (or custom) from turning up in plugins (in the plugin manager).

So replacing anything in lib by putting it in custom is fine, but adding stuff is not.

Show
Brett Porter added a comment - you need to filter anything in lib (or custom) from turning up in plugins (in the plugin manager). So replacing anything in lib by putting it in custom is fine, but adding stuff is not.
Hide
Permalink
Carlos Sanchez added a comment -

do you mean tweaking the PluginManager code or configuration?

Show
Carlos Sanchez added a comment - do you mean tweaking the PluginManager code or configuration?
Hide
Permalink
Brett Porter added a comment -

it's currently in code, would be good to push to configuration.

Show
Brett Porter added a comment - it's currently in code, would be good to push to configuration.
Hide
Permalink
John Casey added a comment -

this will mean changing the way we build the list of artifacts to filter out of the resolution process (because they're already in the core classloader). We'll have to find a dynamic way to manage that, which might mean installing an internal local repository for Maven itself, so we can build up an index of artifacts that are in there.

Any way we go, it represents new design to solve this problem. I think it would be better to do this in the context of design for customizing maven instances, currently planned for 2.1.

Show
John Casey added a comment - this will mean changing the way we build the list of artifacts to filter out of the resolution process (because they're already in the core classloader). We'll have to find a dynamic way to manage that, which might mean installing an internal local repository for Maven itself, so we can build up an index of artifacts that are in there. Any way we go, it represents new design to solve this problem. I think it would be better to do this in the context of design for customizing maven instances, currently planned for 2.1.
Hide
Permalink
Kenney Westerhof added a comment -

It would be better if mojo dependencies took precedence over those in the core realm, especially with all the plexus-utils problems.

Mojo's should be able to use any component version they desire. Only core components api's that are already used by the maven
core should take precedence; in this case only maven-project, maven-plugin-api and possibly maven-artifact; the rest is not needed
and can be replaced by custom versions used by mojo's.

it comes down to limiting items in mojo's parent classloader to ONLY the interfaces/instances that maven core uses and cannot
be replaced. These are: (amongst others):

  • MavenProject
  • ArtifactFactory
  • ArtifactResolution stuff

this list should be as small as possible - no implementations whatsoever should be exported to mojo's.
Here's the current list:

Loc Artifact Export to Mojo
core/ plexus-component-api-1.0-alpha-13.jar
core/ plexus-container-default-1.0-alpha-14.jar
core/ plexus-utils-1.1.jar
core/boot plexus-classworlds-1.2-alpha-5.jar
lib/ commons-cli-1.0.jar
lib/ doxia-sink-api-1.0-alpha-9-20061107.221350-3.jar
lib/ jsch-0.1.27.jar
lib/ jtidy-4aug2000r7-dev.jar
lib/ maven-artifact-2.1-SNAPSHOT.jar
lib/ maven-artifact-manager-2.1-SNAPSHOT.jar
lib/ maven-cli-2.1-SNAPSHOT.jar
lib/ maven-core-2.1-SNAPSHOT.jar
lib/ maven-embedder-2.1-SNAPSHOT.jar
lib/ maven-error-diagnostics-2.1-SNAPSHOT.jar
lib/ maven-model-2.1-SNAPSHOT.jar
lib/ maven-monitor-2.1-SNAPSHOT.jar
lib/ maven-plugin-api-2.1-SNAPSHOT.jar
lib/ maven-plugin-descriptor-2.1-SNAPSHOT.jar
lib/ maven-plugin-parameter-documenter-2.1-SNAPSHOT.jar
lib/ maven-plugin-registry-2.1-SNAPSHOT.jar
lib/ maven-profile-2.1-SNAPSHOT.jar
lib/ maven-project-2.1-SNAPSHOT.jar
lib/ maven-reporting-api-2.1-SNAPSHOT.jar
lib/ maven-repository-metadata-2.1-SNAPSHOT.jar
lib/ maven-settings-2.1-SNAPSHOT.jar
lib/ maven-tools-2.1-SNAPSHOT.jar
lib/ plexus-interactivity-api-1.0-alpha-4.jar
lib/ wagon-file-1.0-beta-2.jar
lib/ wagon-http-lightweight-1.0-beta-2.jar
lib/ wagon-http-shared-1.0-beta-2.jar
lib/ wagon-provider-api-1.0-beta-2.jar
lib/ wagon-ssh-1.0-beta-2.jar
lib/ wagon-ssh-common-1.0-beta-2.jar
lib/ wagon-ssh-external-1.0-beta-2.jar
lib/ xml-apis-1.0.b2.jar

So basically everything that's maven-version specific - only APIs, modello models and in this case also MavenProject since it
contains the runtime project representation.

I think this is easily solved by updating the m2.conf and add another classloader.

Show
Kenney Westerhof added a comment - It would be better if mojo dependencies took precedence over those in the core realm, especially with all the plexus-utils problems. Mojo's should be able to use any component version they desire. Only core components api's that are already used by the maven core should take precedence; in this case only maven-project, maven-plugin-api and possibly maven-artifact; the rest is not needed and can be replaced by custom versions used by mojo's. it comes down to limiting items in mojo's parent classloader to ONLY the interfaces/instances that maven core uses and cannot be replaced. These are: (amongst others):
  • MavenProject
  • ArtifactFactory
  • ArtifactResolution stuff
this list should be as small as possible - no implementations whatsoever should be exported to mojo's. Here's the current list:
Loc Artifact Export to Mojo
core/ plexus-component-api-1.0-alpha-13.jar
core/ plexus-container-default-1.0-alpha-14.jar
core/ plexus-utils-1.1.jar
core/boot plexus-classworlds-1.2-alpha-5.jar
lib/ commons-cli-1.0.jar
lib/ doxia-sink-api-1.0-alpha-9-20061107.221350-3.jar
lib/ jsch-0.1.27.jar
lib/ jtidy-4aug2000r7-dev.jar
lib/ maven-artifact-2.1-SNAPSHOT.jar
lib/ maven-artifact-manager-2.1-SNAPSHOT.jar
lib/ maven-cli-2.1-SNAPSHOT.jar
lib/ maven-core-2.1-SNAPSHOT.jar
lib/ maven-embedder-2.1-SNAPSHOT.jar
lib/ maven-error-diagnostics-2.1-SNAPSHOT.jar
lib/ maven-model-2.1-SNAPSHOT.jar
lib/ maven-monitor-2.1-SNAPSHOT.jar
lib/ maven-plugin-api-2.1-SNAPSHOT.jar
lib/ maven-plugin-descriptor-2.1-SNAPSHOT.jar
lib/ maven-plugin-parameter-documenter-2.1-SNAPSHOT.jar
lib/ maven-plugin-registry-2.1-SNAPSHOT.jar
lib/ maven-profile-2.1-SNAPSHOT.jar
lib/ maven-project-2.1-SNAPSHOT.jar
lib/ maven-reporting-api-2.1-SNAPSHOT.jar
lib/ maven-repository-metadata-2.1-SNAPSHOT.jar
lib/ maven-settings-2.1-SNAPSHOT.jar
lib/ maven-tools-2.1-SNAPSHOT.jar
lib/ plexus-interactivity-api-1.0-alpha-4.jar
lib/ wagon-file-1.0-beta-2.jar
lib/ wagon-http-lightweight-1.0-beta-2.jar
lib/ wagon-http-shared-1.0-beta-2.jar
lib/ wagon-provider-api-1.0-beta-2.jar
lib/ wagon-ssh-1.0-beta-2.jar
lib/ wagon-ssh-common-1.0-beta-2.jar
lib/ wagon-ssh-external-1.0-beta-2.jar
lib/ xml-apis-1.0.b2.jar
So basically everything that's maven-version specific - only APIs, modello models and in this case also MavenProject since it contains the runtime project representation. I think this is easily solved by updating the m2.conf and add another classloader.
Hide
Permalink
John Casey added a comment -

You should be able to bring in any extras now using the build extension mechanism, and only the extension components themselves will be added to the core container realm. As long as these components implement interfaces already present in the core realm, or (I suppose) represent themselves (i.e. they aren't going to be referenced by some interface they bring along in their jar) they should be available without problem.

Dependencies of these extension components are actually loaded into a per-extension realm, and the ext. component classes are imported from that realm into a project-specific realm that inherits from the core realm. This means that the core realm is available, as are the ext. components. However, the ext dependencies are isolated in their own realm, where only those ext components have access to them.

There should be no need to modify the ${maven.home}/lib directory now, since you can specify these extensions at the parent-pom level.

Show
John Casey added a comment - You should be able to bring in any extras now using the build extension mechanism, and only the extension components themselves will be added to the core container realm. As long as these components implement interfaces already present in the core realm, or (I suppose) represent themselves (i.e. they aren't going to be referenced by some interface they bring along in their jar) they should be available without problem. Dependencies of these extension components are actually loaded into a per-extension realm, and the ext. component classes are imported from that realm into a project-specific realm that inherits from the core realm. This means that the core realm is available, as are the ext. components. However, the ext dependencies are isolated in their own realm, where only those ext components have access to them. There should be no need to modify the ${maven.home}/lib directory now, since you can specify these extensions at the parent-pom level.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.