[Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 6, 2014, at 10:38 AM, Lennart Jörelid <le...@gmail.com> 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 <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: lj@jguru.se
> | 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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

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: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins

On Apr 6, 2014, at 4:47 PM, Robert Scholte <rf...@apache.org> wrote:

> Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl <ja...@takari.io>:
> 
>> 
>> On Apr 6, 2014, at 2:24 PM, Robert Scholte <rf...@apache.org> wrote:
>> 
>>> Hi,
>>> 
>>> if we are talking about immutable classpath I agree. But there's something else which needs to be improved.
>>> Let me describe it with the maven-javadoc-plugin, but there are more plugins suffering the same problem.
>>> You must be able to specify doclettags artifact. There are dependencies, but they are not added to the classpath. These jars are added to a different argument of the javadoc executable.
>>> 
>> 
>> So the generic category is the downloading of artifacts that are passed into the command line of an executable? So the plugin already has a dependencies element but the javadoc plugin has a special element such that you can get hold of these dependencies to feed into the command line. Yes? I believe we can make this generic and prevent plugins from having to do their own resolution logic.
>> 
>>> I see two solutions:
>>> - mark these fields in the plugin as being dependencies, which must be resolved.
>>> - add a custom field to the plugin-dependency in the pom.xml, so the plugin knows which dependencies are used for which purpose.
>>> 
>>> With both solutions it should also be possible for the maven-release-plugin to verify all used dependencies, which is impossible right now.
>>> 
>> 
>> The think the second would be better. We already have a <dependencies/> element which are added to the classpath of the executing plugin, but another element like, say, <artifacts/> can just be downloaded and injected into the plugin such that it can do what it likes with the files of the downloaded artifacts. Would this satisfy the requirement of the javadoc plugin?
> 
> I think this will work. A quick look at the javadoc plugin shows me the following <artifacts/>:
> - additionalDependencies: capability to add optionnal dependencies to the javadoc classpath.
> - bootclasspathArtifacts: Specifies the artifacts where the boot classes reside.
> - docletArtifacts: Specifies multiple artifacts containing the path for the doclet starting class file (specified with the -doclet option).
> - resourcesArtifacts: A list of artifacts containing resources which should be copied into the Javadoc output directory (like stylesheets, icons, etc.).
> - tagletArtifacts: Specifies several Taglet artifacts containing the taglet class files (.class). These taglets class names will be auto-detect and so no need to specify them.
> 
> These are artifacts which must be downloaded, and they are all specified as groupId/artifactId/version. I don't see additional elements, but we need to investigate other plugins as well.
> 
> Maybe worth a separate wiki page.
> 
> thanks,
> Robert
> 
> 
>> 
>> Striving for plugins not having to specify and resolution is the goal and this would certainly help. If we stepped through all the plugins that we know of which employ their own resolution logic we can push it back into the core. This also eliminates having to expose most of the resolution system which would go a long way in not having to expose Aether. Being purely declarative, as we should, is best. It's just sort of slipped in many places because we let people get at the resolution internals.
>> 
>> Ultimately this means that what gets exposed is a very simple Artifact-like entity and a simple graph for things like the dependency plugin and enforcer and we eliminate exposing the underbelly of resolution which is a huge problem right now. Also if the artifact-like entity had actions that could be attached then very sophisticated things like what the Android people need would not require using the resolution system at all. Not sure how many people are familiar with p2 but it has the notion of actions that are associated with artifacts. So you might say I want this artifact downloaded, unpack it, and add this directory in the unpacked structure to my classpath.
>> 
>> It would be a radical simplification to basically shear off all access to the resolution system. If we had this years ago we would not have these problems we have with the switches between Maven Artifact, Sonatype Aether, and Eclipse Aether. This means that many plugins need to be remade but they will be far simpler. For Maven 4.0.0 I say go big, go simple, or go home.
>> 
>> I've been noodling around for a couple months and there are a few simple mistakes we made in the past and they have bloomed into relatively large problems. I think they are all fixable provided we just bite the bullet and start removing the janky code.
>> 
>> (I can't seem to edit anything in Confluence or I would have written more there)
>> 
>>> thanks,
>>> 
>>> Robert
>>> 
>>> 
>>> Op Sun, 06 Apr 2014 15:55:07 +0200 schreef 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>> 
>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

We know what we are, but know not what we may be.

  -- Shakespeare

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte <rf...@apache.org>]

Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl <ja...@takari.io>:

>
> On Apr 6, 2014, at 2:24 PM, Robert Scholte <rf...@apache.org> wrote:
>
>> Hi,
>>
>> if we are talking about immutable classpath I agree. But there's  
>> something else which needs to be improved.
>> Let me describe it with the maven-javadoc-plugin, but there are more  
>> plugins suffering the same problem.
>> You must be able to specify doclettags artifact. There are  
>> dependencies, but they are not added to the classpath. These jars are  
>> added to a different argument of the javadoc executable.
>>
>
> So the generic category is the downloading of artifacts that are passed  
> into the command line of an executable? So the plugin already has a  
> dependencies element but the javadoc plugin has a special element such  
> that you can get hold of these dependencies to feed into the command  
> line. Yes? I believe we can make this generic and prevent plugins from  
> having to do their own resolution logic.
>
>> I see two solutions:
>> - mark these fields in the plugin as being dependencies, which must be  
>> resolved.
>> - add a custom field to the plugin-dependency in the pom.xml, so the  
>> plugin knows which dependencies are used for which purpose.
>>
>> With both solutions it should also be possible for the  
>> maven-release-plugin to verify all used dependencies, which is  
>> impossible right now.
>>
>
> The think the second would be better. We already have a <dependencies/>  
> element which are added to the classpath of the executing plugin, but  
> another element like, say, <artifacts/> can just be downloaded and  
> injected into the plugin such that it can do what it likes with the  
> files of the downloaded artifacts. Would this satisfy the requirement of  
> the javadoc plugin?

I think this will work. A quick look at the javadoc plugin shows me the  
following <artifacts/>:
- additionalDependencies: capability to add optionnal dependencies to the  
javadoc classpath.
- bootclasspathArtifacts: Specifies the artifacts where the boot classes  
reside.
- docletArtifacts: Specifies multiple artifacts containing the path for  
the doclet starting class file (specified with the -doclet option).
- resourcesArtifacts: A list of artifacts containing resources which  
should be copied into the Javadoc output directory (like stylesheets,  
icons, etc.).
- tagletArtifacts: Specifies several Taglet artifacts containing the  
taglet class files (.class). These taglets class names will be auto-detect  
and so no need to specify them.

These are artifacts which must be downloaded, and they are all specified  
as groupId/artifactId/version. I don't see additional elements, but we  
need to investigate other plugins as well.

Maybe worth a separate wiki page.

thanks,
Robert


>
> Striving for plugins not having to specify and resolution is the goal  
> and this would certainly help. If we stepped through all the plugins  
> that we know of which employ their own resolution logic we can push it  
> back into the core. This also eliminates having to expose most of the  
> resolution system which would go a long way in not having to expose  
> Aether. Being purely declarative, as we should, is best. It's just sort  
> of slipped in many places because we let people get at the resolution  
> internals.
>
> Ultimately this means that what gets exposed is a very simple  
> Artifact-like entity and a simple graph for things like the dependency  
> plugin and enforcer and we eliminate exposing the underbelly of  
> resolution which is a huge problem right now. Also if the artifact-like  
> entity had actions that could be attached then very sophisticated things  
> like what the Android people need would not require using the resolution  
> system at all. Not sure how many people are familiar with p2 but it has  
> the notion of actions that are associated with artifacts. So you might  
> say I want this artifact downloaded, unpack it, and add this directory  
> in the unpacked structure to my classpath.
>
> It would be a radical simplification to basically shear off all access  
> to the resolution system. If we had this years ago we would not have  
> these problems we have with the switches between Maven Artifact,  
> Sonatype Aether, and Eclipse Aether. This means that many plugins need  
> to be remade but they will be far simpler. For Maven 4.0.0 I say go big,  
> go simple, or go home.
>
> I've been noodling around for a couple months and there are a few simple  
> mistakes we made in the past and they have bloomed into relatively large  
> problems. I think they are all fixable provided we just bite the bullet  
> and start removing the janky code.
>
> (I can't seem to edit anything in Confluence or I would have written  
> more there)
>
>> thanks,
>>
>> Robert
>>
>>
>> Op Sun, 06 Apr 2014 15:55:07 +0200 schreef 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 6, 2014, at 2:24 PM, Robert Scholte <rf...@apache.org> wrote:

> Hi,
> 
> if we are talking about immutable classpath I agree. But there's something else which needs to be improved.
> Let me describe it with the maven-javadoc-plugin, but there are more plugins suffering the same problem.
> You must be able to specify doclettags artifact. There are dependencies, but they are not added to the classpath. These jars are added to a different argument of the javadoc executable.
> 

So the generic category is the downloading of artifacts that are passed into the command line of an executable? So the plugin already has a dependencies element but the javadoc plugin has a special element such that you can get hold of these dependencies to feed into the command line. Yes? I believe we can make this generic and prevent plugins from having to do their own resolution logic.

> I see two solutions:
> - mark these fields in the plugin as being dependencies, which must be resolved.
> - add a custom field to the plugin-dependency in the pom.xml, so the plugin knows which dependencies are used for which purpose.
> 
> With both solutions it should also be possible for the maven-release-plugin to verify all used dependencies, which is impossible right now.
> 

The think the second would be better. We already have a <dependencies/> element which are added to the classpath of the executing plugin, but another element like, say, <artifacts/> can just be downloaded and injected into the plugin such that it can do what it likes with the files of the downloaded artifacts. Would this satisfy the requirement of the javadoc plugin?

Striving for plugins not having to specify and resolution is the goal and this would certainly help. If we stepped through all the plugins that we know of which employ their own resolution logic we can push it back into the core. This also eliminates having to expose most of the resolution system which would go a long way in not having to expose Aether. Being purely declarative, as we should, is best. It's just sort of slipped in many places because we let people get at the resolution internals.

Ultimately this means that what gets exposed is a very simple Artifact-like entity and a simple graph for things like the dependency plugin and enforcer and we eliminate exposing the underbelly of resolution which is a huge problem right now. Also if the artifact-like entity had actions that could be attached then very sophisticated things like what the Android people need would not require using the resolution system at all. Not sure how many people are familiar with p2 but it has the notion of actions that are associated with artifacts. So you might say I want this artifact downloaded, unpack it, and add this directory in the unpacked structure to my classpath.

It would be a radical simplification to basically shear off all access to the resolution system. If we had this years ago we would not have these problems we have with the switches between Maven Artifact, Sonatype Aether, and Eclipse Aether. This means that many plugins need to be remade but they will be far simpler. For Maven 4.0.0 I say go big, go simple, or go home.

I've been noodling around for a couple months and there are a few simple mistakes we made in the past and they have bloomed into relatively large problems. I think they are all fixable provided we just bite the bullet and start removing the janky code.

(I can't seem to edit anything in Confluence or I would have written more there)

> thanks,
> 
> Robert
> 
> 
> Op Sun, 06 Apr 2014 15:55:07 +0200 schreef 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

I like Robert's idea of getting all the variants in a wiki page. But I'd still like you guys to answer the initial query which was to agree on removing the magic of plugins adding things to the classpath and requiring it be specific.

On Apr 6, 2014, at 8:32 PM, Benson Margulies <bi...@gmail.com> wrote:

> It seems to me we have several concepts that might benefit from some combing.
> 
> We have 'path-like' structures. When building Java programs, we have
> the compile and test classpaths. _Within_ these classpaths, we have
> scopes. In other words, I think that the concept of a path and the
> concept of a scope should be orthogonal. The scope controls whether it
> is included in compilation, runtime, or some packaging step. Instead
> of 'scope=test', I claim it would be clearer to say 'it's in the
> 'test' classpath, and the scope is either 'compile' or 'runtime'. When
> we specify a 'dependency', we put it in some path.
> 
> We then have other logical classpaths. . Something like javadoc should
> be able to define another named classpath structure; combining the
> dependencies of the plugin's implementation with dynamic code
> (doclets, whatever) seems like a category confusion to me.
> 
> Then we get to dependencies and path-like structures that are not java
> code. The current situation in which a project's dependencies can be a
> mixture of jar files and zip files and whatnot is not pretty. What if
> I needed a jar file that contained data to be unpacked instead of
> something to add to the classpath? Jason's reference to p2's ability
> for an artifact to self-route sounds handy; I'd settle for a
> declarative idea in the pom that there is more than one kind/path of
> dependencies.
> 
> 
> On Sun, Apr 6, 2014 at 7:19 PM, Mark Derricutt <ma...@talios.com> wrote:
>> On 7 Apr 2014, at 6:24, Robert Scholte wrote:
>> 
>>> You must be able to specify doclettags artifact. There are dependencies,
>>> but they are not added to the classpath. These jars are added to a different
>>> argument of the javadoc executable.
>> 
>> 
>> Would this be possible via plugin-level custom dependency <scope> types?
>> 
>> Then the mojo, via some API gets the "docklet" scoped dependencies?
>> 
>> Mark
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 6, 2014, at 8:32 PM, Benson Margulies <bi...@gmail.com> wrote:

> It seems to me we have several concepts that might benefit from some combing.
> 
> We have 'path-like' structures. When building Java programs, we have
> the compile and test classpaths. _Within_ these classpaths, we have
> scopes. In other words, I think that the concept of a path and the
> concept of a scope should be orthogonal. The scope controls whether it
> is included in compilation, runtime, or some packaging step. Instead
> of 'scope=test', I claim it would be clearer to say 'it's in the
> 'test' classpath, and the scope is either 'compile' or 'runtime'. When
> we specify a 'dependency', we put it in some path.

For each Mojo execution a filter is created based on the scope of resolution the Mojo requests, this filter is set and is used when calling MavenProject.getArtifacts(). This method is used to create the classpath for the compiler for example, or is what you get if you inject ${project.artifacts} into your Mojo . If you use the artifact resolution mechanism yourself in a plugin you can do whatever you want. So depending on the your context and use it can be orthogonal but I believe this is the issue. Where plugins are performing something pertinent to scope the scope needs to be used, if the plugin is doing something orthogonal to scope then you don't necessarily need to consider scope. I don't believe they are orthogonal but rather scope is relevant depending on what you're doing. Compiling, compiling tests, running tests, and packaging something generally have something to do with scope.

> 
> We then have other logical classpaths. . Something like javadoc should
> be able to define another named classpath structure; combining the
> dependencies of the plugin's implementation with dynamic code
> (doclets, whatever) seems like a category confusion to me.
> 

This I believe is captured for the most part in what Robert and I discussed where you have an <artifacts/> element in a plugin which grabs a set of artifacts and a plugin is free do with these what it wishes.

> Then we get to dependencies and path-like structures that are not java
> code. The current situation in which a project's dependencies can be a
> mixture of jar files and zip files and whatnot is not pretty. What if
> I needed a jar file that contained data to be unpacked instead of
> something to add to the classpath? Jason's reference to p2's ability
> for an artifact to self-route sounds handy; I'd settle for a
> declarative idea in the pom that there is more than one kind/path of
> dependencies.

I believe a type of artifact handler with some brains might account for this, or general actions like: unpack and use this directory or take a projection of this archive.

<dependency>
  <groupId>com</groupId>
  <artifactId>crazy</artifactId>
  <version>1.0</version>
  <type>aar</type>
</dependency>

With an artifact handler like mechanism it would know to unpack the archive find the bits inside that it needs added to the classpath and adds them to the classpath. Or something specified in the dependency:

<dependency>
  <groupId>com</groupId>
  <artifactId>crazy</artifactId>
  <version>1.0</version>
  <using>
    <pathWithinArchive>fileOrDirectory</pathWithinArchive>
  </using>
</dependency>

Might not want this in Maven proper but I consider this a provisioning operation and is the only part of the system where I think a DSL is appropriate. But you get the idea where some action is execute to achieve getting the bits out of the archive that you need.

So in summary I think the scopes are necessary and contribute to the classpath depending on the context, you need to have additional capabilities for what the Javadoc plugin requires and I believe we need a more sophisticated way to provide provisioning like operations above without people having to use the resolver directly. You can do anything with the resolver but I don't think this is desirable, exposes too much and caused our Aether transition issues and forces everyone in plugins to do their own thing. 

If we enumerate the plugins and what they do exactly we can account for it all. I think between the javadoc, assmebly, enforcer, dependency, WAR, and Jetty plugin we can account for most things. If this was codified we can even have a standard way to make classloaders with sets of artifacts and alleviate that burden from plugin developers as well.

> 
> 
> On Sun, Apr 6, 2014 at 7:19 PM, Mark Derricutt <ma...@talios.com> wrote:
>> On 7 Apr 2014, at 6:24, Robert Scholte wrote:
>> 
>>> You must be able to specify doclettags artifact. There are dependencies,
>>> but they are not added to the classpath. These jars are added to a different
>>> argument of the javadoc executable.
>> 
>> 
>> Would this be possible via plugin-level custom dependency <scope> types?
>> 
>> Then the mojo, via some API gets the "docklet" scoped dependencies?
>> 
>> Mark
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor along the lines of:

        <dependency>
            <groupId>a.project.a.domain</groupId>
            <artifactId>mydomain-model</artifactId>
        </dependency>

I would claim the contrary position to Mark's - I would not want to litter
all poms in the reactor with the dependency above just because it is
imported in a project onto which several/most/all other projects in the
reactor depends. This approach violates the DontRepeatYourself principle
quite a lot. Moreover, since the dependency *is* required to get the
dependent projects to run properly I can see quite a few reasons why it
would break existing builds. Simply passing a type from the mydomain-model
as an argument to a method in a publicly available interface implies that
the mydomain-model project is required transitively.

Moreover - I find the dependency mechanism broken in the other direction
compared to Mark's view; presently we have to repeat all provided-scope
depedencies in the reactor since they are not transitively spread as
dependencies to importing projects. Loads of unnecessary POM repetition
follows, which is less than ideal since the POM can get quite bloated as
is. I would rather suggest that we need new transitive scope semantics for
provided-scope dependencies to prevent us from unnecessarily repeating
these several times in a multimodule reactor.

Thus ... I'm asking because I assume that Mark sees something I have missed
in the pom transitivity mechanism, and I want to know what that might be.


2014-04-07 9:42 GMT+02:00 Anders Hammar <an...@hammar.net>:

> I believe he's talking about what's mentioned here (see the asterix):
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> /Anders
>
>
> On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
> <le...@gmail.com>wrote:
>
> > I don't understand the difference between what you suggest here, Mark,
> and
> > simply disabling transitive dependencies.
> > Could you elaborate somewhat?
> >
> >
> > 2014-04-07 3:41 GMT+02:00 Mark Derricutt <ma...@talios.com>:
> >
> > > On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> > >
> > >  We then have other logical classpaths. . Something like javadoc should
> > >> be able to define another named classpath structure; combining the
> > >> dependencies of the plugin's implementation with dynamic code
> > >> (doclets, whatever) seems like a category confusion to me.
> > >>
> > >
> > > If we change/break this - can we PLEASE make the compilation path
> IGNORE
> > > transitive dependencies of 'compile' dependencies - if I -need- it to
> > > compile, -I- should depend on it up front.
> > >
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
>



-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[William Ferguson <wi...@xandar.com.au>]

Just wanted to through 2c in.

Jason, you mentioned supporting other uses cases such an Android builds. I
thought I'd explain what's required from that perspective.

The Android team have defined an Android archive (AAR) that holds a JAR and
various Android resources. When the AAR is declared as a dependency the JAR
needs to be added to the classpath during compilation and the Android
resources need to be processed at various phases. At the moment the
classpath needs to be modified dynamically via a LifecycleParticipant during
*afterProjectsRead*, but this has problems in certain multi-module builds.

I'd love to see a way in which the definition of the AAR dependency results
in a declarative addition of the embedded JAR to the classpath.

For mine, if a few things need to break in 4.0 to get a cleaner underlying
structure that provides more long term flexibility and stability then so be
it.

William


On Mon, Apr 7, 2014 at 5:42 PM, Anders Hammar <an...@hammar.net> wrote:

> I believe he's talking about what's mentioned here (see the asterix):
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> /Anders
>
>
> On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
> <le...@gmail.com>wrote:
>
> > I don't understand the difference between what you suggest here, Mark,
> and
> > simply disabling transitive dependencies.
> > Could you elaborate somewhat?
> >
> >
> > 2014-04-07 3:41 GMT+02:00 Mark Derricutt <ma...@talios.com>:
> >
> > > On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> > >
> > >  We then have other logical classpaths. . Something like javadoc should
> > >> be able to define another named classpath structure; combining the
> > >> dependencies of the plugin's implementation with dynamic code
> > >> (doclets, whatever) seems like a category confusion to me.
> > >>
> > >
> > > If we change/break this - can we PLEASE make the compilation path
> IGNORE
> > > transitive dependencies of 'compile' dependencies - if I -need- it to
> > > compile, -I- should depend on it up front.
> > >
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
> >
>

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Anders Hammar <an...@hammar.net>]

I believe he's talking about what's mentioned here (see the asterix):
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

/Anders


On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
<le...@gmail.com>wrote:

> I don't understand the difference between what you suggest here, Mark, and
> simply disabling transitive dependencies.
> Could you elaborate somewhat?
>
>
> 2014-04-07 3:41 GMT+02:00 Mark Derricutt <ma...@talios.com>:
>
> > On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> >
> >  We then have other logical classpaths. . Something like javadoc should
> >> be able to define another named classpath structure; combining the
> >> dependencies of the plugin's implementation with dynamic code
> >> (doclets, whatever) seems like a category confusion to me.
> >>
> >
> > If we change/break this - can we PLEASE make the compilation path IGNORE
> > transitive dependencies of 'compile' dependencies - if I -need- it to
> > compile, -I- should depend on it up front.
> >
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 10, 2014, at 10:07 AM, Lennart Jörelid <le...@gmail.com> wrote:

> So ... the consequence of your approach would be that POMs throughout a
> maven reactor would have to repeat a dependency declaration if the classes
> in your maven project "directly" import a type. This - to me - seems not
> only complex to resolve in a big reactor, but quite user-unfriendly as
> well. An example shows this, I think:

It is not as, it can very hard to debug what version of a dependency you are using which will be pull in transitively in the case there are conflicting versions. We always recommend users declare their direct compile time dependencies, we also recommend users declare their direct test compile time dependencies. While I may not be a complete fan of OSGi, I share their promotion of being as explicit as possible about what you directly require. The resolving mechanism can be deterministic once the requirements of a particular project is known. It's far friendlier to be able to reason about your dependencies correctly. If you don't state them all sorts of other problems arise.

> 
> You have an API Maven project where you create class AbstractSuperType as
> follows which declares a dependency to an artifact (exemplified by the
> Logger/LoggerFactory/Membership classes):
> 
> public abstract AbstractSuperType {
>   protected static final Logger log =
> LoggerFactory.getLogger(Membership.class);
> 
>   protected AbstractSuperType(String something) {
>   }
> 
>   ....
> }
> 
> You then create an Impl project where you define a class ConcreteType as
> follows:
> 
> public ConcreteType extends AbstractSuperType {
> 
>   public ConcreteType() { super("some text"); }
> 
>   private void someUtilityMethod() { log.debug("... "); }
> }
> 
> As the ConcreteType extends AbstractSuperType, which uses the
> Logger/LoggerFactory/Membership classes, Maven will be required to
> synthesize a classpath including the dependencies for all three of these
> classes in order to run the unit tests - we both agree on that. If I
> understand you correctly, you suggest that Maven's mechanics to synthesize
> the test scope classpath should include all required transitive
> dependencies (in effect runtime dependencies for jUnit) - but that Maven's
> mechanics to synthesize the compile scope class path should not. This
> implies that Maven users must understand that Maven uses two different ways
> to construct its classpath in compile and test scopes. Also, the user must
> understand that the compilation fails if the someUtilityMethod is added to
> the ConcreteType - because you would now be required to add a dependency to
> the Impl project as well.
> 
> I find it more usable to simply use the same mechanics to synthesize class
> path in compile and test scopes, implying  that transitive dependencies are
> included in the respective class path without any extra pom dependencies
> being added to parent and child projects.

I'm not recommending classpaths used different mechanisms, I'm not sure where in the thread you inferred otherwise. The issue I started this thread with is a very specific issue that applies to handful of plugins in the Maven ecosystem that non-declaratively and programmatically push dependencies into a project.

> 
> 
> 
> 2014-04-08 2:21 GMT+02:00 Mark Derricutt <ma...@talios.com>:
> 
>> On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
>> 
>> I don't understand the difference between what you suggest here, Mark, and
>>> simply disabling transitive dependencies.
>>> Could you elaborate somewhat?
>>> 
>> 
>> Well, the basics are:
>> 
>> * When compiling code, all I need to do is satisfy the contracts my
>> dependencies interfaces/public signatures. If my code fails to compile due
>> to some absent dependency ( note, this is different from a non-resolvable,
>> declared dependency ), then I should go an add a `<dependency/>` element to
>> my pom.
>> * When running tests however, you require the transitive dependencies on
>> the classpath so the upstream code _actually works_.
>> * When packaging for distribution, you require the transitives for a
>> running solution.
>> 
>> 
>> 
> 
> 
> -- 
> 
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | 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
---------------------------------------------------------

I never make the mistake of arguing with people for whose opinions I have no respect.

-- Edward Gibbon

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly <st...@gmail.com>]

