Hi Benjamin,
On 15 September 2010 17:29, Benjamin Bentmann <[email protected]> wrote:
> Maybe I miss something but won't the removal of provided and in particular
> system scope potentially break the plugin?
Potentially, if someone uses a provided or system scoped processor
dependency, which would just be weird. The original scope filtering
was based on MavenProject.getCompileClasspathElements whereas this
commit changed it to reflect getRuntimeClasspathElements.
> Also, what exactly is the purpose of this scope filtering? The only
> invocation of this method I could find was from
> AbstractAptMojo.getPluginClasspathElements() which passes in the plugin
> artifacts. Those artifacts denote the plugin runtime, what's the need to
> filter those by scope, in particular if your intention is to include all of
> them?
This is very true. It was originally intended to workaround the lack
of ${project.pluginCompileClasspathElements}, hence copying
MavenProject.getCompileClasspathElements. Now that the plugin runtime
classpath is more appropriate, perhaps we could just include all
plugin artifacts, although I'm not sure of any use-cases for including
provided, system nor test scoped plugin dependencies.
Thoughts welcome!
Mark
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
