[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_44001 ]
Jesse McConnell commented on MNG-697: ------------------------------------- three use cases: 1) inside of a project, to add the classes created during compile time to the plugins classpath for processes, as in process-classes phase. If you need to use reflection on the classes you have to create your own classloader to load them up. 2) inside of a project, for maven-execute-plugin where you pass to the plugin a classname and some parameters to call the .main() method on...you need to either create your own classloader to be able to get the class and method in order to invoke the tool. this is useful for allowing the to manage the classpath dependencies for commandline tools which can be simply launched through the system. 3) out of the project, I tried the <extensions> mechanism to suck on the compiled classes to just put the maven-execute-plugin in its own subproject, but that doesn't work either since, like the jdbc driver reqs for maven-jdbc-driver needed the driver code...the execute plugin can't be compiled against the project classes. as for reuse, I can't be the only person that uses the build system to process classfiles with reflection to create more source/classes (though this could be fixed with 1.5 annotations, or @javadoc spec...our source base isn't getting fixed for this until we switch to 1.5 and take a couple of days to audit a hunk of java). Or to execute class files... > 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 > > > 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]