Isn't the point here that compile scope would turn into runtime scope *when
transitive*?

So this is not the same as the current trick of putting
<optional>true</optional> on a dependency.

In general I am in favour if demoting dependencies to runtime when
transitive (we always warned this was the long term plan)... But I think we
do need a scope for dependencies that are an explicit contract, ie they
would *stay* compile scope, if we co that route

On Sunday, 13 April 2014, Jason van Zyl <ja...@takari.io> wrote:

>
> On Apr 13, 2014, at 8:11 AM, Lennart Jörelid <lennart.jorelid@gmail.com<javascript:;>>
> wrote:
>
> > Hello all,
> >
> > Let's see if we can focus on the issue at hand here.
> >
> > 12 apr 2014 kl. 16:59 skrev Jason van Zyl <jason@takari.io<javascript:;>
> >:
> >
> >>
> >> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid <lennart.jorelid@gmail.com<javascript:;>>
> wrote:
> >>
> >>> Oh I know it is the recommended practise, but I believe that particular
> >>> recommendation is flawed since it does not consider the needs of *big*
> >>> systems with reactors containing lots of projects.
> >>
> >> This simply is not the case. It is precisely for manageability reasons
> in large projects that you need to be specific.
> >
> > You seem to consider transitive dependencies "unspecific" or
> "unmanageable" - as opposed to the nature of explicit dependency
> declarations repeated throughout the entire reactor. This is not the case;
> in declaring a dependency to an API project from an impl project within the
> same reactor I automatically say "I will use/import the dependencies from
> the API I am implementing" ... and then adding dependency declarations used
> only by the local impl project itself. I don't want to repeat all
> dependency definitions from the API project *again* within the impl project
> since it would only add bloat to my impl project dependency definitions.
> >
>
> I'm happy to chat in IRC, but in your first sentence you make an
> assumption which isn't true and then carry on to write the rest of the
> email. Transitive dependencies are certainly manageable. I am also not
> suggesting to change the current mechanics with compile scope, and I've
> never seen any OSGi project where it didn't explicitly define its direct
> requirements so I'm interested knowing you you got that working at all. And
> while this email chain could go on for days a 20 minute chat in IRC would
> be more productive. Just pop into #maven on irc.codehaus.org and we can
> carry on there.
>
> > I believe that all of us agree that it is sensible to define a Parent
> POM containing a dependencyManagement section to harmonize versions and
> default scopes of dependencies used throughout the reactor. This implies
> that all [external] dependencies within POMs in the reactor are defined on
> the form
> >
> >        <dependency>
> >            <groupId>org.slf4j</groupId>
> >            <artifactId>slf4j-api</artifactId>
> >        </dependency>
> >
> > What you are suggesting is that we should change the current mechanics
> of Maven within compile scope (but not runtime/test scope since we would
> actually need the transitive dependencies there, if I understand your
> suggestion correctly) to force us to repeat all dependency definitions
> already present within projects I depend upon. I'm saying this is a poor
> idea, since it will require maven users to repeat the dependency (such as
> the example above) in all projects within the reactor - even if they depend
> on other projects in the reactor that already defined it. Your suggestion
> of ignoring today's transitive dependencies in compile scope would only
> make sense if you believe that the majority of people using Maven out there
> do not understand transitive dependencies at all .... implying we should make
> them repeat dependency mechanics "for clarity". In my view, this is an
> incorrect assumption.
> >
> > Let's compare the tasks required for refactoring a big reactor with the
> two mechanics:
> >
> > Whenever I would like to change the version of the slf4j-api within my
> reactor I still would need only change the dependencyManagement element in
> the parent POM. No change from today's mechanics there.
> > Whenever I would like to change the actual dependency from slf4j-api to
> something else I would need to change the code in all projects. No change
> from today.
> > If I use today's transitive dependency mechanics, I could need to alter
> the actual dependency definition in 1 project within the reactor if I so
> choose. With your suggestion I would have to change the dependency in all
> 402 projects within the reactor instead. I'm suggestion therefore that this
> is a pretty poor idea since all projects require the slf4j-api during
> runtime anyways, implying that the explicit dependency definition in all
> the projects is completely redundant information. Having the version
> defined within the parent's DependencyManagement and the dependency itself
> defined within a project I depend upon is sufficient, and requires no
> declaration repetition.
> > Your suggestion is a change in current maven mechanics which makes sense
> only for reasons of internal Maven development, but no sense for the
> *users* of Maven. That is why I suggest that your view would be impractical
> for a sensible way forwards.
> >
> >> Projects with 100, or 200, or 500 projects. If you do not declare your
> direct dependencies all manner of problems abound.
> >
> > Not at all. My last project built 402 OSGi compliant JARs without any
> problem using the current (transitive dependency) mechanics.
> > Going for your suggestion to change the maven mechanics would have
> caused us loads of extra, unnecessary work since any form of refactoring in
> terms of dependencies would have required us not only to change the code
> but also a flush of POMs. The current Maven mechanics for transitive
> dependencies implies we didn't have to change the slush of POMs and
> therefore saved us loads of work.
> >
> > Moreover, I am grateful that each POM defines only the dependencies
> unique to that project - implying I can easily see which dependencies are
> added in a chain of dependent projects within a reactor. This becomes
> difficult with your suggestion, since POMs would be cluttered with the
> transitive dependency definitions of its dependent projects.
> >
> >> The problem of repeating the version of a particular dependency, which
> is really the important aspect, is mitigated by dependencyManagement but a
> project should always declare its dependencies.
> >
> > Noone is arguing (I certainly hope) that you should avoid defining
> dependencies within the dependencyManagement section of a parent POM.
> > That is a completely separate issue from having to repeat existing
> transitive dependency declarations within all POMs in a reactor.
> >
> >>> Basically the recommendation is to repeat some information (i.e.
> dependency
> >>> specs) which is already implied/required (by depending on a project
> where
> >>> the information is already provided).
> >>>
> >>
> >> We are not. One project cannot imply the requirements of another.
> >
> > Uhm ... yes, in terms of [transitive] Dependencies which we are discussing
> here.
> > If project A depend on project B which itself Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can
> fix bad ideas, but good ideas can't save bad people.
>
>  -- Paul Graham
>
>
>
>
>
>
>
>
>
>

