On Apr 6, 2014, at 10:38 AM, Lennart Jörelid <[email protected]> wrote:
> Hm.
>
> Removing the possibility for plugins to manipulate the classpath is - in my
> opinion - a rather poor idea.
I believe the opposite in that magically manipulating the classpath is a poor
idea. As evidenced in the convoluted logic in the core. There are a number of
other ways for plugins to alter the classpath, and if it is required of a
project to have additions that a plugin requires then it should be explicit. If
something is required on the classpath for test execution then it can be added
as a test scoped dependency. Adding all the complexity below as you describe is
akin to what we have and it's not worth it.
> 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 <[email protected]>:
>
>> 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: [email protected]
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
