Classloader problem when adding jars to M2_HOME

Brett Porter added a comment - 13/Apr/06 6:59 PM 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.

Brett Porter added a comment - 13/Apr/06 7:53 PM it's currently in code, would be good to push to configuration.

John Casey added a comment - 22/Jun/06 3:16 PM 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.

Kenney Westerhof added a comment - 22/Dec/06 8:31 AM 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.

John Casey added a comment - 05/Feb/08 3:47 PM 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.