-- 
Sent from my phone

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 13, 2014, at 8:11 AM, Lennart Jörelid <le...@gmail.com> wrote:

> Hello all,
> 
> Let’s see if we can focus on the issue at hand here.
> 
> 12 apr 2014 kl. 16:59 skrev Jason van Zyl <ja...@takari.io>:
> 
>> 
>> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid <le...@gmail.com> wrote:
>> 
>>> Oh I know it is the recommended practise, but I believe that particular
>>> recommendation is flawed since it does not consider the needs of *big*
>>> systems with reactors containing lots of projects.
>> 
>> This simply is not the case. It is precisely for manageability reasons in large projects that you need to be specific.
> 
> You seem to consider transitive dependencies "unspecific” or ”unmanageable” - as opposed to the nature of explicit dependency declarations repeated throughout the entire reactor. This is not the case; in declaring a dependency to an API project from an impl project within the same reactor I automatically say ”I will use/import the dependencies from the API I am implementing” … and then adding dependency declarations used only by the local impl project itself. I don’t want to repeat all dependency definitions from the API project *again* within the impl project since it would only add bloat to my impl project dependency definitions.
> 

I'm happy to chat in IRC, but in your first sentence you make an assumption which isn't true and then carry on to write the rest of the email. Transitive dependencies are certainly manageable. I am also not suggesting to change the current mechanics with compile scope, and I've never seen any OSGi project where it didn't explicitly define its direct requirements so I'm interested knowing you you got that working at all. And while this email chain could go on for days a 20 minute chat in IRC would be more productive. Just pop into #maven on irc.codehaus.org and we can carry on there.

