Hm.
Removing the possibility for plugins to manipulate the classpath is - in my
opinion - a rather poor idea.
If we have a problem with plugins contaminating downstream classpath, then
we should provide a simple means for plugins to define Dependencies which
would be added to the classpath of the project *while the plugin executes*.
Key meaning here is that the Maven plugin API should provide these
mechanics (as opposed to plugin developers reinventing the wheel to achieve
this effect again and again) and then automagically remove the dependency
when the plugin's execute method is over.
If we have a problem with plugins concealing true classpath for reports,
then we need to revise how we expose and harvest data for these reports.
I would suggest we need something which works similar to the @Before and
@After annotations from jUnit 4, but which is limited to Dependency
management for plugins and acted upon by Maven - not left to the plugin
developer to invent on their own.
Using compiled-in annotations for static Dependency declarations in the
plugin code would not be good enough, since plugins have loads of good
reasons to add dependencies dynamically - like, for example, different
dependencies used in different JVMs (think JAXB/SAX/DOM, bytecode
manipulation or similar).
I'm suggesting that we could do something like:
@AddToClasspathDuringThisPluginExecutionOnly
public List<Dependency> getDependenciesForPluginExecution() { ... }
... where the annotation (really silly name here, but illustrates my point)
would indicate that the Dependency would be added to the project's
classpath during the plugin's execution only.
Our reporting and analytics could simply introspect the plugin for methods
annotated with said annotation to find out if they add some dynamically
computed dependencies to their own execution. While it would be impossible
acquire the correct report unless the plugin was actually run, we could
indicate that the classpath may have been manipulated by the plugin during
its execution phase.
2014-04-06 15:55 GMT+02:00 Jason van Zyl <ja...@takari.io>:
> Hi,
>
> I started making of list of things I'd like to remove in Maven 4.0.0, but
> I would like to start getting some agreement on what we can yank and this
> is the first concrete request. I would like to remove the ability for
> plugins to magically inject dependencies. Plugins can either declare their
> dependencies or instruct users to add dependencies to the plugins in their
> POMs. This weird logic for plugins to add dependencies dynamically is the
> cause of some extremely convoluted logic in the resolution code and I want
> to remove it.
>
> The original issue is here: http://jira.codehaus.org/browse/MNG-4363
>
> I encountered this when trying to hoist all the resolution logic into once
> place so that from our Aether provider resolution as it is done in the core
> can be done everywhere. Right now we have plugins like the assembly plugin,
> WAR plugin, dependency plugin that all do their own weird, inconsistent
> thing and when I tried to put it all in one place so that it can be
> analyzed, optimized and then executed this issue cropped up. We never
> should have allowed this in the first place but carried it over from 2.x
> for compatibilities sake. This might affect the code coverage tools but we
> can find a cleaner way. This logic is totally bizarro and needs to go.
>
> If everyone agrees we can start systematically documenting what has been
> removed, as we have lost track of this accurately in the past. I'd like to
> make a 4.x branch in 4 weeks or so and this will be one of the first things
> I'd like to cut. It will be one of those radical simplifications that will
> start allowing people to get a better understanding of the core as I can
> put the resolution logic in one place as it is currently in many.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> We all have problems. How we deal with them is a measure of our worth.
>
> -- Unknown
>
>
>
>
>
>
>
>
>
>
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
