[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_45291 ]
Brett Porter commented on MNG-697: ---------------------------------- yeah, I'd say go for it. While ideally you'd help construct a special classloader, that only helps for reflection - not the "implements a spec" style. So we can just add the flag in the plugin and all the project deps + target/classes will be dropped into the plugin class realm. But there's a potential gotcha here. The way the child containers are done, I think one is only ever created for the plugin, so this might not work in the reactor without reinitialising. If that's the case, I'd lean towards something similar. This will also affect if we decide to allow per-plugin dependencies and is also causing grief with extensions. We need a more sophisticated classloader hierachy. So, to sum up. If this is easy, go for it. If it is hard - put it off until we sort out the classloader situation with extensions, etc. > allow plugins to declare dependence on the project-classpath(s) > --------------------------------------------------------------- > > Key: MNG-697 > URL: http://jira.codehaus.org/browse/MNG-697 > Project: Maven 2 > Type: New Feature > Components: maven-plugin-descriptor, maven-core > Versions: 2.0-alpha-3 > Reporter: John Casey > Assignee: John Casey > Priority: Critical > Fix For: 2.0-beta-1 > > Original Estimate: 3 hours > Remaining: 3 hours > > Currently the only way to provide access to the classpath which consists of > the project artifacts within some scope from a plugin is to manually create > your own classloader inside the plugin using project.getCompileClasspath() or > somesuch. In many plugins (thinking of integration-tests where the project is > NOT an appserver module), it would be most useful to have the plugin > container started with the appropriate project-classpath already added to the > container. This might even be nice for testing plexus projects, and would > allow the plugin to simply instantiate (somehow) and use compiled classes in > order to run tests. > Jesse even tells me this would be useful from a process-classes phase, in > order to gather info about the classes that were compiled. > I propose the following modifications: > 1. Add addProjectClasspath="scope" (where scope = {compile,test...}) > configuration for the maven-plugin-plugin, alongside prefix or whatever else > we use to define the plugin-level metadata. > 2. For plugins declaring addProjectClasspath, add the appropriate project > classpath to the plugin container before calling the mojo. -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