> I believe that all of us agree that it is sensible to define a Parent POM containing a dependencyManagement section to harmonize versions and default scopes of dependencies used throughout the reactor. This implies that all [external] dependencies within POMs in the reactor are defined on the form
> 
>        <dependency>
>            <groupId>org.slf4j</groupId>
>            <artifactId>slf4j-api</artifactId>
>        </dependency>
> 
> What you are suggesting is that we should change the current mechanics of Maven within compile scope (but not runtime/test scope since we would actually need the transitive dependencies there, if I understand your suggestion correctly) to force us to repeat all dependency definitions already present within projects I depend upon. I’m saying this is a poor idea, since it will require maven users to repeat the dependency (such as the example above) in all projects within the reactor - even if they depend on other projects in the reactor that already defined it. Your suggestion of ignoring today’s transitive dependencies in compile scope would only make sense if you believe that the majority of people using Maven out there do not understand transitive dependencies at all …. implying we should make them repeat dependency mechanics ”for clarity”. In my view, this is an incorrect assumption.
> 
> Let’s compare the tasks required for refactoring a big reactor with the two mechanics:
> 
> Whenever I would like to change the version of the slf4j-api within my reactor I still would need only change the dependencyManagement element in the parent POM. No change from today’s mechanics there.
> Whenever I would like to change the actual dependency from slf4j-api to something else I would need to change the code in all projects. No change from today.
> If I use today’s transitive dependency mechanics, I could need to alter the actual dependency definition in 1 project within the reactor if I so choose. With your suggestion I would have to change the dependency in all 402 projects within the reactor instead. I’m suggestion therefore that this is a pretty poor idea since all projects require the slf4j-api during runtime anyways, implying that the explicit dependency definition in all the projects is completely redundant information. Having the version defined within the parent’s DependencyManagement and the dependency itself defined within a project I depend upon is sufficient, and requires no declaration repetition. 
> Your suggestion is a change in current maven mechanics which makes sense only for reasons of internal Maven development, but no sense for the *users* of Maven. That is why I suggest that your view would be impractical for a sensible way forwards.
> 
>> Projects with 100, or 200, or 500 projects. If you do not declare your direct dependencies all manner of problems abound.
> 
> Not at all. My last project built 402 OSGi compliant JARs without any problem using the current (transitive dependency) mechanics.
> Going for your suggestion to change the maven mechanics would have caused us loads of extra, unnecessary work since any form of refactoring in terms of dependencies would have required us not only to change the code but also a flush of POMs. The current Maven mechanics for transitive dependencies implies we didn’t have to change the slush of POMs and therefore saved us loads of work.
> 
> Moreover, I am grateful that each POM defines only the dependencies unique to that project - implying I can easily see which dependencies are added in a chain of dependent projects within a reactor. This becomes difficult with your suggestion, since POMs would be cluttered with the transitive dependency definitions of its dependent projects.
> 
>> The problem of repeating the version of a particular dependency, which is really the important aspect, is mitigated by dependencyManagement but a project should always declare its dependencies.
> 
> Noone is arguing (I certainly hope) that you should avoid defining dependencies within the dependencyManagement section of a parent POM.
> That is a completely separate issue from having to repeat existing transitive dependency declarations within all POMs in a reactor.
> 
>>> Basically the recommendation is to repeat some information (i.e. dependency
>>> specs) which is already implied/required (by depending on a project where
>>> the information is already provided).
>>> 
>> 
>> We are not. One project cannot imply the requirements of another.
> 
> Uhm … yes, in terms of [transitive] Dependencies which we are discussing here.
> If project A depend on project B which itself has a defined compile-scope dependency (say C), then project A has an implied/transitive dependency to C.
> 
> That dependency is certainly required within the runtime scope of A, so I’m saying that the same visibility rules should hold for the compile scope as well.
> 
>>> Repeating redundant information is not too much of a hassle when
>>> considering small reactors with few maven projects.
>>> It is hugely annoying already when a reactor consists of around 40 projects
>>> - and such a reactor would equate only a small enterprise project,
>>> particularly if modularization like JBoss Modules, OSGi or Jigsaw is
>>> applied.
>>> 
>> 
>> In practice for many years I have not found this to be the case with large Maven projects. Not specifying your requirements, in any situation really, leads to problems.
> 
> Again, transitive dependencies are not arbitrary, incomprehensible or ”unspecified”.
> What leads to problems is people not understanding the conceptual model of how transitive dependencies are handled (or not knowing that there are several plugins that can assist in visualizing or enforcing those dependencies for them). Let’s solve the correct problem here; transitive dependencies themselves are not a problem. 
> 
>>> I can see the merit in using an immutable classpath for projects, since
>>> Maven core would get simpler and smoother mechanics.
>>> I can also see the need for some plugins to add dependencies to various
>>> classpaths - to facilitate some common operations such as instrumenting
>>> classes or the like.
>>> 
>> 
>> Or find tools which are better that don't require that. In the case of code coverage I've used Jacoco for years, it is a simple agent model and does everything else required itself without the need for other mucking with the classes. Well, it does have a offline instrumentation mode but I don't recommend using that method and neither do the Jacoco folks. So in light of modern techniques this classpath monkey patching or static instrumentation is not required anymore.
> 
> In normal enterprise settings, the build tooling is frequently not something you are at liberty to change on a whim.
> That is the reality I believe we should cater for.
> 
> 
> // Bästa hälsningar,
> // [sw. "Best regards"
> //
> // Lennart Jörelid
> // lennart.jorelid@gmail.com
> 
> 
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

Hello all,

Let’s see if we can focus on the issue at hand here.

12 apr 2014 kl. 16:59 skrev Jason van Zyl <ja...@takari.io>:

> 
> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid <le...@gmail.com> wrote:
> 
>> Oh I know it is the recommended practise, but I believe that particular
>> recommendation is flawed since it does not consider the needs of *big*
>> systems with reactors containing lots of projects.
> 
> This simply is not the case. It is precisely for manageability reasons in large projects that you need to be specific.

You seem to consider transitive dependencies "unspecific” or ”unmanageable” - as opposed to the nature of explicit dependency declarations repeated throughout the entire reactor. This is not the case; in declaring a dependency to an API project from an impl project within the same reactor I automatically say ”I will use/import the dependencies from the API I am implementing” … and then adding dependency declarations used only by the local impl project itself. I don’t want to repeat all dependency definitions from the API project *again* within the impl project since it would only add bloat to my impl project dependency definitions.

I believe that all of us agree that it is sensible to define a Parent POM containing a dependencyManagement section to harmonize versions and default scopes of dependencies used throughout the reactor. This implies that all [external] dependencies within POMs in the reactor are defined on the form

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
        </dependency>

What you are suggesting is that we should change the current mechanics of Maven within compile scope (but not runtime/test scope since we would actually need the transitive dependencies there, if I understand your suggestion correctly) to force us to repeat all dependency definitions already present within projects I depend upon. I’m saying this is a poor idea, since it will require maven users to repeat the dependency (such as the example above) in all projects within the reactor - even if they depend on other projects in the reactor that already defined it. Your suggestion of ignoring today’s transitive dependencies in compile scope would only make sense if you believe that the majority of people using Maven out there do not understand transitive dependencies at all …. implying we should make them repeat dependency mechanics ”for clarity”. In my view, this is an incorrect assumption.

Let’s compare the tasks required for refactoring a big reactor with the two mechanics:

Whenever I would like to change the version of the slf4j-api within my reactor I still would need only change the dependencyManagement element in the parent POM. No change from today’s mechanics there.
Whenever I would like to change the actual dependency from slf4j-api to something else I would need to change the code in all projects. No change from today.
If I use today’s transitive dependency mechanics, I could need to alter the actual dependency definition in 1 project within the reactor if I so choose. With your suggestion I would have to change the dependency in all 402 projects within the reactor instead. I’m suggestion therefore that this is a pretty poor idea since all projects require the slf4j-api during runtime anyways, implying that the explicit dependency definition in all the projects is completely redundant information. Having the version defined within the parent’s DependencyManagement and the dependency itself defined within a project I depend upon is sufficient, and requires no declaration repetition. 
Your suggestion is a change in current maven mechanics which makes sense only for reasons of internal Maven development, but no sense for the *users* of Maven. That is why I suggest that your view would be impractical for a sensible way forwards.

> Projects with 100, or 200, or 500 projects. If you do not declare your direct dependencies all manner of problems abound.

Not at all. My last project built 402 OSGi compliant JARs without any problem using the current (transitive dependency) mechanics.
Going for your suggestion to change the maven mechanics would have caused us loads of extra, unnecessary work since any form of refactoring in terms of dependencies would have required us not only to change the code but also a flush of POMs. The current Maven mechanics for transitive dependencies implies we didn’t have to change the slush of POMs and therefore saved us loads of work.

Moreover, I am grateful that each POM defines only the dependencies unique to that project - implying I can easily see which dependencies are added in a chain of dependent projects within a reactor. This becomes difficult with your suggestion, since POMs would be cluttered with the transitive dependency definitions of its dependent projects.

> The problem of repeating the version of a particular dependency, which is really the important aspect, is mitigated by dependencyManagement but a project should always declare its dependencies.

Noone is arguing (I certainly hope) that you should avoid defining dependencies within the dependencyManagement section of a parent POM.
That is a completely separate issue from having to repeat existing transitive dependency declarations within all POMs in a reactor.

