You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2005/08/03 21:22:57 UTC
[jira] Created: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
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
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43861 ]
John Casey commented on MNG-697:
--------------------------------
Brett: I'm adding this with a fix-version of -beta-1 in order to try to capture this use case before the 2.0 release. I believe it's a pretty small modification, and shouldn't take long to implement. Feel free to change the fix-version if this is wrong.
> 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
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Kenney Westerhof (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43891 ]
Kenney Westerhof commented on MNG-697:
--------------------------------------
I'm not sure wheter this is a good idea - you can't directly call those classes anyway, because then the plugin
would need a dependency on that code compile-time. You also cannot be sure if the plugin is never re-used
(depending on the instantiation-strategy in plugin.xml).
Wouldn't it be better to just ask for a ClassLoader/ClassRealm all setup with the correct classpath?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Jesse McConnell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43885 ]
Jesse McConnell commented on MNG-697:
-------------------------------------
this addresses the lionshare of MNG-681 as well, I'll close that one out.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=all ]
Brett Porter updated MNG-697:
-----------------------------
Fix Version: (was: 2.0-beta-1)
2.0-beta-2
> 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-2
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Kenney Westerhof (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_45292 ]
Kenney Westerhof commented on MNG-697:
--------------------------------------
I can confirm that there is only one classrealm created for the plugin, and that it is reused.
Meaning that static initializations are done only once, causing contamination (like caches for
dynamic discovery of components) of the 2nd plugin invocation.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=all ]
John Casey updated MNG-697:
---------------------------
Remaining Estimate: 3 hours
Original Estimate: 10800
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43968 ]
Brett Porter commented on MNG-697:
----------------------------------
can we get a specific use case here?
Integration tests may have a separate solution, so let's look beyond that.
The extensions mechanism is meant to provide extra libraries to a plugin, and one possible alternative is to allow dependencies inside a plugin element so the project can pass a dep to a plugin (though I worry about reuse of this).
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=all ]
Brett Porter closed MNG-697:
----------------------------
Resolution: Won't Fix
Fix Version: (was: 2.0-beta-2)
as per John's suggestion.
Let's open up discussion for a better extension mechanism in 2.1.
> 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
>
> Original Estimate: 3 hours
> Time Spent: 1 hour
> Remaining: 2 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Jesse McConnell (JIRA)" <ji...@codehaus.org>.
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_44290 ]
John Casey commented on MNG-697:
--------------------------------
one use case that I can think of would be using a newly minted implementation of, say, plexus-compiler, where you're doing a lookup by ROLE which is provided in -compiler-api, and using the implementation you just put together.
I guess the bottom line for me is that this doesn't amount to too much in the way of extra code to implement. I know the above use case could be implemented in other ways, but this would be far less code in the plugin itself. Personally, I'm +0 - sort of without strong opinion, but willing to implement - but I do believe its plausible to say that this could save some time and complexity in plugin development.
An alternative might be some maven-plugin-utils artifact which is on a separate release schedule, and could provide utilities for constructing/managing classloaders based on ${project.compileClasspathElements} and the like.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_46328 ]
John Casey commented on MNG-697:
--------------------------------
Just started adding this, and I'm starting to see that this will be pretty clunky to implement. First of all, at the point where we're building up the plugin container, we don't know which mojos will be executed from that container (we could assume that they all will, but...). This means several things:
1. we can't tell whether that mojo is an aggregator, and we need iterate over the reactorProjects, pulling classpath from each
2. we may wind up putting together a test-scoped classpath for one mojo, but another from the same plugin may expect that test-scope deps are NOT in the classpath...this can be mitigated by declaring the addedProjectClasspath="scope" at the plugin level, but #1 still remains.
I'm not sure that the complexity for this implementation is justified, when we can simply create a classloader using existing parameter expression results.
> 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-2
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
Posted by "Jesse McConnell (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43904 ]
Jesse McConnell commented on MNG-697:
-------------------------------------
well, the <extensions> mechanism provides a runtime tweak to the classloader for declaring a late addition
like for the maven-jdbc-plugin I put together, needs extensions to support the declaring of the driver code so it is not there at compile time.
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org