>> Basically the recommendation is to repeat some information (i.e. dependency
>> specs) which is already implied/required (by depending on a project where
>> the information is already provided).
>> 
> 
> We are not. One project cannot imply the requirements of another.

Uhm … yes, in terms of [transitive] Dependencies which we are discussing here.
If project A depend on project B which itself has a defined compile-scope dependency (say C), then project A has an implied/transitive dependency to C.

That dependency is certainly required within the runtime scope of A, so I’m saying that the same visibility rules should hold for the compile scope as well.

>> Repeating redundant information is not too much of a hassle when
>> considering small reactors with few maven projects.
>> It is hugely annoying already when a reactor consists of around 40 projects
>> - and such a reactor would equate only a small enterprise project,
>> particularly if modularization like JBoss Modules, OSGi or Jigsaw is
>> applied.
>> 
> 
> In practice for many years I have not found this to be the case with large Maven projects. Not specifying your requirements, in any situation really, leads to problems.

Again, transitive dependencies are not arbitrary, incomprehensible or ”unspecified”.
What leads to problems is people not understanding the conceptual model of how transitive dependencies are handled (or not knowing that there are several plugins that can assist in visualizing or enforcing those dependencies for them). Let’s solve the correct problem here; transitive dependencies themselves are not a problem. 

>> I can see the merit in using an immutable classpath for projects, since
>> Maven core would get simpler and smoother mechanics.
>> I can also see the need for some plugins to add dependencies to various
>> classpaths - to facilitate some common operations such as instrumenting
>> classes or the like.
>> 
> 
> Or find tools which are better that don't require that. In the case of code coverage I've used Jacoco for years, it is a simple agent model and does everything else required itself without the need for other mucking with the classes. Well, it does have a offline instrumentation mode but I don't recommend using that method and neither do the Jacoco folks. So in light of modern techniques this classpath monkey patching or static instrumentation is not required anymore.

In normal enterprise settings, the build tooling is frequently not something you are at liberty to change on a whim.
That is the reality I believe we should cater for.


// Bästa hälsningar,
// [sw. "Best regards"
//
// Lennart Jörelid
// lennart.jorelid@gmail.com

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 12, 2014, at 7:24 AM, Lennart Jörelid <le...@gmail.com> wrote:

> Oh I know it is the recommended practise, but I believe that particular
> recommendation is flawed since it does not consider the needs of *big*
> systems with reactors containing lots of projects.

This simply is not the case. It is precisely for manageability reasons in large projects that you need to be specific. Projects with 100, or 200, or 500 projects. If you do not declare your direct dependencies all manner of problems abound. The problem of repeating the version of a particular dependency, which is really the important aspect, is mitigated by dependencyManagement but a project should always declare its dependencies. We do not enforce this right now and if you want to rely on a transitive dependency without the use of dependencyManagement then you are subject to a version of dependency that the conflict resolver hands over. You're not going to convince anyone here that's a good idea. The heuristics and data don't exist, yet, to have the system make the correct choice or at least help you make a correct choice as there are many possible correct choices. In practice you know your points of integration where you mesh conflict in your dependencies until many parts are integrated into a final runtime where you simply have to manage what goes into it, there's no real way around that. Being explicit all the way along makes analysis, integration and final provisioning manageable.

> Basically the recommendation is to repeat some information (i.e. dependency
> specs) which is already implied/required (by depending on a project where
> the information is already provided).
> 

We are not. One project cannot imply the requirements of another.

> Repeating redundant information is not too much of a hassle when
> considering small reactors with few maven projects.
> It is hugely annoying already when a reactor consists of around 40 projects
> - and such a reactor would equate only a small enterprise project,
> particularly if modularization like JBoss Modules, OSGi or Jigsaw is
> applied.
> 

In practice for many years I have not found this to be the case with large Maven projects. Not specifying your requirements, in any situation really, leads to problems.

> I can see the merit in using an immutable classpath for projects, since
> Maven core would get simpler and smoother mechanics.
> I can also see the need for some plugins to add dependencies to various
> classpaths - to facilitate some common operations such as instrumenting
> classes or the like.
> 

Or find tools which are better that don't require that. In the case of code coverage I've used Jacoco for years, it is a simple agent model and does everything else required itself without the need for other mucking with the classes. Well, it does have a offline instrumentation mode but I don't recommend using that method and neither do the Jacoco folks. So in light of modern techniques this classpath monkey patching or static instrumentation is not required anymore.

> I just don't want to have to repeat dependencies all over a reactor when
> these dependencies are already implied by normal transitive dependency
> mechanics - that would imply a huge and completely unneccessary workload.
> 
> My recommendation is to provide a core-controlled mechanics to enable
> plugins to add dependencies to *their own execution*

We do. The standard mechanism for a plugin to declare its dependencies if it requires something to run. Furthermore a plugin declaration by a user can provider additional dependencies if the plugin itself has extension points that a user can provide. Or if the plugin author has provided options where you need to have one thing on the classpath vs another then the user is instructed to add set A of dependencies to the plugin declaration vs set B. Instead of providing a configuration which the plugin acts upon internally to go fetch dependencies and modify the execution classpath. What we have is declarative and I believe is sufficient for all reasonable requirements.

> if we want to make the
> classpath immutable otherwise. Overriding the "I want to add dependencies"
> method can easily be detected by analysis tools and computed for reports,
> while preserving a simpler logic in the core for dependency resolution.
> 
> My recommendation is also to completely ignore the suggestion that we would
> have to repeat dependencies which are implied by transitive dependency
> mechanics. This would create lots of unnecessary work for bigger projects.
> 

Like I said above you can do that if you want, but it's not manageable at all. We may one day enforce that you declare all direct requirements but nothing stops you in Maven 3.x from putting a blindfold on and throwing the darts at the version selection board.

> 
> 2014-04-11 1:23 GMT+02:00 Barrie Treloar <ba...@gmail.com>:
> 
>> On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com> wrote:
>> 
>>> So ... the consequence of your approach would be that POMs throughout a
>>> maven reactor would have to repeat a dependency declaration if the
>> classes
>>> in your maven project "directly" import a type. This - to me - seems not
>>> only complex to resolve in a big reactor, but quite user-unfriendly as
>>> well. An example shows this, I think:
>>> 
>> 
>> This is the *recommended* best practice.
>> 
>> If you use something directly, then you should be explicit about that
>> dependency.
>> 
>> 
>> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
>> report failures for you so you can check.
>> 
> 
> 
> 
> -- 
> 
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | 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
---------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

Oh I know it is the recommended practise, but I believe that particular
recommendation is flawed since it does not consider the needs of *big*
systems with reactors containing lots of projects.
Basically the recommendation is to repeat some information (i.e. dependency
specs) which is already implied/required (by depending on a project where
the information is already provided).

Repeating redundant information is not too much of a hassle when
considering small reactors with few maven projects.
It is hugely annoying already when a reactor consists of around 40 projects
- and such a reactor would equate only a small enterprise project,
particularly if modularization like JBoss Modules, OSGi or Jigsaw is
applied.

I can see the merit in using an immutable classpath for projects, since
Maven core would get simpler and smoother mechanics.
I can also see the need for some plugins to add dependencies to various
classpaths - to facilitate some common operations such as instrumenting
classes or the like.

I just don't want to have to repeat dependencies all over a reactor when
these dependencies are already implied by normal transitive dependency
mechanics - that would imply a huge and completely unneccessary workload.

My recommendation is to provide a core-controlled mechanics to enable
plugins to add dependencies to *their own execution* if we want to make the
classpath immutable otherwise. Overriding the "I want to add dependencies"
method can easily be detected by analysis tools and computed for reports,
while preserving a simpler logic in the core for dependency resolution.

My recommendation is also to completely ignore the suggestion that we would
have to repeat dependencies which are implied by transitive dependency
mechanics. This would create lots of unnecessary work for bigger projects.


2014-04-11 1:23 GMT+02:00 Barrie Treloar <ba...@gmail.com>:

> On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com> wrote:
>
> > So ... the consequence of your approach would be that POMs throughout a
> > maven reactor would have to repeat a dependency declaration if the
> classes
> > in your maven project "directly" import a type. This - to me - seems not
> > only complex to resolve in a big reactor, but quite user-unfriendly as
> > well. An example shows this, I think:
> >
>
> This is the *recommended* best practice.
>
> If you use something directly, then you should be explicit about that
> dependency.
>
>
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
> report failures for you so you can check.
>



-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 12, 2014, at 8:02 AM, Hervé BOUTEMY <he...@free.fr> wrote:

>> 
>> In short, if I've followed and understood this correctly, and I may not have
>> (holiday time for me), it sounds a very bad idea Igon.
> IMHO, each choice is debatable: this should be an option in compiler plugin. 
> Something like "disableTransitiveDependencies". Notice that this wouldn't 
> require core change
> 

Only requires the use of access rules in the compiler which JDT supports and you can implement them with the modern Javac compiler. 

> Regards,
> 
> Hervé
> 
>> 
>> -Chris
>> 
>>> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlw
>>> ill report failures for you so you can check.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

There's no sense in being precise when you don't even know what you're talking about.

 -- John von Neumann

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Hervé BOUTEMY <he...@free.fr>]

Le vendredi 11 avril 2014 15:10:01 Chris Graham a écrit :
> Sent from my iPhone
> 
> On 11/04/2014, at 9:23 AM, Barrie Treloar <ba...@gmail.com> wrote:
> > On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com> wrote:
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to repeat a dependency declaration if the
> >> classes
> >> in your maven project "directly" import a type. This - to me - seems not
> >> only complex to resolve in a big reactor, but quite user-unfriendly as
> > 
> >> well. An example shows this, I think:
> > This is the *recommended* best practice.
> > 
> > If you use something directly, then you should be explicit about that
> > dependency.
> 
> If I've followed this thread and fully understood it, the proposal is to
> force the declaration of a dependency in the current Pom, even if they are
> declared as dependencies of your declared dependency, ie transitive
> dependencies.
> 
> Does this not effectively disable the use of transitive dependencies?
no, not completely: you still have automatic version calculation, and 
calculated complete transitive dependencies for run
but yes, forcing direct dependencies delclaration gives developer more work: 
we expect this gives developer more precise knowledge of his code

> 
> I find transitive dependencies one of the most useful, powerful features of
> Maven.
+1

> 
> Without them, it takes me back to the (horrid) Ant days of manually having
> walk the dependency tree.
> 
> And what of consolidation/library poms, where one Pom lists 100's of other
> jars needed? The WebSphere Process Server one (172 jars!) comes to mind.
> 
> In short, if I've followed and understood this correctly, and I may not have
> (holiday time for me), it sounds a very bad idea Igon.
IMHO, each choice is debatable: this should be an option in compiler plugin. 
Something like "disableTransitiveDependencies". Notice that this wouldn't 
require core change

Regards,

Hervé

> 
> -Chris
> 
> > http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlw
> > ill report failures for you so you can check.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar <ba...@gmail.com>]

On 11 April 2014 14:40, Chris Graham <ch...@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 11/04/2014, at 9:23 AM, Barrie Treloar <ba...@gmail.com> wrote:
>
> > On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com>
> wrote:
> >
> >> So ... the consequence of your approach would be that POMs throughout a
> >> maven reactor would have to repeat a dependency declaration if the
> classes
> >> in your maven project "directly" import a type. This - to me - seems not
> >> only complex to resolve in a big reactor, but quite user-unfriendly as
> >> well. An example shows this, I think:
> >>
> >
> > This is the *recommended* best practice.
> >
> > If you use something directly, then you should be explicit about that
> > dependency.
>
> If I've followed this thread and fully understood it, the proposal is to
> force the declaration of a dependency in the current Pom, even if they are
> declared as dependencies of your declared dependency, ie transitive
> dependencies.
>
>
This thread is about making the classpath immutable to plugins.
As per Jason's original email if a plugin wants to change the classpath
they should declare it in the plugin pom, or document that users should
declare it in their pom.



> Does this not effectively disable the use of transitive dependencies?
>
>
Additionally this thread had stuff included around Mark Derricutt's email
that suggested Maven change its behaviour so that compile time dependencies
are not transitive.
Which is what the recommended best practice is to do anyway.

Runtime would still be transitive.

>
> I find transitive dependencies one of the most useful, powerful features
> of Maven.
>
> Without them, it takes me back to the (horrid) Ant days of manually having
> walk the dependency tree.
>
> And what of consolidation/library poms, where one Pom lists 100's of other
> jars needed? The WebSphere Process Server one (172 jars!) comes to mind.
>

Consolidation or library poms would mostly contain runtime dependencies and
not be a problem.

For compile time dependencies the two ways to do this are via inheritance
or includes.
Inheritance (i.e. parent poms) works because the dependency management
defines what versions to use, and in the child you select what you actually
want.
If there are too many things to define in the child then maybe the include
way would be better.
I can't remember whether include is vaporware though...

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-best-practice.htmlsays
"There's a certain point defined more by style and experience where you
decide that minimal duplication of configuration is a small price to pay
for allowing projects [...] to remain completely independent. Designing a
huge set of thirty plus projects which all inherit five levels of POM
configuration isn't always the best idea."

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Chris Graham <ch...@gmail.com>]

Sent from my iPhone

On 11/04/2014, at 9:23 AM, Barrie Treloar <ba...@gmail.com> wrote:

> On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com> wrote:
> 
>> So ... the consequence of your approach would be that POMs throughout a
>> maven reactor would have to repeat a dependency declaration if the classes
>> in your maven project "directly" import a type. This - to me - seems not
>> only complex to resolve in a big reactor, but quite user-unfriendly as
>> well. An example shows this, I think:
>> 
> 
> This is the *recommended* best practice.
> 
> If you use something directly, then you should be explicit about that
> dependency.

If I've followed this thread and fully understood it, the proposal is to force the declaration of a dependency in the current Pom, even if they are declared as dependencies of your declared dependency, ie transitive dependencies.

Does this not effectively disable the use of transitive dependencies?

I find transitive dependencies one of the most useful, powerful features of Maven. 

Without them, it takes me back to the (horrid) Ant days of manually having walk the dependency tree.

And what of consolidation/library poms, where one Pom lists 100's of other jars needed? The WebSphere Process Server one (172 jars!) comes to mind.

In short, if I've followed and understood this correctly, and I may not have (holiday time for me), it sounds a very bad idea Igon.

-Chris

> 
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
> report failures for you so you can check.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Barrie Treloar <ba...@gmail.com>]

On 10 April 2014 23:37, Lennart Jörelid <le...@gmail.com> wrote:

> So ... the consequence of your approach would be that POMs throughout a
> maven reactor would have to repeat a dependency declaration if the classes
> in your maven project "directly" import a type. This - to me - seems not
> only complex to resolve in a big reactor, but quite user-unfriendly as
> well. An example shows this, I think:
>

This is the *recommended* best practice.

If you use something directly, then you should be explicit about that
dependency.

http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htmlwill
report failures for you so you can check.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

So ... the consequence of your approach would be that POMs throughout a
maven reactor would have to repeat a dependency declaration if the classes
in your maven project "directly" import a type. This - to me - seems not
only complex to resolve in a big reactor, but quite user-unfriendly as
well. An example shows this, I think:

You have an API Maven project where you create class AbstractSuperType as
follows which declares a dependency to an artifact (exemplified by the
Logger/LoggerFactory/Membership classes):

public abstract AbstractSuperType {
   protected static final Logger log =
LoggerFactory.getLogger(Membership.class);

   protected AbstractSuperType(String something) {
   }

   ....
}

You then create an Impl project where you define a class ConcreteType as
follows:

public ConcreteType extends AbstractSuperType {

   public ConcreteType() { super("some text"); }

   private void someUtilityMethod() { log.debug("... "); }
}

As the ConcreteType extends AbstractSuperType, which uses the
Logger/LoggerFactory/Membership classes, Maven will be required to
synthesize a classpath including the dependencies for all three of these
classes in order to run the unit tests - we both agree on that. If I
understand you correctly, you suggest that Maven's mechanics to synthesize
the test scope classpath should include all required transitive
dependencies (in effect runtime dependencies for jUnit) - but that Maven's
mechanics to synthesize the compile scope class path should not. This
implies that Maven users must understand that Maven uses two different ways
to construct its classpath in compile and test scopes. Also, the user must
understand that the compilation fails if the someUtilityMethod is added to
the ConcreteType - because you would now be required to add a dependency to
the Impl project as well.

I find it more usable to simply use the same mechanics to synthesize class
path in compile and test scopes, implying  that transitive dependencies are
included in the respective class path without any extra pom dependencies
being added to parent and child projects.



2014-04-08 2:21 GMT+02:00 Mark Derricutt <ma...@talios.com>:

> On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
>
>  I don't understand the difference between what you suggest here, Mark, and
>> simply disabling transitive dependencies.
>> Could you elaborate somewhat?
>>
>
> Well, the basics are:
>
> * When compiling code, all I need to do is satisfy the contracts my
> dependencies interfaces/public signatures. If my code fails to compile due
> to some absent dependency ( note, this is different from a non-resolvable,
> declared dependency ), then I should go an add a `<dependency/>` element to
> my pom.
> * When running tests however, you require the transitive dependencies on
> the classpath so the upstream code _actually works_.
> * When packaging for distribution, you require the transitives for a
> running solution.
>
>
>


-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Mark Derricutt <ma...@talios.com>]

On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:

> I don't understand the difference between what you suggest here, Mark, 
> and
> simply disabling transitive dependencies.
> Could you elaborate somewhat?

Well, the basics are:

* When compiling code, all I need to do is satisfy the contracts my 
dependencies interfaces/public signatures. If my code fails to compile 
due to some absent dependency ( note, this is different from a 
non-resolvable, declared dependency ), then I should go an add a 
`<dependency/>` element to my pom.
* When running tests however, you require the transitive dependencies on 
the classpath so the upstream code _actually works_.
* When packaging for distribution, you require the transitives for a 
running solution.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Lennart Jörelid <le...@gmail.com>]

I don't understand the difference between what you suggest here, Mark, and
simply disabling transitive dependencies.
Could you elaborate somewhat?


2014-04-07 3:41 GMT+02:00 Mark Derricutt <ma...@talios.com>:

> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
>
>  We then have other logical classpaths. . Something like javadoc should
>> be able to define another named classpath structure; combining the
>> dependencies of the plugin's implementation with dynamic code
>> (doclets, whatever) seems like a category confusion to me.
>>
>
> If we change/break this - can we PLEASE make the compilation path IGNORE
> transitive dependencies of 'compile' dependencies - if I -need- it to
> compile, -I- should depend on it up front.
>
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

This is really about providing access restrictions to the compiler. JDT has done this forever as OSGi requires it and it's possible with modern Javac compiler as well. It's more about what you tell the compiler to consider than our notions of scope.

On Apr 6, 2014, at 9:41 PM, Mark Derricutt <ma...@talios.com> wrote:

> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> 
>> We then have other logical classpaths. . Something like javadoc should
>> be able to define another named classpath structure; combining the
>> dependencies of the plugin's implementation with dynamic code
>> (doclets, whatever) seems like a category confusion to me.
> 
> If we change/break this - can we PLEASE make the compilation path IGNORE transitive dependencies of 'compile' dependencies - if I -need- it to compile, -I- should depend on it up front.
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible <jo...@swisspost.com>]

Hi Mark,

Mark Derricutt wrote:

> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> 
>> We then have other logical classpaths. . Something like javadoc should
>> be able to define another named classpath structure; combining the
>> dependencies of the plugin's implementation with dynamic code
>> (doclets, whatever) seems like a category confusion to me.
> 
> If we change/break this - can we PLEASE make the compilation path IGNORE
> transitive dependencies of 'compile' dependencies - if I -need- it to
> compile, -I- should depend on it up front.

I made the same request more than 7 years ago 
(https://jira.codehaus.org/browse/MNG-2589). However, you can already force 
such a mode with some own effort using a common POM with a depMgmt section 
declaring anything with runtime scope. Unfortunately such a mode reveals 
some nasty effects of the Java model and we finally gave in. See my comment 
in MNG-2589 of last year.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Mark Derricutt <ma...@talios.com>]

On 7 Apr 2014, at 12:32, Benson Margulies wrote:

> We then have other logical classpaths. . Something like javadoc should
> be able to define another named classpath structure; combining the
> dependencies of the plugin's implementation with dynamic code
> (doclets, whatever) seems like a category confusion to me.

If we change/break this - can we PLEASE make the compilation path IGNORE 
transitive dependencies of 'compile' dependencies - if I -need- it to 
compile, -I- should depend on it up front.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies <bi...@gmail.com>]

It seems to me we have several concepts that might benefit from some combing.

We have 'path-like' structures. When building Java programs, we have
the compile and test classpaths. _Within_ these classpaths, we have
scopes. In other words, I think that the concept of a path and the
concept of a scope should be orthogonal. The scope controls whether it
is included in compilation, runtime, or some packaging step. Instead
of 'scope=test', I claim it would be clearer to say 'it's in the
'test' classpath, and the scope is either 'compile' or 'runtime'. When
we specify a 'dependency', we put it in some path.

We then have other logical classpaths. . Something like javadoc should
be able to define another named classpath structure; combining the
dependencies of the plugin's implementation with dynamic code
(doclets, whatever) seems like a category confusion to me.

Then we get to dependencies and path-like structures that are not java
code. The current situation in which a project's dependencies can be a
mixture of jar files and zip files and whatnot is not pretty. What if
I needed a jar file that contained data to be unpacked instead of
something to add to the classpath? Jason's reference to p2's ability
for an artifact to self-route sounds handy; I'd settle for a
declarative idea in the pom that there is more than one kind/path of
dependencies.


On Sun, Apr 6, 2014 at 7:19 PM, Mark Derricutt <ma...@talios.com> wrote:
> On 7 Apr 2014, at 6:24, Robert Scholte wrote:
>
>> You must be able to specify doclettags artifact. There are dependencies,
>> but they are not added to the classpath. These jars are added to a different
>> argument of the javadoc executable.
>
>
> Would this be possible via plugin-level custom dependency <scope> types?
>
> Then the mojo, via some API gets the "docklet" scoped dependencies?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Mark Derricutt <ma...@talios.com>]

On 7 Apr 2014, at 6:24, Robert Scholte wrote:

> You must be able to specify doclettags artifact. There are 
> dependencies, but they are not added to the classpath. These jars are 
> added to a different argument of the javadoc executable.

Would this be possible via plugin-level custom dependency <scope> types?

Then the mojo, via some API gets the "docklet" scoped dependencies?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte <rf...@apache.org>]

Hi,

if we are talking about immutable classpath I agree. But there's something  
else which needs to be improved.
Let me describe it with the maven-javadoc-plugin, but there are more  
plugins suffering the same problem.
You must be able to specify doclettags artifact. There are dependencies,  
but they are not added to the classpath. These jars are added to a  
different argument of the javadoc executable.

I see two solutions:
- mark these fields in the plugin as being dependencies, which must be  
resolved.
- add a custom field to the plugin-dependency in the pom.xml, so the  
plugin knows which dependencies are used for which purpose.

With both solutions it should also be possible for the  
maven-release-plugin to verify all used dependencies, which is impossible  
right now.

thanks,

Robert


Op Sun, 06 Apr 2014 15:55:07 +0200 schreef 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
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

I realize folks are busy, I'll just run with this given I think we all agree immutable classpaths are better and fiddly magic in the core is bad. I'm going to remove the capability to dynamically fiddle with the project classpath and the IT for MNG-4363 will be omitted from the run for Maven 4.0.0.

On Apr 6, 2014, at 9:55 AM, Jason van Zyl <ja...@takari.io> wrote:

> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Mirko Friedenhagen <mf...@apache.org>]

What about (ab-)using the runtime scope for this? The core could inspect
the pom and inject runtime dependencies into the class path.

Regards
Mirko
-- 
Sent from my mobile
On Apr 12, 2014 2:08 PM, "Hervé BOUTEMY" <he...@free.fr> wrote:

> after thinking more at it, it seems the "scope" for such artifacts is the
> plugin parameter name
>
> so why not resolve artifacts (or collections of artifacts)  when injecting
> parameters?
> I'm not sure we really need a need elemen in pom.
>
> Regards,
>
> Hervé
>
> Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
> > Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
> >
> > <bi...@gmail.com>:
> > > On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> > >
> > > <st...@gmail.com> wrote:
> > >> On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com>
> wrote:
> > >>> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> > >>>
> > >>> into
> > >>>
> > >>> > the project class path but equally wish that the copy/unpack goals
> > >>>
> > >>> could
> > >>>
> > >>> > simply go away regardless. (in leu of the more normal
> > >>>
> > >>> xxx-dependencies
> > >>>
> > >>> > versions)
> > >>>
> > >>> If you make them go away, please find them a new home. I use them
> > >>> constantly to unpack data resources retrieved from a Maven repo. It
> > >>> seems odd that they live in a 'dependency' plugin, but it would be a
> > >>> disaster if they disappeared.
> > >>
> > >> You should be declaring the resources you are unpacking/copying as
> > >> dependencies and then using the copy-dependencies or
> unpack-dependencies
> > >> goal instead of the copy or unpack goal.
> > >
> > > I don't want them in the classpath. Even if their filenames end in
> > > '.jar'.
> >
> > The current proposal is to add an artifacts-element[1] to the plugin.
> > Dependencies are for the classpath, artifacts are additional files which
> > must be resolved, but don't belong on the classpath.
> >
> > Robert
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
> > lugins
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

I think allowing plugins to resolve things with annotations is not a good idea as we already have project dependencies resolution that happens on the fly per project. This means it's impossible to fully reason about the requirements of a project being built up front. This, in practice, leads to users building, getting a resolution error, building, getting a resolution error. While not problems can be determined from up-front analysis most of them can. I am more in favor of going the other direction where we have something purely declarative, all dependencies for the project and plugins can be reasoned about up-front and reported to the user for correction.

Ultimately I would like to get rid of on-the-fly resolution and replace it with a stage in Maven's execution that occurs before the build starts.

On Apr 12, 2014, at 8:07 AM, Hervé BOUTEMY <he...@free.fr> wrote:

> after thinking more at it, it seems the "scope" for such artifacts is the 
> plugin parameter name
> 
> so why not resolve artifacts (or collections of artifacts)  when injecting 
> parameters?
> I'm not sure we really need a need elemen in pom.
> 
> Regards,
> 
> Hervé
> 
> Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
>> Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
>> 
>> <bi...@gmail.com>:
>>> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
>>> 
>>> <st...@gmail.com> wrote:
>>>> On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
>>>>>> Fwiw, I don't recall the dependency plugin actually injecting stuff
>>>>> 
>>>>> into
>>>>> 
>>>>>> the project class path but equally wish that the copy/unpack goals
>>>>> 
>>>>> could
>>>>> 
>>>>>> simply go away regardless. (in leu of the more normal
>>>>> 
>>>>> xxx-dependencies
>>>>> 
>>>>>> versions)
>>>>> 
>>>>> If you make them go away, please find them a new home. I use them
>>>>> constantly to unpack data resources retrieved from a Maven repo. It
>>>>> seems odd that they live in a 'dependency' plugin, but it would be a
>>>>> disaster if they disappeared.
>>>> 
>>>> You should be declaring the resources you are unpacking/copying as
>>>> dependencies and then using the copy-dependencies or unpack-dependencies
>>>> goal instead of the copy or unpack goal.
>>> 
>>> I don't want them in the classpath. Even if their filenames end in
>>> '.jar'.
>> 
>> The current proposal is to add an artifacts-element[1] to the plugin.
>> Dependencies are for the classpath, artifacts are additional files which
>> must be resolved, but don't belong on the classpath.
>> 
>> Robert
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
>> lugins
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Hervé BOUTEMY <he...@free.fr>]

after thinking more at it, it seems the "scope" for such artifacts is the 
plugin parameter name

so why not resolve artifacts (or collections of artifacts)  when injecting 
parameters?
I'm not sure we really need a need elemen in pom.

Regards,

Hervé

Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit :
> Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies
> 
> <bi...@gmail.com>:
> > On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> > 
> > <st...@gmail.com> wrote:
> >> On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
> >>> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> >>> 
> >>> into
> >>> 
> >>> > the project class path but equally wish that the copy/unpack goals
> >>> 
> >>> could
> >>> 
> >>> > simply go away regardless. (in leu of the more normal
> >>> 
> >>> xxx-dependencies
> >>> 
> >>> > versions)
> >>> 
> >>> If you make them go away, please find them a new home. I use them
> >>> constantly to unpack data resources retrieved from a Maven repo. It
> >>> seems odd that they live in a 'dependency' plugin, but it would be a
> >>> disaster if they disappeared.
> >> 
> >> You should be declaring the resources you are unpacking/copying as
> >> dependencies and then using the copy-dependencies or unpack-dependencies
> >> goal instead of the copy or unpack goal.
> > 
> > I don't want them in the classpath. Even if their filenames end in
> > '.jar'.
> 
> The current proposal is to add an artifacts-element[1] to the plugin.
> Dependencies are for the classpath, artifacts are additional files which
> must be resolved, but don't belong on the classpath.
> 
> Robert
> 
> [1]
> https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p
> lugins
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte <rf...@apache.org>]

Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies  
<bi...@gmail.com>:

> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
>>
>>> >
>>> > Fwiw, I don't recall the dependency plugin actually injecting stuff  
>>> into
>>> > the project class path but equally wish that the copy/unpack goals  
>>> could
>>> > simply go away regardless. (in leu of the more normal  
>>> xxx-dependencies
>>> > versions)
>>>
>>> If you make them go away, please find them a new home. I use them
>>> constantly to unpack data resources retrieved from a Maven repo. It
>>> seems odd that they live in a 'dependency' plugin, but it would be a
>>> disaster if they disappeared.
>>>
>>
>> You should be declaring the resources you are unpacking/copying as
>> dependencies and then using the copy-dependencies or unpack-dependencies
>> goal instead of the copy or unpack goal.
>
> I don't want them in the classpath. Even if their filenames end in  
> '.jar'.
>

The current proposal is to add an artifacts-element[1] to the plugin.
Dependencies are for the classpath, artifacts are additional files which  
must be resolved, but don't belong on the classpath.

Robert

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins



>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly <st...@gmail.com>]

The decision was we couldn't add scopes until the modelVersion gets a
bump... Which is on the cards for maven 4.0.

On Saturday, 12 April 2014, Benson Margulies <bi...@gmail.com> wrote:

> On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
> <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> > That's a sign that we need a new scope...
>
> The person who decided that we couldn't just use an arbitrary custom
> value as a scope (thus breaking the tomcat plugin of the time) might
> want to reconsider that decision.
>
>
> >
> >
> > On 11 April 2014 22:50, Benson Margulies <bimargulies@gmail.com<javascript:;>>
> wrote:
> >
> >> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> >> <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >> > On 11 April 2014 22:10, Benson Margulies <bimargulies@gmail.com<javascript:;>>
> wrote:
> >> >
> >> >> >
> >> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> >> into
> >> >> > the project class path but equally wish that the copy/unpack goals
> >> could
> >> >> > simply go away regardless. (in leu of the more normal
> xxx-dependencies
> >> >> > versions)
> >> >>
> >> >> If you make them go away, please find them a new home. I use them
> >> >> constantly to unpack data resources retrieved from a Maven repo. It
> >> >> seems odd that they live in a 'dependency' plugin, but it would be a
> >> >> disaster if they disappeared.
> >> >>
> >> >
> >> > You should be declaring the resources you are unpacking/copying as
> >> > dependencies and then using the copy-dependencies or
> unpack-dependencies
> >> > goal instead of the copy or unpack goal.
> >>
> >> I don't want them in the classpath. Even if their filenames end in
> '.jar'.
> >>
> >> >
> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies <bi...@gmail.com>]

On Fri, Apr 11, 2014 at 5:57 PM, Stephen Connolly
<st...@gmail.com> wrote:
> That's a sign that we need a new scope...

The person who decided that we couldn't just use an arbitrary custom
value as a scope (thus breaking the tomcat plugin of the time) might
want to reconsider that decision.


>
>
> On 11 April 2014 22:50, Benson Margulies <bi...@gmail.com> wrote:
>
>> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>> > On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
>> >
>> >> >
>> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
>> into
>> >> > the project class path but equally wish that the copy/unpack goals
>> could
>> >> > simply go away regardless. (in leu of the more normal xxx-dependencies
>> >> > versions)
>> >>
>> >> If you make them go away, please find them a new home. I use them
>> >> constantly to unpack data resources retrieved from a Maven repo. It
>> >> seems odd that they live in a 'dependency' plugin, but it would be a
>> >> disaster if they disappeared.
>> >>
>> >
>> > You should be declaring the resources you are unpacking/copying as
>> > dependencies and then using the copy-dependencies or unpack-dependencies
>> > goal instead of the copy or unpack goal.
>>
>> I don't want them in the classpath. Even if their filenames end in '.jar'.
>>
>> >
>> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly <st...@gmail.com>]

That's a sign that we need a new scope...


On 11 April 2014 22:50, Benson Margulies <bi...@gmail.com> wrote:

> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> <st...@gmail.com> wrote:
> > On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> into
> >> > the project class path but equally wish that the copy/unpack goals
> could
> >> > simply go away regardless. (in leu of the more normal xxx-dependencies
> >> > versions)
> >>
> >> If you make them go away, please find them a new home. I use them
> >> constantly to unpack data resources retrieved from a Maven repo. It
> >> seems odd that they live in a 'dependency' plugin, but it would be a
> >> disaster if they disappeared.
> >>
> >
> > You should be declaring the resources you are unpacking/copying as
> > dependencies and then using the copy-dependencies or unpack-dependencies
> > goal instead of the copy or unpack goal.
>
> I don't want them in the classpath. Even if their filenames end in '.jar'.
>
> >
> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox <br...@infinity.nu>]

On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies <bi...@gmail.com>wrote:

> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
> <st...@gmail.com> wrote:
> > On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> into
> >> > the project class path but equally wish that the copy/unpack goals
> could
> >> > simply go away regardless. (in leu of the more normal xxx-dependencies
> >> > versions)
> >>
> >> If you make them go away, please find them a new home. I use them
> >> constantly to unpack data resources retrieved from a Maven repo. It
> >> seems odd that they live in a 'dependency' plugin, but it would be a
> >> disaster if they disappeared.
> >>
> >
> > You should be declaring the resources you are unpacking/copying as
> > dependencies and then using the copy-dependencies or unpack-dependencies
> > goal instead of the copy or unpack goal.
>
> I don't want them in the classpath. Even if their filenames end in '.jar'.
>
>
Well, that is the use case I had when I created them originally. I just see
too many people abuse these when they simply could have used the
-dependencies versions just as effectively and with better compatibility to
other plugins.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies <bi...@gmail.com>]

On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
<st...@gmail.com> wrote:
> On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:
>
>> >
>> > Fwiw, I don't recall the dependency plugin actually injecting stuff into
>> > the project class path but equally wish that the copy/unpack goals could
>> > simply go away regardless. (in leu of the more normal xxx-dependencies
>> > versions)
>>
>> If you make them go away, please find them a new home. I use them
>> constantly to unpack data resources retrieved from a Maven repo. It
>> seems odd that they live in a 'dependency' plugin, but it would be a
>> disaster if they disappeared.
>>
>
> You should be declaring the resources you are unpacking/copying as
> dependencies and then using the copy-dependencies or unpack-dependencies
> goal instead of the copy or unpack goal.

I don't want them in the classpath. Even if their filenames end in '.jar'.

>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Stephen Connolly <st...@gmail.com>]

On 11 April 2014 22:10, Benson Margulies <bi...@gmail.com> wrote:

> >
> > Fwiw, I don't recall the dependency plugin actually injecting stuff into
> > the project class path but equally wish that the copy/unpack goals could
> > simply go away regardless. (in leu of the more normal xxx-dependencies
> > versions)
>
> If you make them go away, please find them a new home. I use them
> constantly to unpack data resources retrieved from a Maven repo. It
> seems odd that they live in a 'dependency' plugin, but it would be a
> disaster if they disappeared.
>

You should be declaring the resources you are unpacking/copying as
dependencies and then using the copy-dependencies or unpack-dependencies
goal instead of the copy or unpack goal.


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Benson Margulies <bi...@gmail.com>]

>
> Fwiw, I don't recall the dependency plugin actually injecting stuff into
> the project class path but equally wish that the copy/unpack goals could
> simply go away regardless. (in leu of the more normal xxx-dependencies
> versions)

If you make them go away, please find them a new home. I use them
constantly to unpack data resources retrieved from a Maven repo. It
seems odd that they live in a 'dependency' plugin, but it would be a
disaster if they disappeared.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Robert Scholte <rf...@apache.org>]

Op Fri, 11 Apr 2014 22:57:01 +0200 schreef Brian Fox <br...@infinity.nu>:

>> My proposal is strictly to prohibit a plugin from modifying a project's
>> classpath implicitly. That this become fully explicit such that I can
>> remove some of the convoluted logic in the core to account for this.
>>
>>
> Not allowing plugins to randomly inject new dependencies makes sense. I  
> see
> some cases where you still want to add a new dependency to the plugin  
> class
> path, but from above that sounds unrelated to what you are proposing
> changing?
>
> Fwiw, I don't recall the dependency plugin actually injecting stuff into
> the project class path but equally wish that the copy/unpack goals could
> simply go away regardless. (in leu of the more normal xxx-dependencies
> versions)

The dependency:get is the most tricky goal here, since it's probably a  
pomless execution and you specify the GAV and additional properties. When  
we don't allow the plugin to do this kind of resolution, it's probably  
something which needs to be moved to Maven Core.

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox <br...@infinity.nu>]

> My proposal is strictly to prohibit a plugin from modifying a project's
> classpath implicitly. That this become fully explicit such that I can
> remove some of the convoluted logic in the core to account for this.
>
>
Not allowing plugins to randomly inject new dependencies makes sense. I see
some cases where you still want to add a new dependency to the plugin class
path, but from above that sounds unrelated to what you are proposing
changing?

Fwiw, I don't recall the dependency plugin actually injecting stuff into
the project class path but equally wish that the copy/unpack goals could
simply go away regardless. (in leu of the more normal xxx-dependencies
versions)

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 7, 2014, at 1:35 PM, Jörg Schaible <jo...@gmx.de> wrote:

> Jason van Zyl wrote:
> 
>> 
>> I'm not exactly sure what your question is. Do you mean how would you
>> accomplish these types of tasks without using the resolver directly and do
>> this declaratively?
> 
> No, the plugin should use the resolver and a user should not have to declare 
> such artifacts as dependencies ... just as it is now.

Everything you outline really falls outside the scope of the build proper. If you trying to get artifacts for the IDE, or doing documentation and you want to then I would still limit what exactly you can see of the resolver. I think most things can be declarative, but in the cases where they truly cannot be then to extremely limit the surface area of a resolver such that the internal implementation can change without everyone being affected like they were with the Aether change. 

Right now I care more about the weirdness that crops up as a result of strictly build-time activities. Specifically the magic project classpath fiddling that can occur currently.

> 
> Cheers,
> Jörg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible <jo...@gmx.de>]

Jason van Zyl wrote:

> On Apr 7, 2014, at 3:19 AM, Jörg Schaible <jo...@swisspost.com>
> wrote:
> 
>> Hi Jason,
>> 
>> Jason van Zyl wrote:
>> 
>>> 
>>> 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.
>> 
>> Do you only mean injecting new dependencies into the classpath or
>> injecting new ones into the reactor that will have to be considered for
>> dependency resolution? MNG-4363 talks of the former, your proposal seems
>> to include the latter.
>> 
> 
> My proposal is strictly to prohibit a plugin from modifying a project's
> classpath implicitly. That this become fully explicit such that I can
> remove some of the convoluted logic in the core to account for this.
> 
>> How do you then intent to resolve dynamically dependencies with different
>> classifiers?
>> 
>> The dependency plugin does this explicitly for its sources and javadoc
>> goals (resolving artifacts with corresponding classifier). The site
>> plugin does it implicitly with an artifact having a "site" classifier.
>> And we have developed an own plugin doing the same to aggregate
>> documentation from the dependencies.
>> 
>> It does not make sense for these cases to declare those artifacts with a
>> (different) classifier. What about this scenario?
>> 
> 
> I'm not exactly sure what your question is. Do you mean how would you
> accomplish these types of tasks without using the resolver directly and do
> this declaratively?

No, the plugin should use the resolver and a user should not have to declare 
such artifacts as dependencies ... just as it is now.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jason van Zyl <ja...@takari.io>]

On Apr 7, 2014, at 3:19 AM, Jörg Schaible <jo...@swisspost.com> wrote:

> Hi Jason,
> 
> Jason van Zyl wrote:
> 
>> 
>> 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.
> 
> Do you only mean injecting new dependencies into the classpath or injecting 
> new ones into the reactor that will have to be considered for dependency 
> resolution? MNG-4363 talks of the former, your proposal seems to include the 
> latter.
> 

My proposal is strictly to prohibit a plugin from modifying a project's classpath implicitly. That this become fully explicit such that I can remove some of the convoluted logic in the core to account for this.

> How do you then intent to resolve dynamically dependencies with different 
> classifiers?
> 
> The dependency plugin does this explicitly for its sources and javadoc goals 
> (resolving artifacts with corresponding classifier). The site plugin does it 
> implicitly with an artifact having a "site" classifier. And we have 
> developed an own plugin doing the same to aggregate documentation from the 
> dependencies.
> 
> It does not make sense for these cases to declare those artifacts with a 
> (different) classifier. What about this scenario?
> 

I'm not exactly sure what your question is. Do you mean how would you accomplish these types of tasks without using the resolver directly and do this declaratively?

> - Jörg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible <jo...@swisspost.com>]

Hi Jason,

Jason van Zyl wrote:

> 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.

Do you only mean injecting new dependencies into the classpath or injecting 
new ones into the reactor that will have to be considered for dependency 
resolution? MNG-4363 talks of the former, your proposal seems to include the 
latter.

How do you then intent to resolve dynamically dependencies with different 
classifiers?

The dependency plugin does this explicitly for its sources and javadoc goals 
(resolving artifacts with corresponding classifier). The site plugin does it 
implicitly with an artifact having a "site" classifier. And we have 
developed an own plugin doing the same to aggregate documentation from the 
dependencies.

It does not make sense for these cases to declare those artifacts with a 
(different) classifier. What about this scenario?

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org