svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[sc...@apache.org]

Author: schulte
Date: Sat Dec 24 14:56:53 2016
New Revision: 1775971

URL: http://svn.apache.org/viewvc?rev=1775971&view=rev
Log:
[MPMD-230] Required class missing: org/apache/commons/io/IOUtils


Modified:
    maven/plugins/trunk/maven-pmd-plugin/pom.xml

Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xml?rev=1775971&r1=1775970&r2=1775971&view=diff
==============================================================================
--- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53 2016
@@ -216,13 +216,13 @@ under the License.
       <groupId>org.apache.httpcomponents</groupId>
       <artifactId>httpclient</artifactId>
       <version>4.3.5</version>
-      <scope>test</scope>
+      <!-- scope>test</scope> Required by Doxia transitively. -->
     </dependency>
     <dependency>
       <groupId>commons-io</groupId>
       <artifactId>commons-io</artifactId>
       <version>2.5</version>
-      <scope>test</scope>
+      <!-- scope>test</scope> Required by PMD transitively. -->
     </dependency>
   </dependencies>
 

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

I think we should finetune the definition of "nearest wins"-strategy:  
Which elements are matchers and which are merged? What happens to the  
scope? Is it different for direct and transitive dependencies?

On Sun, 25 Dec 2016 05:21:00 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> Am 12/24/16 um 17:03 schrieb Robert Scholte:
>> With this commit commons-io gets the default scope.
>> Suppose PMD drops commons-io, then there's no reason that this  
>> dependency
>> has the compile scope.
>> Assuming the unittests are using commons-io it makes sense that it has  
>> the
>> test-scope.
>
> Putting that dependency into that POM makes it the nearest declaration
> during resolving dependencies. When using test scope, that will
> disappear from the plugin's runtime (application) classpath and that
> will make the plugin blow up. It's a test dependency of the plugin and
> also a transitive compile dependency of some compile dependency of the
> plugin.
>
>> Be aware that users can overwrite dependencies of plugins in their  
>> pom.xml
>> Developers can only know about the dependencies for their src/main/java
>> and src/test/java code, and cannot do any assumptions about transitive
>> dependencies due to all the override mechanisms in Maven.
>
> If the ITs would have failed right from the start, the person adding
> those test dependencies would have done the right thing back then.
>
>> It may be clear that I don't like these changes.
>
> I haven't expected anything else :-) What has led to that bugfix in the
> resolver was something completely different. I hadn't expected such an
> impact back then. From what I can tell so far, it's really uncovering
> bugs in the POMs. The "one tree per project" logic is what makes this
> look strange. Someone adds a test dependency to a project to express
> that dependency to be needed during testing although that same
> dependency also is needed in the application/main classpath. Looks like
> this will be handled way more intelligent in model version 5.0.0, from
> what I can tell. Right now we have that "nearest wins" strategy in model
> version 4.0.0. If the nearest node happens to be in test scope, that
> nearest node will not be part of the main/application/project/you name
> it classpath. I would want the test classpath used to run all unit tests
> to match what is used at runtime. For this, plugins need to be resolved
> the same way as projects. Taking a closer look at this, Hervé raised
> another very valid point. The resolver still throws away non-transitive
> nodes the next level in the hierarchy during collecting dependencies.
> Following that "there should never be a difference between project or
> dependency resolution" statement of Hervé, the resolver should really
> never cut off any nodes during collecting dependencies and should pass
> all of what is there to the conflict resolver. Implementing that looks
> easy (one line of code to change). I doubt the conflict resolver will
> handle that new "input tree" correctly immediately. Will give it a try
> locally, though.
>
> Regards,

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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/24/16 um 17:03 schrieb Robert Scholte:
> With this commit commons-io gets the default scope.
> Suppose PMD drops commons-io, then there's no reason that this dependency  
> has the compile scope.
> Assuming the unittests are using commons-io it makes sense that it has the  
> test-scope.

Putting that dependency into that POM makes it the nearest declaration
during resolving dependencies. When using test scope, that will
disappear from the plugin's runtime (application) classpath and that
will make the plugin blow up. It's a test dependency of the plugin and
also a transitive compile dependency of some compile dependency of the
plugin.

> Be aware that users can overwrite dependencies of plugins in their pom.xml
> Developers can only know about the dependencies for their src/main/java  
> and src/test/java code, and cannot do any assumptions about transitive  
> dependencies due to all the override mechanisms in Maven.

If the ITs would have failed right from the start, the person adding
those test dependencies would have done the right thing back then.

> It may be clear that I don't like these changes.

I haven't expected anything else :-) What has led to that bugfix in the
resolver was something completely different. I hadn't expected such an
impact back then. From what I can tell so far, it's really uncovering
bugs in the POMs. The "one tree per project" logic is what makes this
look strange. Someone adds a test dependency to a project to express
that dependency to be needed during testing although that same
dependency also is needed in the application/main classpath. Looks like
this will be handled way more intelligent in model version 5.0.0, from
what I can tell. Right now we have that "nearest wins" strategy in model
version 4.0.0. If the nearest node happens to be in test scope, that
nearest node will not be part of the main/application/project/you name
it classpath. I would want the test classpath used to run all unit tests
to match what is used at runtime. For this, plugins need to be resolved
the same way as projects. Taking a closer look at this, Herv raised
another very valid point. The resolver still throws away non-transitive
nodes the next level in the hierarchy during collecting dependencies.
Following that "there should never be a difference between project or
dependency resolution" statement of Herv, the resolver should really
never cut off any nodes during collecting dependencies and should pass
all of what is there to the conflict resolver. Implementing that looks
easy (one line of code to change). I doubt the conflict resolver will
handle that new "input tree" correctly immediately. Will give it a try
locally, though.

Regards,
-- 
Christian


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

good representation of such dependencies question we should work on, since I'm 
sure our current algorithm sometimes give wrong result from human point of 
view

What I don't know yet is if "human point of view" can be a simple algorithm 
improvement, or if there are some cases where there is no single good answer

Regards,

Hervé

Le dimanche 25 décembre 2016, 08:33:28 CET Stephen Connolly a écrit :
> How does a nearer transitive dependency get affected?
> 
> A->B(compile)->C->D
> A->E(test)->D
> 
> Will D now get Test scope or does it still retain compile
> 
> On Sun 25 Dec 2016 at 04:41, Christian Schulte <cs...@schulte.it> wrote:
> > Am 12/24/16 um 17:59 schrieb Hervé BOUTEMY:
> > > +1
> > > 
> > > 
> > > 
> > > notice that it may show that we have an issue with the way transitivity
> > > +
> > > 
> > > nearest resolution are applied
> > > 
> > > 
> > > 
> > > IIUC this case, we have:
> > > 
> > > 1. a direct dependency with scope = test
> > > 
> > > 2. a transitive dependency with scope = compile
> > > 
> > > 
> > > 
> > > the result can't be just the direct dependency with scope=test: scope of
> > > 
> > > direct dependency has to switch to compile (and I don't know which
> > 
> > version
> > 
> > > should be kept: direct or transitive)
> > 
> > Following the nearest node wins strategy, current master does exactly
> > 
> > what is expected. Adding a test scope dependency to a POM that is
> > 
> > already part of the test classpath just means that someone just did not
> > 
> > notice the dependency already is available to that scope due to other
> > 
> > reasons and that a scope is being overridden that way (by pulling it
> > 
> > nearer and overriding the scope).
> > 
> > 
> > 
> > Regards,
> > 
> > --
> > 
> > Christian
> > 
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > 
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > 
> > For additional commands, e-mail: dev-help@maven.apache.org
> > 
> > 
> > 
> > --
> 
> Sent from my phone



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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

To stop my confusion from slipping onto others:

Whenever I talked about project vs. dependency resolution, just forget
about that to be different. That's the result of my confusion during
working on MRESOLVER-8. There is no difference. There should be no
difference. There had been a difference due to MRESOLVER-8. Period.

If you take a look at the example, there is a difference in resolution
of module-3 vs. module-4. I am really talking about that difference.


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 25.12.2016 um 09:33 schrieb Stephen Connolly:
> How does a nearer transitive dependency get affected?
> 
> A->B(compile)->C->D
> A->E(test)->D
> 
> Will D now get Test scope or does it still retain compile

Depends :-)

For project resolution, it will retain compile. For dependency
resolution, it will become test. It is a transitive dependency in both
cases. See the example I attached. Hopefully this gets through to the
list. I verified dependency:tree does not show different results to what
the resolver does and I also verified Maven-3.3.9 and 3.4.0-SNAPSHOT do
show the same results. So nothing special about bugfixes in
3.4.0-SNAPSHOT here. Run mvn clean package dependency:tree on the
project and compare module-3 vs. module-4.

Project resolution (compile scope retained):

[INFO] --- maven-dependency-plugin:3.0.0:tree (default-cli) @ module-3 ---
[INFO] localhost:module-3:jar:1.0-SNAPSHOT
[INFO] +- localhost:module-1:jar:1.0-SNAPSHOT:compile
[INFO] |  \- junit:junit:jar:4.12:compile
[INFO] \- localhost:module-2:jar:1.0-SNAPSHOT:test
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.3:compile

Dependency resolution (compile scope not retained):

[INFO] --- maven-dependency-plugin:3.0.0:tree (default-cli) @ module-4 ---
[INFO] localhost:module-4:jar:1.0-SNAPSHOT
[INFO] +- localhost:module-3:jar:1.0-SNAPSHOT:compile
[INFO] |  \- localhost:module-1:jar:1.0-SNAPSHOT:compile
[INFO] \- junit:junit:jar:4.12:test
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.3:test

If hamcrest-core gets compile scope in module-3, it should retain that
scope in module-4 as well. Correct?

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

How does a nearer transitive dependency get affected?

A->B(compile)->C->D
A->E(test)->D

Will D now get Test scope or does it still retain compile
On Sun 25 Dec 2016 at 04:41, Christian Schulte <cs...@schulte.it> wrote:

> Am 12/24/16 um 17:59 schrieb Hervé BOUTEMY:
>
> > +1
>
> >
>
> > notice that it may show that we have an issue with the way transitivity +
>
> > nearest resolution are applied
>
> >
>
> > IIUC this case, we have:
>
> > 1. a direct dependency with scope = test
>
> > 2. a transitive dependency with scope = compile
>
> >
>
> > the result can't be just the direct dependency with scope=test: scope of
>
> > direct dependency has to switch to compile (and I don't know which
> version
>
> > should be kept: direct or transitive)
>
>
>
> Following the nearest node wins strategy, current master does exactly
>
> what is expected. Adding a test scope dependency to a POM that is
>
> already part of the test classpath just means that someone just did not
>
> notice the dependency already is available to that scope due to other
>
> reasons and that a scope is being overridden that way (by pulling it
>
> nearer and overriding the scope).
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/24/16 um 17:59 schrieb Herv BOUTEMY:
> +1
> 
> notice that it may show that we have an issue with the way transitivity + 
> nearest resolution are applied
> 
> IIUC this case, we have:
> 1. a direct dependency with scope = test
> 2. a transitive dependency with scope = compile
> 
> the result can't be just the direct dependency with scope=test: scope of 
> direct dependency has to switch to compile (and I don't know which version 
> should be kept: direct or transitive)

Following the nearest node wins strategy, current master does exactly
what is expected. Adding a test scope dependency to a POM that is
already part of the test classpath just means that someone just did not
notice the dependency already is available to that scope due to other
reasons and that a scope is being overridden that way (by pulling it
nearer and overriding the scope).

Regards,
-- 
Christian


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

I'm amused how your single question give 3 answers (I'll add mine) that are 
all accurate, but answer to a different interpretation of your question

my own interpretation of your question:
PMD plugin has some reporting goals, that depend on Doxia.
And if report mojos get Doxia dependencies injected by maven-site-plugin when 
run as reports, they can also be run as direct mojos, where maven-site-plugin 
is not there to inject any depency (be it declared or not, or declared but 
ignored)

My answer is as right as others, it's simply another interpretation of your 
question: every interpretation of your question looks reasonable, AFAIK nobody 
answered completely out of scope. Please tell us what more precise question 
was yours, and if you found your answer from the 3 :)

Regards

Hervé

Le samedi 24 décembre 2016, 18:40:22 CET Guillaume Boué a écrit :
> Why would the PMD plugin care about what Doxia require transitively?
> Christian, can you explain a bit more why those changes are needed?
> 
> Le 24/12/2016 à 17:59, Hervé BOUTEMY a écrit :
> > +1
> > 
> > notice that it may show that we have an issue with the way transitivity +
> > nearest resolution are applied
> > 
> > IIUC this case, we have:
> > 1. a direct dependency with scope = test
> > 2. a transitive dependency with scope = compile
> > 
> > the result can't be just the direct dependency with scope=test: scope of
> > direct dependency has to switch to compile (and I don't know which version
> > should be kept: direct or transitive)
> > 
> > I'm sure we have edge cases with transitive dependencies algorithm and
> > scopes
> > 
> > For a long time now, I want to create a builder API to create dependencies
> > unit tests, to ease creating tests, avoiding the nightmare of creating a
> > bunch of pom.xml files in a test local repo that are used by a unit test,
> > with hard to document rationale
> > Seems like it is time to work on it now...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 24 décembre 2016, 17:03:03 CET Robert Scholte a écrit :
> >> With this commit commons-io gets the default scope.
> >> Suppose PMD drops commons-io, then there's no reason that this dependency
> >> has the compile scope.
> >> Assuming the unittests are using commons-io it makes sense that it has
> >> the
> >> test-scope.
> >> Be aware that users can overwrite dependencies of plugins in their
> >> pom.xml
> >> Developers can only know about the dependencies for their src/main/java
> >> and src/test/java code, and cannot do any assumptions about transitive
> >> dependencies due to all the override mechanisms in Maven.
> >> It may be clear that I don't like these changes.
> >> 
> >> Robert
> >> 
> >> On Sat, 24 Dec 2016 15:56:53 +0100, <sc...@apache.org> wrote:
> >>> Author: schulte
> >>> Date: Sat Dec 24 14:56:53 2016
> >>> New Revision: 1775971
> >>> 
> >>> URL: http://svn.apache.org/viewvc?rev=1775971&view=rev
> >>> Log:
> >>> [MPMD-230] Required class missing: org/apache/commons/io/IOUtils
> >>> 
> >>> Modified:
> >>>      maven/plugins/trunk/maven-pmd-plugin/pom.xml
> >>> 
> >>> Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
> >>> URL:
> >>> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xm
> >>> l?
> >>> rev=1775971&r1=1775970&r2=1775971&view=diff
> >>> ========================================================================
> >>> =
> >>> ===== --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
> >>> +++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53
> >>> 2016
> >>> @@ -216,13 +216,13 @@ under the License.
> >>> 
> >>>         <groupId>org.apache.httpcomponents</groupId>
> >>>         <artifactId>httpclient</artifactId>
> >>>         <version>4.3.5</version>
> >>> 
> >>> -      <scope>test</scope>
> >>> +      <!-- scope>test</scope> Required by Doxia transitively. -->
> >>> 
> >>>       </dependency>
> >>>       <dependency>
> >>>       
> >>>         <groupId>commons-io</groupId>
> >>>         <artifactId>commons-io</artifactId>
> >>>         <version>2.5</version>
> >>> 
> >>> -      <scope>test</scope>
> >>> +      <!-- scope>test</scope> Required by PMD transitively. -->
> >>> 
> >>>       </dependency>
> >>>     
> >>>     </dependencies>
> >> 
> >> ---------------------------------------------------------------------
> >> 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
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast. https://www.avast.com/antivirus
> 
> 
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

remember Aether was written to:
1. improve resolution by extracting code, to ease future evolution
2. keep Maven 3 not break what was working with Maven 2
Keeping the right balance between cleaner resolution management and eventually 
"bug for bug" compatibility was not so easy to do: I suppose that the code 
update to introduce a compatibility bug (yes...) was just not documented

We're back to choosing what will go in Maven 3.4.0 (hopefully in near future) 
and what will go in a future version (I don't know when because every new 
bugfix opens a new area of issues)


IMHO, the flag introduced in MNG-6139 should be changed from "legacy-
dependency-management" to opposite "new-dependency-management" to keep 
compatibility by default on next 3.4.0 version (what our vast majority of 
users want), then let time to test the feature and continue bugfixes that are 
required to make the new behaviour really consistent from end to end: once we 
are confident on the new behaviour, we'll activate it by default

WDYT?
is there any breaking fix that is not covered by this flag?

Regards,

Hervé

Le lundi 26 décembre 2016, 11:36:27 CET Robert Scholte a écrit :
> This is becoming a bug versus feature discussion. Up until now you've made
> changes which might change the resolution because you've marked them as a
> bug which must be fixed. However, what is 'the truth': the documentation
> or the code? The answer is: in the end it is the code. And if you want to
> have them in sync, you sometimes need to adjust the documentation instead
> of the code, because the code has a behavior one is used to.
> Since we're talking about changes in resolution, I also expose this topic.
> To me it is not a bug nor a feature, but it is a design flaw. And the
> issue is often not exposed, because the dependencies used for testing are
> not conflicting the compile dependencies. As long as the compilations
> works and all the tests run, users often don't look in detail at the
> dependency.
> The fact right now is that if I add/change a test-scoped dependency, it
> could happen that the project won't run due to a missing transitive
> dependency.
> We are very, very lucky this doesn't happen that often.
> 
> Robert
> 
> On Sun, 25 Dec 2016 19:32:53 +0100, Christian Schulte <cs...@schulte.it>
> 
> wrote:
> > From what I can tell, the resolver now behaves exactly as the API
> > Javadoc states it should. I've also written various test cases for the
> > resolver testing the documented behaviour. From the resolver point of
> > view, MRESOLVER-8 and MRESOLVER-9 and MRESOLVER-10 are really "just"
> > bugfixes. How that manifests in Maven is another story. Looking at all
> > this (again and again and again) is confusing. Mostly because things you
> > are used to know how they behave change in a way no-one is used to. The
> > resolver currently really does what it's supposed to do.
> > 
> > Am 25.12.2016 um 18:01 schrieb Christian Schulte:
> >> Am 12/25/16 um 11:57 schrieb Robert Scholte:
> >>> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <cs...@schulte.it>
> >>> 
> >>> wrote:
> >>>> Am 12/24/16 um 18:40 schrieb Guillaume Boué:
> >>>>> Why would the PMD plugin care about what Doxia require transitively?
> >>>>> Christian, can you explain a bit more why those changes are needed?
> >>>> 
> >>>> Classpath consistency. Running the unit tests with a completely
> >>>> different classpath than what the plugin is using at runtime makes
> >>>> those
> >>>> unit tests meaningless, so to say.
> >>> 
> >>> We're talking about *unittests*, they should test one unit. In those
> >>> cases
> >>> there should be no issue which such dependencies, because if that unit
> >>> requires a certain dependency, it should already have been defined as
> >>> direct dependency.
> >> 
> >> Exactly. In the "widest" scope required. In this case, that's not the
> >> test scope but the compile scope. It's not the test scope overriding the
> >> compile scope here. It's the nearest declaration overriding a transitive
> >> dependency in an incompatible way. What if those two dependencies
> >> (compile and test) would require different major versions of that
> >> dependency? That's the "one tree per project" issue I have been talking
> >> about.
> >> 
> >>> If a test framework requires a newer version of some dependency also
> >>> required at compile time, it is weird to be forced to upgrade this
> >>> dependency just for testing (and what if this dependency is compiled
> >>> with
> >>> a newer version of Java compared to the max of the project).
> >> 
> >> Still means you are not testing the runtime classpath. You know things
> >> are working in test scope. There are different artifacts in the runtime
> >> scope you never have tested. The ITs are different. You would need to
> >> duplicate all unit tests in the ITs. That's not possible most of the
> >> time (you are executing goals in the ITs - you cannot instantiate a
> >> class and perform various tests with that from the ITs).
> >> 
> >>> Maybe it is also caused by the current implementation of test tools.
> >>> JUnit
> >>> is using its own classpath for everything. I've been talking with them
> >>> if
> >>> it would make sense to give the JUnit engine, the test classes and the
> >>> main classes all their own classloader. That would make it possible to
> >>> have better separation.
> >>> 
> >>> I understand the statement of classpath consistency, I used to think
> >>> like
> >>> that in the past too, but for *unit*testing this shouldn't matter.
> >>> That's
> >>> why integration tests are just as important.
> >> 
> >> All I did is make an implementation behave as is documented in it's
> >> Javadoc. Please take a look at this class.
> >> 
> >> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=ma
> >> ven-resolver-api/src/main/java/org/eclipse/aether/collection/CollectReque
> >> st.java;h=d9c252733d0bdcef3c3b6fcb3313a0b21f5b6253;hb=HEAD>
> >> 
> >> Read the Javadoc of all constructors. Concentrate on direct vs.
> >> transitive here. Read the Javadoc of the getDependencies and
> >> addDependency methods as well. Again, concentrate on direct vs.
> >> transitive here as well.
> >> 
> >> Now read the Javadoc of this class.
> >> 
> >> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=ma
> >> ven-resolver-util/src/main/java/org/eclipse/aether/util/graph/selector/Sc
> >> opeDependencySelector.java;h=92db1417e8affadd976e2c51a38b33500161ce45;hb=
> >> HEAD>
> >> 
> >> /**
> >> 
> >>  * A dependency selector that filters transitive dependencies based on
> >> 
> >> their scope. Direct dependencies are always
> >> 
> >>  * included regardless of their scope. <em>Note:</em> This filter does
> >> 
> >> not assume any relationships between the scopes.
> >> 
> >>  * In particular, the filter is not aware of scopes that logically
> >> 
> >> include other scopes.
> >> 
> >>  *
> >>  * @see Dependency#getScope()
> >>  */
> >> 
> >> public final class ScopeDependencySelector
> >> 
> >>     implements DependencySelector
> >> 
> >> The class calling into this is the DefaultDependencyCollector.
> >> 
> >> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=ma
> >> ven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultD
> >> ependencyCollector.java;h=aaf5865f3fe74060e60be35f1d2bd9b13c69d206;hb=HEA
> >> D>
> >> 
> >> Do you notice there is an inconsistency in that 'CollectRequest' class
> >> depending on the way it gets constructed? The 'getDependencies' method
> >> clearly states:
> >> 
> >> @return The direct dependencies, never {@code null}.
> >> 
> >> Now compare if that statement is correct (direct vs. transitive)
> >> depending on how that class has been constructed and tell me why only
> >> the ScopeDependencySelector above has had logic deciding if those
> >> dependencies are transitive or direct when all other
> >> selector,traverser,manager implementations did not.
> >> 
> >> There is this resolver only a few people seem to have taken a closer
> >> look at. I am not telling anyone how things should behave and what has
> >> to change etc. There is an API Maven is calling into no-one has ever
> >> verified is doing what it is stating in it's Javadoc. Now compare the
> >> Javadoc of those constructors of that CollectRequest class above to the
> >> Javadoc of the getDependencies and addDependency methods of that same
> >> class. Only one class (ScopeDependencySelector) handled things
> >> differently (direct vs. transitive). There are plenty of other classes
> >> not handling anything differently. Either that ScopeDependencySelector
> >> got it right and all other classes need to be updated or it's the other
> >> way around. I tried both. That has led to MNG-6135. What we now have on
> >> master (resolver and core) is consistent to what the Javadoc of those
> >> getDependencies and addDependency methods state. And still Hervé made a
> >> very valid point during this. Why is there such a difference at all?
> >> 
> >> Regards,
> > 
> > ---------------------------------------------------------------------
> > 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Le mercredi 28 décembre 2016, 14:33:58 CET Robert Scholte a écrit :
> On Wed, 28 Dec 2016 11:47:40 +0100, Hervé BOUTEMY <he...@free.fr>
> 
> wrote:
> > Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
> >> >> The fact right now is that if I add/change a test-scoped dependency,
> >> 
> >> it
> >> 
> >> >> could happen that the project won't run due to a missing transitive
> >> >> dependency.
> >> >> We are very, very lucky this doesn't happen that often.
> >> > 
> >> > This is what would stop if we would just fix those bugs. We are
> >> 
> >> running
> >> 
> >> > into those bugs ourselves. Take a look at the PMD plugin POM again.
> >> 
> >> What
> >> 
> >> > would you have done, if the test dependencies I moved to compile scope
> >> > would be required for compilation of that project?
> >> 
> >> With the current behavior I wouldn't include these dependencies at all,
> >> since they're already available as compile-scoped transitive dependency.
> >> When due to an upgrade of a dependency commons-io is not used anymore,
> >> tests will fail to compile. And that's the moment to add this
> >> dependency.
> >> IMO changing dependencies should never cause compilation failures caused
> >> by transitive dependencies, but right now there's simply no better
> >> solution. We say that it is a best practice to always define the direct
> >> dependencies, but in this case we can't do that because we cannot give
> >> these dependencies the test-scope.
> > 
> > notice that this seems to have been reported years ago:
> > https://issues.apache.org/jira/browse/MNG-5739
> > 
> > and IMHO, if this case was fixed (which seems reasonable), MNG-6135
> > would not
> > break so many plugins (which do not have really broken config: having to
> > avoid
> > a test scope dependency just because it will override a transitive
> > compile
> > dependency is just the trial and error configuration people will have to
> > do)
> 
> You fully hit the nail. Before MNG-6135 the resolution was working as
> expected, even though it may seem as a very simplified dependency
> resolution: only look at direct compile+runtime -scoped dependencies and
> their transitive deps. In fact, I like this concept in general: pick all
> direct dependencies matching one or more scopes and all their transitive
> dependencies.
> To me there are 2 solutions: either implement MNG-5739 or revert MNG-6135.
> Any of both solutions will make plugins again run as expected.
+1

> 
> Robert
> 
> > Regards,
> > 
> > Hervé
> > 
> > ---------------------------------------------------------------------
> > 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/28/16 um 14:33 schrieb Robert Scholte:
> ...revert MNG-6135.

Well. If I would be a jerk, I would come up and say: But this is how
Maven 2 behaved and Maven 3 must behave the same way or I will vote -1
on the release. MNG-6135 has been requested by Igor Fedorenko. Ask him
about it.


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/28/16 um 14:33 schrieb Robert Scholte:
> ...implement MNG-5739.

Exactly. In model version 5.0.0. Until then, project and plugin and
extension resolution should behave the same. It makes no sense to have
different resolution strategies no-one knows about. MNG-5739 is not
about plugin runtime classpath construction!



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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

On Wed, 28 Dec 2016 11:47:40 +0100, Hervé BOUTEMY <he...@free.fr>  
wrote:

> Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
>> >> The fact right now is that if I add/change a test-scoped dependency,  
>> it
>> >> could happen that the project won't run due to a missing transitive
>> >> dependency.
>> >> We are very, very lucky this doesn't happen that often.
>> >
>> > This is what would stop if we would just fix those bugs. We are  
>> running
>> > into those bugs ourselves. Take a look at the PMD plugin POM again.  
>> What
>> > would you have done, if the test dependencies I moved to compile scope
>> > would be required for compilation of that project?
>>
>> With the current behavior I wouldn't include these dependencies at all,
>> since they're already available as compile-scoped transitive dependency.
>> When due to an upgrade of a dependency commons-io is not used anymore,
>> tests will fail to compile. And that's the moment to add this  
>> dependency.
>> IMO changing dependencies should never cause compilation failures caused
>> by transitive dependencies, but right now there's simply no better
>> solution. We say that it is a best practice to always define the direct
>> dependencies, but in this case we can't do that because we cannot give
>> these dependencies the test-scope.
> notice that this seems to have been reported years ago:
> https://issues.apache.org/jira/browse/MNG-5739
>
> and IMHO, if this case was fixed (which seems reasonable), MNG-6135  
> would not
> break so many plugins (which do not have really broken config: having to  
> avoid
> a test scope dependency just because it will override a transitive  
> compile
> dependency is just the trial and error configuration people will have to  
> do)
>

You fully hit the nail. Before MNG-6135 the resolution was working as  
expected, even though it may seem as a very simplified dependency  
resolution: only look at direct compile+runtime -scoped dependencies and  
their transitive deps. In fact, I like this concept in general: pick all  
direct dependencies matching one or more scopes and all their transitive  
dependencies.
To me there are 2 solutions: either implement MNG-5739 or revert MNG-6135.  
Any of both solutions will make plugins again run as expected.

Robert


> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
> >> The fact right now is that if I add/change a test-scoped dependency, it
> >> could happen that the project won't run due to a missing transitive
> >> dependency.
> >> We are very, very lucky this doesn't happen that often.
> > 
> > This is what would stop if we would just fix those bugs. We are running
> > into those bugs ourselves. Take a look at the PMD plugin POM again. What
> > would you have done, if the test dependencies I moved to compile scope
> > would be required for compilation of that project?
> 
> With the current behavior I wouldn't include these dependencies at all,
> since they're already available as compile-scoped transitive dependency.
> When due to an upgrade of a dependency commons-io is not used anymore,
> tests will fail to compile. And that's the moment to add this dependency.
> IMO changing dependencies should never cause compilation failures caused
> by transitive dependencies, but right now there's simply no better
> solution. We say that it is a best practice to always define the direct
> dependencies, but in this case we can't do that because we cannot give
> these dependencies the test-scope.
notice that this seems to have been reported years ago:
https://issues.apache.org/jira/browse/MNG-5739

and IMHO, if this case was fixed (which seems reasonable), MNG-6135 would not 
break so many plugins (which do not have really broken config: having to avoid 
a test scope dependency just because it will override a transitive compile 
dependency is just the trial and error configuration people will have to do)

Regards,

Hervé

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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

I will have to analyze that. [1]

When working on Jigsaw I had to make clear what's the difference between  
the two of them:
- both are required on the classpath during compilation, but at runtime  
the provided should already be there ( e.g. servlet-api), optional can be  
there (springboot dependency)

there it is translated like this:
module M {
   requires javax.servlet-api; //it is required both at compile time and at  
runtime, even though it is the container which provides this module
   requires static some.springboot.dep; //required during compiletime,  
unused or discoverable during runtime
}

and about those compile-time annotations like Plugin Annotations: those  
are actually compile-time only.

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0

On Tue, 27 Dec 2016 20:07:06 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> Am 12/27/16 um 14:48 schrieb Robert Scholte:
>> IMO scopes weren't designed to make transitive dependencies disappear.
>
> Does it mean you would agree that there should be no "provided" scope?
> Instead "compile+optional" or "runtime+optional" or "test+optional"
> should be used, where "optional" is just another name for "transitive"?
> So in model version 5.0.0 we really should rename "optional" to
> "transitive"? Would you also agree that the "test" scope should be
> transitive by default in model version 5.0.0? So in model version 5.0.0
> all scopes are transitive by default and a dependency can be flagged
> non-transitive by setting the "transitive" attribute to "false" which
> defaults to "true" and there are no optional dependencies any more.
> Maybe the dependency element needs a way to carry freetext comments on
> them as well so that things can be documented (I flagged this not
> transitive, because..., I pulled this in to upgrade transitive
> dependency XYZ of ABC..., etc.).
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/27/16 um 14:48 schrieb Robert Scholte:
> IMO scopes weren't designed to make transitive dependencies disappear.

Does it mean you would agree that there should be no "provided" scope?
Instead "compile+optional" or "runtime+optional" or "test+optional"
should be used, where "optional" is just another name for "transitive"?
So in model version 5.0.0 we really should rename "optional" to
"transitive"? Would you also agree that the "test" scope should be
transitive by default in model version 5.0.0? So in model version 5.0.0
all scopes are transitive by default and a dependency can be flagged
non-transitive by setting the "transitive" attribute to "false" which
defaults to "true" and there are no optional dependencies any more.
Maybe the dependency element needs a way to carry freetext comments on
them as well so that things can be documented (I flagged this not
transitive, because..., I pulled this in to upgrade transitive
dependency XYZ of ABC..., etc.).


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

On Mon, 26 Dec 2016 17:07:14 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> Am 12/26/16 um 11:36 schrieb Robert Scholte:
>> This is becoming a bug versus feature discussion.
>
> It shouldn't.
>
>> Up until now you've made
>> changes which might change the resolution because you've marked them as  
>> a
>> bug which must be fixed. However, what is 'the truth': the documentation
>> or the code? The answer is: in the end it is the code. And if you want  
>> to
>> have them in sync, you sometimes need to adjust the documentation  
>> instead
>> of the code, because the code has a behavior one is used to.
>
> Have you read the Javadoc and the code? If you would have done that, you
> would notice that everything behaves consistently and as documented
> *but* one class which is fixed now. If it would be *all* classes, there
> would be no question the code is behaving the way it should.
>
> MRESOLVER-8
>
> This *only* affects plugin and extension resolution by stopping to
> discard any test and provided *direct* dependencies of a plugin the same
> way optional *direct* dependencies are not discarded and the same way
> the dependency manager is not managing *direct* dependencies. It does
> not affect project resolution in any way. That's what we are really
> lucky about. If we don't want Maven to behave that way (with plugin and
> extension resolution fixed) it's the Maven codebase to adjust - not the
> resolver. That's just an API used by Maven and should just be consistent
> and correct. The original author really could have left a few unit tests
> in that area. We would not discuss anything, if he would have done that.
> He would have noticed things himself or would have left a comment at
> least. The issue above together with
>
> MRESOLVER-9
> MRESOLVER-10
>
> is really "just" bugfixes. What we learn from that is that we should
> "commit" any resolution result during deployment so that bugs like these
> can be fixed without influencing the resolution performed for a deployed
> project. That's the PDT file we are going to deploy in Maven X.
>
>> Since we're talking about changes in resolution, I also expose this  
>> topic.
>> To me it is not a bug nor a feature, but it is a design flaw. And the
>> issue is often not exposed, because the dependencies used for testing  
>> are
>> not conflicting the compile dependencies. As long as the compilations
>> works and all the tests run, users often don't look in detail at the
>> dependency.
>> The fact right now is that if I add/change a test-scoped dependency, it
>> could happen that the project won't run due to a missing transitive
>> dependency.
>> We are very, very lucky this doesn't happen that often.
>
> This is what would stop if we would just fix those bugs. We are running
> into those bugs ourselves. Take a look at the PMD plugin POM again. What
> would you have done, if the test dependencies I moved to compile scope
> would be required for compilation of that project?

With the current behavior I wouldn't include these dependencies at all,  
since they're already available as compile-scoped transitive dependency.  
When due to an upgrade of a dependency commons-io is not used anymore,  
tests will fail to compile. And that's the moment to add this dependency.
IMO changing dependencies should never cause compilation failures caused  
by transitive dependencies, but right now there's simply no better  
solution. We say that it is a best practice to always define the direct  
dependencies, but in this case we can't do that because we cannot give  
these dependencies the test-scope.

> This is already
> yelling for an enforcer rule or something like that. "Are all classes
> used by the classes on the compilation classpath available during
> compilation?" Currently it's a result of trial and error. Really. If we
> let this go on, we need to be even more lucky in a few years. If we say
> plugins and extensions just are not resolved the same way as projects
> (how it has been for a long time), this will make the following IT start
> to fail, when done consistently.
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0>
>
> So we would need to adjust the Maven codebase to keep it behaving as
> before. The resolver is not the correct codebase for this. I could do
> that easily although it's inconcistent with itself that way. If you take
> a look at what updates needed to be performed to various plugin POMs,
> those are really all bugs in the POMs. Either we fix them, or we make
> plugin resolution differ from project resolution (non-transitive
> *direct* dependencies only override main scope dependencies during
> building but are ignored when building the runtime classpath). Just say
> so and it'll be done. My personal opinion is that having a different
> runtime classpath than what was used during building is a bad idea and
> we are running into issues due to this ourselves which proves this  
> correct.

I agree that compile and runtime classpath should be the same (apart from  
provided/runtime scoped deps of course). Just like test-compile and test  
(which is actually the runtime with the test-classpath).
Between these sets there can be differences for good reasons.
IMO scopes weren't designed to make transitive dependencies disappear.
And the way I'm describing it, the result will be that both compile and  
runtime classpath can have extra artifacts, so with that in mind I don't  
see the issue.

Robert

>
> Regards,

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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Jeff Jensen <jj...@apache.org>]

> This is not something that the user should be able to control directly

Makes sense, since this only affects plugins, to not expect or enable user
control of this feature.
Thank you for explaining.

(I also do not prefer a CLI switch for this due to the "reproducible
builds" issue, and prefer a source controlled setting, which a pom change
is a solution; I also agree we don't want that requirement nor is it needed
to allow users to change it.)


On Mon, Dec 26, 2016 at 2:07 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Well a command line switch is useless imho.
>
> Suppose I have a multi-module reactor and one module uses version A of
> plugin X and another module uses version B.
>
> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
> tweaks and hacks to ensure the transitive dependencies worked out correctly
> (yes they should have filed a bug rather than work around, but life)
>
> B was built against Maven 3.4.0 and all the hacks were removed.
>
> How can we build that reactor with a command line switch? We cannot. The
> CLI switch would force with A or B to be wrong.
>
> We need something that works the way users expect *without* requiring that
> they change their poms
>
> (If we have no solution available other than "you have to change your poms"
> then we need to do that, but first priority is not to force users to change
> their poms)
>
> So prerequisites comes into play because it defines the minimum version of
> Maven that the plugin works with.
>
> I am presuming that Maven 2.x did not have this issue. I suspect, perhaps
> Maven 3.0.x did not have it either... it would be good to get some history
> if the behaviour. (If it turns out that maven 2.x behaves the same as 3.3.9
> in this regard then really the bug is the Java docs)
>
> If you are a plugin developer, and you mark your plugin as compatible with
> Maven 2.2.1+ (which is what 'prerequisites' does... you do know that field
> is *only* applicable to plugins!) we have to assume you tested on Maven
> 2.2.1, and you should thus have git a 2.2.1 classpath. If that is not the
> same as a 3.3.9 classpath... boom that is a bug in 3.3.9 and it is
> perfectly legitimate for 3.4.0 to provide the plugin with the classpath it
> would get with Maven 2.2.1 (which may even be different from 3.4.0)
>
> This is not something that the user should be able to control directly
> IMHO. Adding knobs to tweak the behaviour just complicates things for
> users.
>
> We should look at the prerequisites of the plugin and give it the correct
> classpath for that Maven version (and eg this could include adding in Maven
> compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
> plexus utils etc)
>
> If the user finds bugs they can either upgrade/roll back the plugin or
> upgrade/roll back Maven and we update our mapping layer for the 3.4.1
> release and move forward.
>
> Adding 1000 command line options is not the right answer.
>
> It seems we got lucky here with it only affecting plugins... so we can use
> our luck as a get out of jail free card and use the plugins advertised
> minimum Maven version requirement to control the resolution strategy for
> each plugin.
> On Mon 26 Dec 2016 at 18:54, Jeff Jensen <jj...@apache.org> wrote:
>
> > I find the prerequisites idea very intriguing.  However, does that mean
> >
> > it's automatic behavior and no way for user to control it?
> >
> > (For user to control it, in addition to normal docs, I expect release
> notes
> >
> > describing the issue (e.g. links to JIRA) and how to enable/disable the
> new
> >
> > breaking feature or breaking fix (e.g. POM element or property)).
> >
> >
> >
> >
> >
> > BTW Christian, I admire your work and tenacity on this fix.  While I
> >
> > understand the "main line development" pattern and what you intended, I
> >
> > also think it should have been on a branch with some commits squashed
> (and
> >
> > full tests run before pushing).
> >
> >
> >
> >
> >
> > On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly <
> >
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >
> >
> > > Rather than a CLI switch can we use the plugin prerequisites to control
> > the
> >
> > > behaviour?
> >
> > >
> >
> > > If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise
> > replicate
> >
> > > the bug.
> >
> > >
> >
> > > That way if the plugin was built and tested against 2.x (which
> presumably
> >
> > > doesn't have the bug) or against 3.4+ you get the. Ore than behaviour.
> >
> > > Plugins that were developed and tested against 3.0-3.3 should get the
> >
> > > behaviour they were tested against
> >
> > >
> >
> > > Wdyt
> >
> > > On Mon 26 Dec 2016 at 16:07, Christian Schulte <cs...@schulte.it> wrote:
> >
> > >
> >
> > > > Am 12/26/16 um 11:36 schrieb Robert Scholte:
> >
> > > >
> >
> > > > > This is becoming a bug versus feature discussion.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > It shouldn't.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > > Up until now you've made
> >
> > > >
> >
> > > > > changes which might change the resolution because you've marked
> them
> >
> > > as a
> >
> > > >
> >
> > > > > bug which must be fixed. However, what is 'the truth': the
> >
> > > documentation
> >
> > > >
> >
> > > > > or the code? The answer is: in the end it is the code. And if you
> > want
> >
> > > to
> >
> > > >
> >
> > > > > have them in sync, you sometimes need to adjust the documentation
> >
> > > instead
> >
> > > >
> >
> > > > > of the code, because the code has a behavior one is used to.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Have you read the Javadoc and the code? If you would have done that,
> > you
> >
> > > >
> >
> > > > would notice that everything behaves consistently and as documented
> >
> > > >
> >
> > > > *but* one class which is fixed now. If it would be *all* classes,
> there
> >
> > > >
> >
> > > > would be no question the code is behaving the way it should.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > MRESOLVER-8
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > This *only* affects plugin and extension resolution by stopping to
> >
> > > >
> >
> > > > discard any test and provided *direct* dependencies of a plugin the
> > same
> >
> > > >
> >
> > > > way optional *direct* dependencies are not discarded and the same way
> >
> > > >
> >
> > > > the dependency manager is not managing *direct* dependencies. It does
> >
> > > >
> >
> > > > not affect project resolution in any way. That's what we are really
> >
> > > >
> >
> > > > lucky about. If we don't want Maven to behave that way (with plugin
> and
> >
> > > >
> >
> > > > extension resolution fixed) it's the Maven codebase to adjust - not
> the
> >
> > > >
> >
> > > > resolver. That's just an API used by Maven and should just be
> > consistent
> >
> > > >
> >
> > > > and correct. The original author really could have left a few unit
> > tests
> >
> > > >
> >
> > > > in that area. We would not discuss anything, if he would have done
> > that.
> >
> > > >
> >
> > > > He would have noticed things himself or would have left a comment at
> >
> > > >
> >
> > > > least. The issue above together with
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > MRESOLVER-9
> >
> > > >
> >
> > > > MRESOLVER-10
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > is really "just" bugfixes. What we learn from that is that we should
> >
> > > >
> >
> > > > "commit" any resolution result during deployment so that bugs like
> > these
> >
> > > >
> >
> > > > can be fixed without influencing the resolution performed for a
> > deployed
> >
> > > >
> >
> > > > project. That's the PDT file we are going to deploy in Maven X.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > > Since we're talking about changes in resolution, I also expose this
> >
> > > > topic.
> >
> > > >
> >
> > > > > To me it is not a bug nor a feature, but it is a design flaw. And
> the
> >
> > > >
> >
> > > > > issue is often not exposed, because the dependencies used for
> testing
> >
> > > are
> >
> > > >
> >
> > > > > not conflicting the compile dependencies. As long as the
> compilations
> >
> > > >
> >
> > > > > works and all the tests run, users often don't look in detail at
> the
> >
> > > >
> >
> > > > > dependency.
> >
> > > >
> >
> > > > > The fact right now is that if I add/change a test-scoped
> dependency,
> > it
> >
> > > >
> >
> > > > > could happen that the project won't run due to a missing transitive
> >
> > > >
> >
> > > > > dependency.
> >
> > > >
> >
> > > > > We are very, very lucky this doesn't happen that often.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > This is what would stop if we would just fix those bugs. We are
> running
> >
> > > >
> >
> > > > into those bugs ourselves. Take a look at the PMD plugin POM again.
> > What
> >
> > > >
> >
> > > > would you have done, if the test dependencies I moved to compile
> scope
> >
> > > >
> >
> > > > would be required for compilation of that project? This is already
> >
> > > >
> >
> > > > yelling for an enforcer rule or something like that. "Are all classes
> >
> > > >
> >
> > > > used by the classes on the compilation classpath available during
> >
> > > >
> >
> > > > compilation?" Currently it's a result of trial and error. Really. If
> we
> >
> > > >
> >
> > > > let this go on, we need to be even more lucky in a few years. If we
> say
> >
> > > >
> >
> > > > plugins and extensions just are not resolved the same way as projects
> >
> > > >
> >
> > > > (how it has been for a long time), this will make the following IT
> > start
> >
> > > >
> >
> > > > to fail, when done consistently.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > <
> >
> > > > https://git-wip-us.apache.org/repos/asf?p=maven-integration-
> >
> > > testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0
> >
> > > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > So we would need to adjust the Maven codebase to keep it behaving as
> >
> > > >
> >
> > > > before. The resolver is not the correct codebase for this. I could do
> >
> > > >
> >
> > > > that easily although it's inconcistent with itself that way. If you
> > take
> >
> > > >
> >
> > > > a look at what updates needed to be performed to various plugin POMs,
> >
> > > >
> >
> > > > those are really all bugs in the POMs. Either we fix them, or we make
> >
> > > >
> >
> > > > plugin resolution differ from project resolution (non-transitive
> >
> > > >
> >
> > > > *direct* dependencies only override main scope dependencies during
> >
> > > >
> >
> > > > building but are ignored when building the runtime classpath). Just
> say
> >
> > > >
> >
> > > > so and it'll be done. My personal opinion is that having a different
> >
> > > >
> >
> > > > runtime classpath than what was used during building is a bad idea
> and
> >
> > > >
> >
> > > > we are running into issues due to this ourselves which proves this
> >
> > > correct.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Regards,
> >
> > > >
> >
> > > > --
> >
> > > >
> >
> > > > Christian
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > ------------------------------------------------------------
> ---------
> >
> > > >
> >
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > > >
> >
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > Sent from my phone
> >
> > >
> >
> > --
> Sent from my phone
>

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/28/16 um 11:44 schrieb Robert Scholte:
> So can we remove the commandline option?

IMHO, yes. It's just one commit to revert on Maven master. I would still
like to wait a bit on my last comment on MNG-6139.

<https://issues.apache.org/jira/browse/MNG-6082>
<https://issues.apache.org/jira/browse/MNG-6139>

Mark?


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

So can we remove the commandline option?

And anything we cannot agree on push to Model 5.0.0? This way model 4.0.0  
works as it did (apart from the real bugfixes) and we can finally start  
making milestones for M3.4.0
For 5.0.0 we need to reach out to other third parties anyway, so let's  
take that opportunity to do it correct.

Robert

On Mon, 26 Dec 2016 22:42:39 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> Am 12/26/16 um 21:07 schrieb Stephen Connolly:
>> Well a command line switch is useless imho.
>
> +1
>
>>
>> Suppose I have a multi-module reactor and one module uses version A of
>> plugin X and another module uses version B.
>>
>> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
>> tweaks and hacks to ensure the transitive dependencies worked out  
>> correctly
>> (yes they should have filed a bug rather than work around, but life)
>>
>> B was built against Maven 3.4.0 and all the hacks were removed.
>>
>> How can we build that reactor with a command line switch? We cannot. The
>> CLI switch would force with A or B to be wrong.
>
> +1
>
> Same for dependencies.
>
>>
>> We need something that works the way users expect *without* requiring  
>> that
>> they change their poms
>
> That'd be the best we can do.
>
>> This is not something that the user should be able to control directly
>> IMHO. Adding knobs to tweak the behaviour just complicates things for  
>> users.
>
> +1
>
> When deployed, no one knows what knobs had been in effect during
> deployment. Bad idea. Information must be retained in the POMs.
> Prerequisites to the rescue.
>
>> We should look at the prerequisites of the plugin and give it the  
>> correct
>> classpath for that Maven version (and eg this could include adding in  
>> Maven
>> compat for anything pre-3.4.0, aether shims, sonatype shims, etc,  
>> mapping
>> plexus utils etc)
>
> +1
>
> I just ran various tests against maven-pmd-plugin version 2.3. That
> version can still be used with Maven 2.0 and that version is the first
> version introducing an issue where a test artifact overrides a compile
> artifact.
>
> With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to
> what 3.4.0-SNAPSHOT currently does (test scope dependencies not
> available at runtime). This is from the Maven 2.2.1 debug messages:
>
>  org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to:
> compile; local scope test wins*)
> org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*)
>
> MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This
> is something I would not have expected myself.
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/27/16 um 00:57 schrieb Christian Schulte:
> Am 12/26/16 um 23:04 schrieb Stephen Connolly:
>> Well that certainly puts a different light on things
>>
>> With this being a regression introduced in 3.x it should be significantly
>> less contentious to fix.
>>
>> What would be good is to find when exactly the regression was introduced:
>> 3.0.x or 3.1.x
> 
> The bug is there since aether-1.0. What is a bit strange is that in
> aether-1.0 the selectors were not inconsistent but were implemented for
> what I've called dependency resolution. Just compare the
> 'deriveChildSelector' methods of these two classes in aether-1.0.
> 
> <https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/OptionalDependencySelector.java>
> 
> <https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/ScopeDependencySelector.java>

Damn it. It's inconsistent there as well. So even aether-1.0 had this issue.


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/26/16 um 23:04 schrieb Stephen Connolly:
> Well that certainly puts a different light on things
> 
> With this being a regression introduced in 3.x it should be significantly
> less contentious to fix.
> 
> What would be good is to find when exactly the regression was introduced:
> 3.0.x or 3.1.x

The bug is there since aether-1.0. What is a bit strange is that in
aether-1.0 the selectors were not inconsistent but were implemented for
what I've called dependency resolution. Just compare the
'deriveChildSelector' methods of these two classes in aether-1.0.

<https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/OptionalDependencySelector.java>

<https://github.com/sonatype/sonatype-aether/blob/aether-1.0/util/src/main/java/org/sonatype/aether/util/graph/selector/ScopeDependencySelector.java>

One of the inconsistencies between the selector implementations got
introduced in this commit and released with aether-1.1.

<https://github.com/sonatype/sonatype-aether/commit/066bd42e19b57ed6b062dda96b930bacc22e8b34#diff-fc29adb2eeb81ae0520094c0cfdcfc5d>

Compare the 'deriveChildSelector' methods of the same classes again
after that commit.

<https://github.com/sonatype/sonatype-aether/blob/aether-1.1/aether-util/src/main/java/org/sonatype/aether/util/graph/selector/OptionalDependencySelector.java>

<https://github.com/sonatype/sonatype-aether/blob/aether-1.1/aether-util/src/main/java/org/sonatype/aether/util/graph/selector/ScopeDependencySelector.java>

Maven 3.0-beta-3 is the first release bundled with aether-1.2. I
verified the betas and alphas before that also resolved the plugins the
way 3.0-beta-3 does it. So it's there since day one of Maven 3.

> 
> On Mon 26 Dec 2016 at 21:42, Christian Schulte <cs...@schulte.it> wrote:
> 
>> Am 12/26/16 um 21:07 schrieb Stephen Connolly:
>>
>>> Well a command line switch is useless imho.
>>
>>
>>
>> +1
>>
>>
>>
>>>
>>
>>> Suppose I have a multi-module reactor and one module uses version A of
>>
>>> plugin X and another module uses version B.
>>
>>>
>>
>>> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
>>
>>> tweaks and hacks to ensure the transitive dependencies worked out
>> correctly
>>
>>> (yes they should have filed a bug rather than work around, but life)
>>
>>>
>>
>>> B was built against Maven 3.4.0 and all the hacks were removed.
>>
>>>
>>
>>> How can we build that reactor with a command line switch? We cannot. The
>>
>>> CLI switch would force with A or B to be wrong.
>>
>>
>>
>> +1
>>
>>
>>
>> Same for dependencies.
>>
>>
>>
>>>
>>
>>> We need something that works the way users expect *without* requiring
>> that
>>
>>> they change their poms
>>
>>
>>
>> That'd be the best we can do.
>>
>>
>>
>>> This is not something that the user should be able to control directly
>>
>>> IMHO. Adding knobs to tweak the behaviour just complicates things for
>> users.
>>
>>
>>
>> +1
>>
>>
>>
>> When deployed, no one knows what knobs had been in effect during
>>
>> deployment. Bad idea. Information must be retained in the POMs.
>>
>> Prerequisites to the rescue.
>>
>>
>>
>>> We should look at the prerequisites of the plugin and give it the correct
>>
>>> classpath for that Maven version (and eg this could include adding in
>> Maven
>>
>>> compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
>>
>>> plexus utils etc)
>>
>>
>>
>> +1
>>
>>
>>
>> I just ran various tests against maven-pmd-plugin version 2.3. That
>>
>> version can still be used with Maven 2.0 and that version is the first
>>
>> version introducing an issue where a test artifact overrides a compile
>>
>> artifact.
>>
>>
>>
>> With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to
>>
>> what 3.4.0-SNAPSHOT currently does (test scope dependencies not
>>
>> available at runtime). This is from the Maven 2.2.1 debug messages:
>>
>>
>>
>>  org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to:
>>
>> compile; local scope test wins*)
>>
>> org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*)
>>
>>
>>
>> MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This
>>
>> is something I would not have expected myself.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>> --
> Sent from my phone
> 


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Well that certainly puts a different light on things

With this being a regression introduced in 3.x it should be significantly
less contentious to fix.

What would be good is to find when exactly the regression was introduced:
3.0.x or 3.1.x

On Mon 26 Dec 2016 at 21:42, Christian Schulte <cs...@schulte.it> wrote:

> Am 12/26/16 um 21:07 schrieb Stephen Connolly:
>
> > Well a command line switch is useless imho.
>
>
>
> +1
>
>
>
> >
>
> > Suppose I have a multi-module reactor and one module uses version A of
>
> > plugin X and another module uses version B.
>
> >
>
> > Now A was built against Maven 3.3.3 and the classpath was "fixed" with
>
> > tweaks and hacks to ensure the transitive dependencies worked out
> correctly
>
> > (yes they should have filed a bug rather than work around, but life)
>
> >
>
> > B was built against Maven 3.4.0 and all the hacks were removed.
>
> >
>
> > How can we build that reactor with a command line switch? We cannot. The
>
> > CLI switch would force with A or B to be wrong.
>
>
>
> +1
>
>
>
> Same for dependencies.
>
>
>
> >
>
> > We need something that works the way users expect *without* requiring
> that
>
> > they change their poms
>
>
>
> That'd be the best we can do.
>
>
>
> > This is not something that the user should be able to control directly
>
> > IMHO. Adding knobs to tweak the behaviour just complicates things for
> users.
>
>
>
> +1
>
>
>
> When deployed, no one knows what knobs had been in effect during
>
> deployment. Bad idea. Information must be retained in the POMs.
>
> Prerequisites to the rescue.
>
>
>
> > We should look at the prerequisites of the plugin and give it the correct
>
> > classpath for that Maven version (and eg this could include adding in
> Maven
>
> > compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
>
> > plexus utils etc)
>
>
>
> +1
>
>
>
> I just ran various tests against maven-pmd-plugin version 2.3. That
>
> version can still be used with Maven 2.0 and that version is the first
>
> version introducing an issue where a test artifact overrides a compile
>
> artifact.
>
>
>
> With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to
>
> what 3.4.0-SNAPSHOT currently does (test scope dependencies not
>
> available at runtime). This is from the Maven 2.2.1 debug messages:
>
>
>
>  org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to:
>
> compile; local scope test wins*)
>
> org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*)
>
>
>
> MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This
>
> is something I would not have expected myself.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/26/16 um 21:07 schrieb Stephen Connolly:
> Well a command line switch is useless imho.

+1

> 
> Suppose I have a multi-module reactor and one module uses version A of
> plugin X and another module uses version B.
> 
> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
> tweaks and hacks to ensure the transitive dependencies worked out correctly
> (yes they should have filed a bug rather than work around, but life)
> 
> B was built against Maven 3.4.0 and all the hacks were removed.
> 
> How can we build that reactor with a command line switch? We cannot. The
> CLI switch would force with A or B to be wrong.

+1

Same for dependencies.

> 
> We need something that works the way users expect *without* requiring that
> they change their poms

That'd be the best we can do.

> This is not something that the user should be able to control directly
> IMHO. Adding knobs to tweak the behaviour just complicates things for users.

+1

When deployed, no one knows what knobs had been in effect during
deployment. Bad idea. Information must be retained in the POMs.
Prerequisites to the rescue.

> We should look at the prerequisites of the plugin and give it the correct
> classpath for that Maven version (and eg this could include adding in Maven
> compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
> plexus utils etc)

+1

I just ran various tests against maven-pmd-plugin version 2.3. That
version can still be used with Maven 2.0 and that version is the first
version introducing an issue where a test artifact overrides a compile
artifact.

With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to
what 3.4.0-SNAPSHOT currently does (test scope dependencies not
available at runtime). This is from the Maven 2.2.1 debug messages:

 org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to:
compile; local scope test wins*)
org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*)

MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This
is something I would not have expected myself.


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Well a command line switch is useless imho.

Suppose I have a multi-module reactor and one module uses version A of
plugin X and another module uses version B.

Now A was built against Maven 3.3.3 and the classpath was "fixed" with
tweaks and hacks to ensure the transitive dependencies worked out correctly
(yes they should have filed a bug rather than work around, but life)

B was built against Maven 3.4.0 and all the hacks were removed.

How can we build that reactor with a command line switch? We cannot. The
CLI switch would force with A or B to be wrong.

We need something that works the way users expect *without* requiring that
they change their poms

(If we have no solution available other than "you have to change your poms"
then we need to do that, but first priority is not to force users to change
their poms)

So prerequisites comes into play because it defines the minimum version of
Maven that the plugin works with.

I am presuming that Maven 2.x did not have this issue. I suspect, perhaps
Maven 3.0.x did not have it either... it would be good to get some history
if the behaviour. (If it turns out that maven 2.x behaves the same as 3.3.9
in this regard then really the bug is the Java docs)

If you are a plugin developer, and you mark your plugin as compatible with
Maven 2.2.1+ (which is what 'prerequisites' does... you do know that field
is *only* applicable to plugins!) we have to assume you tested on Maven
2.2.1, and you should thus have git a 2.2.1 classpath. If that is not the
same as a 3.3.9 classpath... boom that is a bug in 3.3.9 and it is
perfectly legitimate for 3.4.0 to provide the plugin with the classpath it
would get with Maven 2.2.1 (which may even be different from 3.4.0)

This is not something that the user should be able to control directly
IMHO. Adding knobs to tweak the behaviour just complicates things for users.

We should look at the prerequisites of the plugin and give it the correct
classpath for that Maven version (and eg this could include adding in Maven
compat for anything pre-3.4.0, aether shims, sonatype shims, etc, mapping
plexus utils etc)

If the user finds bugs they can either upgrade/roll back the plugin or
upgrade/roll back Maven and we update our mapping layer for the 3.4.1
release and move forward.

Adding 1000 command line options is not the right answer.

It seems we got lucky here with it only affecting plugins... so we can use
our luck as a get out of jail free card and use the plugins advertised
minimum Maven version requirement to control the resolution strategy for
each plugin.
On Mon 26 Dec 2016 at 18:54, Jeff Jensen <jj...@apache.org> wrote:

> I find the prerequisites idea very intriguing.  However, does that mean
>
> it's automatic behavior and no way for user to control it?
>
> (For user to control it, in addition to normal docs, I expect release notes
>
> describing the issue (e.g. links to JIRA) and how to enable/disable the new
>
> breaking feature or breaking fix (e.g. POM element or property)).
>
>
>
>
>
> BTW Christian, I admire your work and tenacity on this fix.  While I
>
> understand the "main line development" pattern and what you intended, I
>
> also think it should have been on a branch with some commits squashed (and
>
> full tests run before pushing).
>
>
>
>
>
> On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly <
>
> stephen.alan.connolly@gmail.com> wrote:
>
>
>
> > Rather than a CLI switch can we use the plugin prerequisites to control
> the
>
> > behaviour?
>
> >
>
> > If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise
> replicate
>
> > the bug.
>
> >
>
> > That way if the plugin was built and tested against 2.x (which presumably
>
> > doesn't have the bug) or against 3.4+ you get the. Ore than behaviour.
>
> > Plugins that were developed and tested against 3.0-3.3 should get the
>
> > behaviour they were tested against
>
> >
>
> > Wdyt
>
> > On Mon 26 Dec 2016 at 16:07, Christian Schulte <cs...@schulte.it> wrote:
>
> >
>
> > > Am 12/26/16 um 11:36 schrieb Robert Scholte:
>
> > >
>
> > > > This is becoming a bug versus feature discussion.
>
> > >
>
> > >
>
> > >
>
> > > It shouldn't.
>
> > >
>
> > >
>
> > >
>
> > > > Up until now you've made
>
> > >
>
> > > > changes which might change the resolution because you've marked them
>
> > as a
>
> > >
>
> > > > bug which must be fixed. However, what is 'the truth': the
>
> > documentation
>
> > >
>
> > > > or the code? The answer is: in the end it is the code. And if you
> want
>
> > to
>
> > >
>
> > > > have them in sync, you sometimes need to adjust the documentation
>
> > instead
>
> > >
>
> > > > of the code, because the code has a behavior one is used to.
>
> > >
>
> > >
>
> > >
>
> > > Have you read the Javadoc and the code? If you would have done that,
> you
>
> > >
>
> > > would notice that everything behaves consistently and as documented
>
> > >
>
> > > *but* one class which is fixed now. If it would be *all* classes, there
>
> > >
>
> > > would be no question the code is behaving the way it should.
>
> > >
>
> > >
>
> > >
>
> > > MRESOLVER-8
>
> > >
>
> > >
>
> > >
>
> > > This *only* affects plugin and extension resolution by stopping to
>
> > >
>
> > > discard any test and provided *direct* dependencies of a plugin the
> same
>
> > >
>
> > > way optional *direct* dependencies are not discarded and the same way
>
> > >
>
> > > the dependency manager is not managing *direct* dependencies. It does
>
> > >
>
> > > not affect project resolution in any way. That's what we are really
>
> > >
>
> > > lucky about. If we don't want Maven to behave that way (with plugin and
>
> > >
>
> > > extension resolution fixed) it's the Maven codebase to adjust - not the
>
> > >
>
> > > resolver. That's just an API used by Maven and should just be
> consistent
>
> > >
>
> > > and correct. The original author really could have left a few unit
> tests
>
> > >
>
> > > in that area. We would not discuss anything, if he would have done
> that.
>
> > >
>
> > > He would have noticed things himself or would have left a comment at
>
> > >
>
> > > least. The issue above together with
>
> > >
>
> > >
>
> > >
>
> > > MRESOLVER-9
>
> > >
>
> > > MRESOLVER-10
>
> > >
>
> > >
>
> > >
>
> > > is really "just" bugfixes. What we learn from that is that we should
>
> > >
>
> > > "commit" any resolution result during deployment so that bugs like
> these
>
> > >
>
> > > can be fixed without influencing the resolution performed for a
> deployed
>
> > >
>
> > > project. That's the PDT file we are going to deploy in Maven X.
>
> > >
>
> > >
>
> > >
>
> > > > Since we're talking about changes in resolution, I also expose this
>
> > > topic.
>
> > >
>
> > > > To me it is not a bug nor a feature, but it is a design flaw. And the
>
> > >
>
> > > > issue is often not exposed, because the dependencies used for testing
>
> > are
>
> > >
>
> > > > not conflicting the compile dependencies. As long as the compilations
>
> > >
>
> > > > works and all the tests run, users often don't look in detail at the
>
> > >
>
> > > > dependency.
>
> > >
>
> > > > The fact right now is that if I add/change a test-scoped dependency,
> it
>
> > >
>
> > > > could happen that the project won't run due to a missing transitive
>
> > >
>
> > > > dependency.
>
> > >
>
> > > > We are very, very lucky this doesn't happen that often.
>
> > >
>
> > >
>
> > >
>
> > > This is what would stop if we would just fix those bugs. We are running
>
> > >
>
> > > into those bugs ourselves. Take a look at the PMD plugin POM again.
> What
>
> > >
>
> > > would you have done, if the test dependencies I moved to compile scope
>
> > >
>
> > > would be required for compilation of that project? This is already
>
> > >
>
> > > yelling for an enforcer rule or something like that. "Are all classes
>
> > >
>
> > > used by the classes on the compilation classpath available during
>
> > >
>
> > > compilation?" Currently it's a result of trial and error. Really. If we
>
> > >
>
> > > let this go on, we need to be even more lucky in a few years. If we say
>
> > >
>
> > > plugins and extensions just are not resolved the same way as projects
>
> > >
>
> > > (how it has been for a long time), this will make the following IT
> start
>
> > >
>
> > > to fail, when done consistently.
>
> > >
>
> > >
>
> > >
>
> > > <
>
> > > https://git-wip-us.apache.org/repos/asf?p=maven-integration-
>
> > testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0
>
> > > >
>
> > >
>
> > >
>
> > >
>
> > > So we would need to adjust the Maven codebase to keep it behaving as
>
> > >
>
> > > before. The resolver is not the correct codebase for this. I could do
>
> > >
>
> > > that easily although it's inconcistent with itself that way. If you
> take
>
> > >
>
> > > a look at what updates needed to be performed to various plugin POMs,
>
> > >
>
> > > those are really all bugs in the POMs. Either we fix them, or we make
>
> > >
>
> > > plugin resolution differ from project resolution (non-transitive
>
> > >
>
> > > *direct* dependencies only override main scope dependencies during
>
> > >
>
> > > building but are ignored when building the runtime classpath). Just say
>
> > >
>
> > > so and it'll be done. My personal opinion is that having a different
>
> > >
>
> > > runtime classpath than what was used during building is a bad idea and
>
> > >
>
> > > we are running into issues due to this ourselves which proves this
>
> > correct.
>
> > >
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > --
>
> > >
>
> > > Christian
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > >
>
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> > >
>
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > Sent from my phone
>
> >
>
> --
Sent from my phone

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Jeff Jensen <jj...@apache.org>]

I find the prerequisites idea very intriguing.  However, does that mean
it's automatic behavior and no way for user to control it?
(For user to control it, in addition to normal docs, I expect release notes
describing the issue (e.g. links to JIRA) and how to enable/disable the new
breaking feature or breaking fix (e.g. POM element or property)).


BTW Christian, I admire your work and tenacity on this fix.  While I
understand the "main line development" pattern and what you intended, I
also think it should have been on a branch with some commits squashed (and
full tests run before pushing).


On Mon, Dec 26, 2016 at 12:29 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Rather than a CLI switch can we use the plugin prerequisites to control the
> behaviour?
>
> If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise replicate
> the bug.
>
> That way if the plugin was built and tested against 2.x (which presumably
> doesn't have the bug) or against 3.4+ you get the. Ore than behaviour.
> Plugins that were developed and tested against 3.0-3.3 should get the
> behaviour they were tested against
>
> Wdyt
> On Mon 26 Dec 2016 at 16:07, Christian Schulte <cs...@schulte.it> wrote:
>
> > Am 12/26/16 um 11:36 schrieb Robert Scholte:
> >
> > > This is becoming a bug versus feature discussion.
> >
> >
> >
> > It shouldn't.
> >
> >
> >
> > > Up until now you've made
> >
> > > changes which might change the resolution because you've marked them
> as a
> >
> > > bug which must be fixed. However, what is 'the truth': the
> documentation
> >
> > > or the code? The answer is: in the end it is the code. And if you want
> to
> >
> > > have them in sync, you sometimes need to adjust the documentation
> instead
> >
> > > of the code, because the code has a behavior one is used to.
> >
> >
> >
> > Have you read the Javadoc and the code? If you would have done that, you
> >
> > would notice that everything behaves consistently and as documented
> >
> > *but* one class which is fixed now. If it would be *all* classes, there
> >
> > would be no question the code is behaving the way it should.
> >
> >
> >
> > MRESOLVER-8
> >
> >
> >
> > This *only* affects plugin and extension resolution by stopping to
> >
> > discard any test and provided *direct* dependencies of a plugin the same
> >
> > way optional *direct* dependencies are not discarded and the same way
> >
> > the dependency manager is not managing *direct* dependencies. It does
> >
> > not affect project resolution in any way. That's what we are really
> >
> > lucky about. If we don't want Maven to behave that way (with plugin and
> >
> > extension resolution fixed) it's the Maven codebase to adjust - not the
> >
> > resolver. That's just an API used by Maven and should just be consistent
> >
> > and correct. The original author really could have left a few unit tests
> >
> > in that area. We would not discuss anything, if he would have done that.
> >
> > He would have noticed things himself or would have left a comment at
> >
> > least. The issue above together with
> >
> >
> >
> > MRESOLVER-9
> >
> > MRESOLVER-10
> >
> >
> >
> > is really "just" bugfixes. What we learn from that is that we should
> >
> > "commit" any resolution result during deployment so that bugs like these
> >
> > can be fixed without influencing the resolution performed for a deployed
> >
> > project. That's the PDT file we are going to deploy in Maven X.
> >
> >
> >
> > > Since we're talking about changes in resolution, I also expose this
> > topic.
> >
> > > To me it is not a bug nor a feature, but it is a design flaw. And the
> >
> > > issue is often not exposed, because the dependencies used for testing
> are
> >
> > > not conflicting the compile dependencies. As long as the compilations
> >
> > > works and all the tests run, users often don't look in detail at the
> >
> > > dependency.
> >
> > > The fact right now is that if I add/change a test-scoped dependency, it
> >
> > > could happen that the project won't run due to a missing transitive
> >
> > > dependency.
> >
> > > We are very, very lucky this doesn't happen that often.
> >
> >
> >
> > This is what would stop if we would just fix those bugs. We are running
> >
> > into those bugs ourselves. Take a look at the PMD plugin POM again. What
> >
> > would you have done, if the test dependencies I moved to compile scope
> >
> > would be required for compilation of that project? This is already
> >
> > yelling for an enforcer rule or something like that. "Are all classes
> >
> > used by the classes on the compilation classpath available during
> >
> > compilation?" Currently it's a result of trial and error. Really. If we
> >
> > let this go on, we need to be even more lucky in a few years. If we say
> >
> > plugins and extensions just are not resolved the same way as projects
> >
> > (how it has been for a long time), this will make the following IT start
> >
> > to fail, when done consistently.
> >
> >
> >
> > <
> > https://git-wip-us.apache.org/repos/asf?p=maven-integration-
> testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0
> > >
> >
> >
> >
> > So we would need to adjust the Maven codebase to keep it behaving as
> >
> > before. The resolver is not the correct codebase for this. I could do
> >
> > that easily although it's inconcistent with itself that way. If you take
> >
> > a look at what updates needed to be performed to various plugin POMs,
> >
> > those are really all bugs in the POMs. Either we fix them, or we make
> >
> > plugin resolution differ from project resolution (non-transitive
> >
> > *direct* dependencies only override main scope dependencies during
> >
> > building but are ignored when building the runtime classpath). Just say
> >
> > so and it'll be done. My personal opinion is that having a different
> >
> > runtime classpath than what was used during building is a bad idea and
> >
> > we are running into issues due to this ourselves which proves this
> correct.
> >
> >
> >
> > Regards,
> >
> > --
> >
> > Christian
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > --
> Sent from my phone
>

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Rather than a CLI switch can we use the plugin prerequisites to control the
behaviour?

If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise replicate
the bug.

That way if the plugin was built and tested against 2.x (which presumably
doesn't have the bug) or against 3.4+ you get the. Ore than behaviour.
Plugins that were developed and tested against 3.0-3.3 should get the
behaviour they were tested against

Wdyt
On Mon 26 Dec 2016 at 16:07, Christian Schulte <cs...@schulte.it> wrote:

> Am 12/26/16 um 11:36 schrieb Robert Scholte:
>
> > This is becoming a bug versus feature discussion.
>
>
>
> It shouldn't.
>
>
>
> > Up until now you've made
>
> > changes which might change the resolution because you've marked them as a
>
> > bug which must be fixed. However, what is 'the truth': the documentation
>
> > or the code? The answer is: in the end it is the code. And if you want to
>
> > have them in sync, you sometimes need to adjust the documentation instead
>
> > of the code, because the code has a behavior one is used to.
>
>
>
> Have you read the Javadoc and the code? If you would have done that, you
>
> would notice that everything behaves consistently and as documented
>
> *but* one class which is fixed now. If it would be *all* classes, there
>
> would be no question the code is behaving the way it should.
>
>
>
> MRESOLVER-8
>
>
>
> This *only* affects plugin and extension resolution by stopping to
>
> discard any test and provided *direct* dependencies of a plugin the same
>
> way optional *direct* dependencies are not discarded and the same way
>
> the dependency manager is not managing *direct* dependencies. It does
>
> not affect project resolution in any way. That's what we are really
>
> lucky about. If we don't want Maven to behave that way (with plugin and
>
> extension resolution fixed) it's the Maven codebase to adjust - not the
>
> resolver. That's just an API used by Maven and should just be consistent
>
> and correct. The original author really could have left a few unit tests
>
> in that area. We would not discuss anything, if he would have done that.
>
> He would have noticed things himself or would have left a comment at
>
> least. The issue above together with
>
>
>
> MRESOLVER-9
>
> MRESOLVER-10
>
>
>
> is really "just" bugfixes. What we learn from that is that we should
>
> "commit" any resolution result during deployment so that bugs like these
>
> can be fixed without influencing the resolution performed for a deployed
>
> project. That's the PDT file we are going to deploy in Maven X.
>
>
>
> > Since we're talking about changes in resolution, I also expose this
> topic.
>
> > To me it is not a bug nor a feature, but it is a design flaw. And the
>
> > issue is often not exposed, because the dependencies used for testing are
>
> > not conflicting the compile dependencies. As long as the compilations
>
> > works and all the tests run, users often don't look in detail at the
>
> > dependency.
>
> > The fact right now is that if I add/change a test-scoped dependency, it
>
> > could happen that the project won't run due to a missing transitive
>
> > dependency.
>
> > We are very, very lucky this doesn't happen that often.
>
>
>
> This is what would stop if we would just fix those bugs. We are running
>
> into those bugs ourselves. Take a look at the PMD plugin POM again. What
>
> would you have done, if the test dependencies I moved to compile scope
>
> would be required for compilation of that project? This is already
>
> yelling for an enforcer rule or something like that. "Are all classes
>
> used by the classes on the compilation classpath available during
>
> compilation?" Currently it's a result of trial and error. Really. If we
>
> let this go on, we need to be even more lucky in a few years. If we say
>
> plugins and extensions just are not resolved the same way as projects
>
> (how it has been for a long time), this will make the following IT start
>
> to fail, when done consistently.
>
>
>
> <
> https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0
> >
>
>
>
> So we would need to adjust the Maven codebase to keep it behaving as
>
> before. The resolver is not the correct codebase for this. I could do
>
> that easily although it's inconcistent with itself that way. If you take
>
> a look at what updates needed to be performed to various plugin POMs,
>
> those are really all bugs in the POMs. Either we fix them, or we make
>
> plugin resolution differ from project resolution (non-transitive
>
> *direct* dependencies only override main scope dependencies during
>
> building but are ignored when building the runtime classpath). Just say
>
> so and it'll be done. My personal opinion is that having a different
>
> runtime classpath than what was used during building is a bad idea and
>
> we are running into issues due to this ourselves which proves this correct.
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
Sent from my phone

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/26/16 um 11:36 schrieb Robert Scholte:
> This is becoming a bug versus feature discussion.

It shouldn't.

> Up until now you've made  
> changes which might change the resolution because you've marked them as a  
> bug which must be fixed. However, what is 'the truth': the documentation  
> or the code? The answer is: in the end it is the code. And if you want to  
> have them in sync, you sometimes need to adjust the documentation instead  
> of the code, because the code has a behavior one is used to.

Have you read the Javadoc and the code? If you would have done that, you
would notice that everything behaves consistently and as documented
*but* one class which is fixed now. If it would be *all* classes, there
would be no question the code is behaving the way it should.

MRESOLVER-8

This *only* affects plugin and extension resolution by stopping to
discard any test and provided *direct* dependencies of a plugin the same
way optional *direct* dependencies are not discarded and the same way
the dependency manager is not managing *direct* dependencies. It does
not affect project resolution in any way. That's what we are really
lucky about. If we don't want Maven to behave that way (with plugin and
extension resolution fixed) it's the Maven codebase to adjust - not the
resolver. That's just an API used by Maven and should just be consistent
and correct. The original author really could have left a few unit tests
in that area. We would not discuss anything, if he would have done that.
He would have noticed things himself or would have left a comment at
least. The issue above together with

MRESOLVER-9
MRESOLVER-10

is really "just" bugfixes. What we learn from that is that we should
"commit" any resolution result during deployment so that bugs like these
can be fixed without influencing the resolution performed for a deployed
project. That's the PDT file we are going to deploy in Maven X.

> Since we're talking about changes in resolution, I also expose this topic.  
> To me it is not a bug nor a feature, but it is a design flaw. And the  
> issue is often not exposed, because the dependencies used for testing are  
> not conflicting the compile dependencies. As long as the compilations  
> works and all the tests run, users often don't look in detail at the  
> dependency.
> The fact right now is that if I add/change a test-scoped dependency, it  
> could happen that the project won't run due to a missing transitive  
> dependency.
> We are very, very lucky this doesn't happen that often.

This is what would stop if we would just fix those bugs. We are running
into those bugs ourselves. Take a look at the PMD plugin POM again. What
would you have done, if the test dependencies I moved to compile scope
would be required for compilation of that project? This is already
yelling for an enforcer rule or something like that. "Are all classes
used by the classes on the compilation classpath available during
compilation?" Currently it's a result of trial and error. Really. If we
let this go on, we need to be even more lucky in a few years. If we say
plugins and extensions just are not resolved the same way as projects
(how it has been for a long time), this will make the following IT start
to fail, when done consistently.

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0>

So we would need to adjust the Maven codebase to keep it behaving as
before. The resolver is not the correct codebase for this. I could do
that easily although it's inconcistent with itself that way. If you take
a look at what updates needed to be performed to various plugin POMs,
those are really all bugs in the POMs. Either we fix them, or we make
plugin resolution differ from project resolution (non-transitive
*direct* dependencies only override main scope dependencies during
building but are ignored when building the runtime classpath). Just say
so and it'll be done. My personal opinion is that having a different
runtime classpath than what was used during building is a bad idea and
we are running into issues due to this ourselves which proves this correct.

Regards,
-- 
Christian


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

This is becoming a bug versus feature discussion. Up until now you've made  
changes which might change the resolution because you've marked them as a  
bug which must be fixed. However, what is 'the truth': the documentation  
or the code? The answer is: in the end it is the code. And if you want to  
have them in sync, you sometimes need to adjust the documentation instead  
of the code, because the code has a behavior one is used to.
Since we're talking about changes in resolution, I also expose this topic.  
To me it is not a bug nor a feature, but it is a design flaw. And the  
issue is often not exposed, because the dependencies used for testing are  
not conflicting the compile dependencies. As long as the compilations  
works and all the tests run, users often don't look in detail at the  
dependency.
The fact right now is that if I add/change a test-scoped dependency, it  
could happen that the project won't run due to a missing transitive  
dependency.
We are very, very lucky this doesn't happen that often.

Robert

On Sun, 25 Dec 2016 19:32:53 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> From what I can tell, the resolver now behaves exactly as the API
> Javadoc states it should. I've also written various test cases for the
> resolver testing the documented behaviour. From the resolver point of
> view, MRESOLVER-8 and MRESOLVER-9 and MRESOLVER-10 are really "just"
> bugfixes. How that manifests in Maven is another story. Looking at all
> this (again and again and again) is confusing. Mostly because things you
> are used to know how they behave change in a way no-one is used to. The
> resolver currently really does what it's supposed to do.
>
> Am 25.12.2016 um 18:01 schrieb Christian Schulte:
>> Am 12/25/16 um 11:57 schrieb Robert Scholte:
>>> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <cs...@schulte.it>
>>> wrote:
>>>
>>>> Am 12/24/16 um 18:40 schrieb Guillaume Boué:
>>>>> Why would the PMD plugin care about what Doxia require transitively?
>>>>> Christian, can you explain a bit more why those changes are needed?
>>>>
>>>> Classpath consistency. Running the unit tests with a completely
>>>> different classpath than what the plugin is using at runtime makes  
>>>> those
>>>> unit tests meaningless, so to say.
>>>>
>>>
>>> We're talking about *unittests*, they should test one unit. In those  
>>> cases
>>> there should be no issue which such dependencies, because if that unit
>>> requires a certain dependency, it should already have been defined as
>>> direct dependency.
>>
>> Exactly. In the "widest" scope required. In this case, that's not the
>> test scope but the compile scope. It's not the test scope overriding the
>> compile scope here. It's the nearest declaration overriding a transitive
>> dependency in an incompatible way. What if those two dependencies
>> (compile and test) would require different major versions of that
>> dependency? That's the "one tree per project" issue I have been talking
>> about.
>>
>>> If a test framework requires a newer version of some dependency also
>>> required at compile time, it is weird to be forced to upgrade this
>>> dependency just for testing (and what if this dependency is compiled  
>>> with
>>> a newer version of Java compared to the max of the project).
>>
>> Still means you are not testing the runtime classpath. You know things
>> are working in test scope. There are different artifacts in the runtime
>> scope you never have tested. The ITs are different. You would need to
>> duplicate all unit tests in the ITs. That's not possible most of the
>> time (you are executing goals in the ITs - you cannot instantiate a
>> class and perform various tests with that from the ITs).
>>
>>> Maybe it is also caused by the current implementation of test tools.  
>>> JUnit
>>> is using its own classpath for everything. I've been talking with them  
>>> if
>>> it would make sense to give the JUnit engine, the test classes and the
>>> main classes all their own classloader. That would make it possible to
>>> have better separation.
>>>
>>> I understand the statement of classpath consistency, I used to think  
>>> like
>>> that in the past too, but for *unit*testing this shouldn't matter.  
>>> That's
>>> why integration tests are just as important.
>>
>> All I did is make an implementation behave as is documented in it's
>> Javadoc. Please take a look at this class.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-api/src/main/java/org/eclipse/aether/collection/CollectRequest.java;h=d9c252733d0bdcef3c3b6fcb3313a0b21f5b6253;hb=HEAD>
>>
>> Read the Javadoc of all constructors. Concentrate on direct vs.
>> transitive here. Read the Javadoc of the getDependencies and
>> addDependency methods as well. Again, concentrate on direct vs.
>> transitive here as well.
>>
>> Now read the Javadoc of this class.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/selector/ScopeDependencySelector.java;h=92db1417e8affadd976e2c51a38b33500161ce45;hb=HEAD>
>>
>> /**
>>  * A dependency selector that filters transitive dependencies based on
>> their scope. Direct dependencies are always
>>  * included regardless of their scope. <em>Note:</em> This filter does
>> not assume any relationships between the scopes.
>>  * In particular, the filter is not aware of scopes that logically
>> include other scopes.
>>  *
>>  * @see Dependency#getScope()
>>  */
>> public final class ScopeDependencySelector
>>     implements DependencySelector
>>
>> The class calling into this is the DefaultDependencyCollector.
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java;h=aaf5865f3fe74060e60be35f1d2bd9b13c69d206;hb=HEAD>
>>
>> Do you notice there is an inconsistency in that 'CollectRequest' class
>> depending on the way it gets constructed? The 'getDependencies' method
>> clearly states:
>>
>> @return The direct dependencies, never {@code null}.
>>
>> Now compare if that statement is correct (direct vs. transitive)
>> depending on how that class has been constructed and tell me why only
>> the ScopeDependencySelector above has had logic deciding if those
>> dependencies are transitive or direct when all other
>> selector,traverser,manager implementations did not.
>>
>> There is this resolver only a few people seem to have taken a closer
>> look at. I am not telling anyone how things should behave and what has
>> to change etc. There is an API Maven is calling into no-one has ever
>> verified is doing what it is stating in it's Javadoc. Now compare the
>> Javadoc of those constructors of that CollectRequest class above to the
>> Javadoc of the getDependencies and addDependency methods of that same
>> class. Only one class (ScopeDependencySelector) handled things
>> differently (direct vs. transitive). There are plenty of other classes
>> not handling anything differently. Either that ScopeDependencySelector
>> got it right and all other classes need to be updated or it's the other
>> way around. I tried both. That has led to MNG-6135. What we now have on
>> master (resolver and core) is consistent to what the Javadoc of those
>> getDependencies and addDependency methods state. And still Hervé made a
>> very valid point during this. Why is there such a difference at all?
>>
>> Regards,
>>
>
>
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

From what I can tell, the resolver now behaves exactly as the API
Javadoc states it should. I've also written various test cases for the
resolver testing the documented behaviour. From the resolver point of
view, MRESOLVER-8 and MRESOLVER-9 and MRESOLVER-10 are really "just"
bugfixes. How that manifests in Maven is another story. Looking at all
this (again and again and again) is confusing. Mostly because things you
are used to know how they behave change in a way no-one is used to. The
resolver currently really does what it's supposed to do.

Am 25.12.2016 um 18:01 schrieb Christian Schulte:
> Am 12/25/16 um 11:57 schrieb Robert Scholte:
>> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <cs...@schulte.it>  
>> wrote:
>>
>>> Am 12/24/16 um 18:40 schrieb Guillaume Bou:
>>>> Why would the PMD plugin care about what Doxia require transitively?
>>>> Christian, can you explain a bit more why those changes are needed?
>>>
>>> Classpath consistency. Running the unit tests with a completely
>>> different classpath than what the plugin is using at runtime makes those
>>> unit tests meaningless, so to say.
>>>
>>
>> We're talking about *unittests*, they should test one unit. In those cases  
>> there should be no issue which such dependencies, because if that unit  
>> requires a certain dependency, it should already have been defined as  
>> direct dependency.
> 
> Exactly. In the "widest" scope required. In this case, that's not the
> test scope but the compile scope. It's not the test scope overriding the
> compile scope here. It's the nearest declaration overriding a transitive
> dependency in an incompatible way. What if those two dependencies
> (compile and test) would require different major versions of that
> dependency? That's the "one tree per project" issue I have been talking
> about.
> 
>> If a test framework requires a newer version of some dependency also  
>> required at compile time, it is weird to be forced to upgrade this  
>> dependency just for testing (and what if this dependency is compiled with  
>> a newer version of Java compared to the max of the project).
> 
> Still means you are not testing the runtime classpath. You know things
> are working in test scope. There are different artifacts in the runtime
> scope you never have tested. The ITs are different. You would need to
> duplicate all unit tests in the ITs. That's not possible most of the
> time (you are executing goals in the ITs - you cannot instantiate a
> class and perform various tests with that from the ITs).
> 
>> Maybe it is also caused by the current implementation of test tools. JUnit  
>> is using its own classpath for everything. I've been talking with them if  
>> it would make sense to give the JUnit engine, the test classes and the  
>> main classes all their own classloader. That would make it possible to  
>> have better separation.
>>
>> I understand the statement of classpath consistency, I used to think like  
>> that in the past too, but for *unit*testing this shouldn't matter. That's  
>> why integration tests are just as important.
> 
> All I did is make an implementation behave as is documented in it's
> Javadoc. Please take a look at this class.
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-api/src/main/java/org/eclipse/aether/collection/CollectRequest.java;h=d9c252733d0bdcef3c3b6fcb3313a0b21f5b6253;hb=HEAD>
> 
> Read the Javadoc of all constructors. Concentrate on direct vs.
> transitive here. Read the Javadoc of the getDependencies and
> addDependency methods as well. Again, concentrate on direct vs.
> transitive here as well.
> 
> Now read the Javadoc of this class.
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/selector/ScopeDependencySelector.java;h=92db1417e8affadd976e2c51a38b33500161ce45;hb=HEAD>
> 
> /**
>  * A dependency selector that filters transitive dependencies based on
> their scope. Direct dependencies are always
>  * included regardless of their scope. <em>Note:</em> This filter does
> not assume any relationships between the scopes.
>  * In particular, the filter is not aware of scopes that logically
> include other scopes.
>  *
>  * @see Dependency#getScope()
>  */
> public final class ScopeDependencySelector
>     implements DependencySelector
> 
> The class calling into this is the DefaultDependencyCollector.
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java;h=aaf5865f3fe74060e60be35f1d2bd9b13c69d206;hb=HEAD>
> 
> Do you notice there is an inconsistency in that 'CollectRequest' class
> depending on the way it gets constructed? The 'getDependencies' method
> clearly states:
> 
> @return The direct dependencies, never {@code null}.
> 
> Now compare if that statement is correct (direct vs. transitive)
> depending on how that class has been constructed and tell me why only
> the ScopeDependencySelector above has had logic deciding if those
> dependencies are transitive or direct when all other
> selector,traverser,manager implementations did not.
> 
> There is this resolver only a few people seem to have taken a closer
> look at. I am not telling anyone how things should behave and what has
> to change etc. There is an API Maven is calling into no-one has ever
> verified is doing what it is stating in it's Javadoc. Now compare the
> Javadoc of those constructors of that CollectRequest class above to the
> Javadoc of the getDependencies and addDependency methods of that same
> class. Only one class (ScopeDependencySelector) handled things
> differently (direct vs. transitive). There are plenty of other classes
> not handling anything differently. Either that ScopeDependencySelector
> got it right and all other classes need to be updated or it's the other
> way around. I tried both. That has led to MNG-6135. What we now have on
> master (resolver and core) is consistent to what the Javadoc of those
> getDependencies and addDependency methods state. And still Herv made a
> very valid point during this. Why is there such a difference at all?
> 
> Regards,
> 


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/25/16 um 11:57 schrieb Robert Scholte:
> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <cs...@schulte.it>  
> wrote:
> 
>> Am 12/24/16 um 18:40 schrieb Guillaume Bou:
>>> Why would the PMD plugin care about what Doxia require transitively?
>>> Christian, can you explain a bit more why those changes are needed?
>>
>> Classpath consistency. Running the unit tests with a completely
>> different classpath than what the plugin is using at runtime makes those
>> unit tests meaningless, so to say.
>>
> 
> We're talking about *unittests*, they should test one unit. In those cases  
> there should be no issue which such dependencies, because if that unit  
> requires a certain dependency, it should already have been defined as  
> direct dependency.

Exactly. In the "widest" scope required. In this case, that's not the
test scope but the compile scope. It's not the test scope overriding the
compile scope here. It's the nearest declaration overriding a transitive
dependency in an incompatible way. What if those two dependencies
(compile and test) would require different major versions of that
dependency? That's the "one tree per project" issue I have been talking
about.

> If a test framework requires a newer version of some dependency also  
> required at compile time, it is weird to be forced to upgrade this  
> dependency just for testing (and what if this dependency is compiled with  
> a newer version of Java compared to the max of the project).

Still means you are not testing the runtime classpath. You know things
are working in test scope. There are different artifacts in the runtime
scope you never have tested. The ITs are different. You would need to
duplicate all unit tests in the ITs. That's not possible most of the
time (you are executing goals in the ITs - you cannot instantiate a
class and perform various tests with that from the ITs).

> Maybe it is also caused by the current implementation of test tools. JUnit  
> is using its own classpath for everything. I've been talking with them if  
> it would make sense to give the JUnit engine, the test classes and the  
> main classes all their own classloader. That would make it possible to  
> have better separation.
> 
> I understand the statement of classpath consistency, I used to think like  
> that in the past too, but for *unit*testing this shouldn't matter. That's  
> why integration tests are just as important.

All I did is make an implementation behave as is documented in it's
Javadoc. Please take a look at this class.

<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-api/src/main/java/org/eclipse/aether/collection/CollectRequest.java;h=d9c252733d0bdcef3c3b6fcb3313a0b21f5b6253;hb=HEAD>

Read the Javadoc of all constructors. Concentrate on direct vs.
transitive here. Read the Javadoc of the getDependencies and
addDependency methods as well. Again, concentrate on direct vs.
transitive here as well.

Now read the Javadoc of this class.

<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/selector/ScopeDependencySelector.java;h=92db1417e8affadd976e2c51a38b33500161ce45;hb=HEAD>

/**
 * A dependency selector that filters transitive dependencies based on
their scope. Direct dependencies are always
 * included regardless of their scope. <em>Note:</em> This filter does
not assume any relationships between the scopes.
 * In particular, the filter is not aware of scopes that logically
include other scopes.
 *
 * @see Dependency#getScope()
 */
public final class ScopeDependencySelector
    implements DependencySelector

The class calling into this is the DefaultDependencyCollector.

<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blob;f=maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java;h=aaf5865f3fe74060e60be35f1d2bd9b13c69d206;hb=HEAD>

Do you notice there is an inconsistency in that 'CollectRequest' class
depending on the way it gets constructed? The 'getDependencies' method
clearly states:

@return The direct dependencies, never {@code null}.

Now compare if that statement is correct (direct vs. transitive)
depending on how that class has been constructed and tell me why only
the ScopeDependencySelector above has had logic deciding if those
dependencies are transitive or direct when all other
selector,traverser,manager implementations did not.

There is this resolver only a few people seem to have taken a closer
look at. I am not telling anyone how things should behave and what has
to change etc. There is an API Maven is calling into no-one has ever
verified is doing what it is stating in it's Javadoc. Now compare the
Javadoc of those constructors of that CollectRequest class above to the
Javadoc of the getDependencies and addDependency methods of that same
class. Only one class (ScopeDependencySelector) handled things
differently (direct vs. transitive). There are plenty of other classes
not handling anything differently. Either that ScopeDependencySelector
got it right and all other classes need to be updated or it's the other
way around. I tried both. That has led to MNG-6135. What we now have on
master (resolver and core) is consistent to what the Javadoc of those
getDependencies and addDependency methods state. And still Herv made a
very valid point during this. Why is there such a difference at all?

Regards,
-- 
Christian


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <cs...@schulte.it>  
wrote:

> Am 12/24/16 um 18:40 schrieb Guillaume Boué:
>> Why would the PMD plugin care about what Doxia require transitively?
>> Christian, can you explain a bit more why those changes are needed?
>
> Classpath consistency. Running the unit tests with a completely
> different classpath than what the plugin is using at runtime makes those
> unit tests meaningless, so to say.
>

We're talking about *unittests*, they should test one unit. In those cases  
there should be no issue which such dependencies, because if that unit  
requires a certain dependency, it should already have been defined as  
direct dependency.
If a test framework requires a newer version of some dependency also  
required at compile time, it is weird to be forced to upgrade this  
dependency just for testing (and what if this dependency is compiled with  
a newer version of Java compared to the max of the project).
Maybe it is also caused by the current implementation of test tools. JUnit  
is using its own classpath for everything. I've been talking with them if  
it would make sense to give the JUnit engine, the test classes and the  
main classes all their own classloader. That would make it possible to  
have better separation.

I understand the statement of classpath consistency, I used to think like  
that in the past too, but for *unit*testing this shouldn't matter. That's  
why integration tests are just as important.

Robert

>
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Christian Schulte <cs...@schulte.it>]

Am 12/24/16 um 18:40 schrieb Guillaume Bou:
> Why would the PMD plugin care about what Doxia require transitively? 
> Christian, can you explain a bit more why those changes are needed?

Classpath consistency. Running the unit tests with a completely
different classpath than what the plugin is using at runtime makes those
unit tests meaningless, so to say.


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Guillaume Boué <gb...@apache.org>]

Why would the PMD plugin care about what Doxia require transitively? 
Christian, can you explain a bit more why those changes are needed?


Le 24/12/2016  17:59, Herv BOUTEMY a crit :
> +1
>
> notice that it may show that we have an issue with the way transitivity +
> nearest resolution are applied
>
> IIUC this case, we have:
> 1. a direct dependency with scope = test
> 2. a transitive dependency with scope = compile
>
> the result can't be just the direct dependency with scope=test: scope of
> direct dependency has to switch to compile (and I don't know which version
> should be kept: direct or transitive)
>
> I'm sure we have edge cases with transitive dependencies algorithm and scopes
>
> For a long time now, I want to create a builder API to create dependencies
> unit tests, to ease creating tests, avoiding the nightmare of creating a bunch
> of pom.xml files in a test local repo that are used by a unit test, with hard
> to document rationale
> Seems like it is time to work on it now...
>
> Regards,
>
> Herv
>
> Le samedi 24 dcembre 2016, 17:03:03 CET Robert Scholte a crit :
>> With this commit commons-io gets the default scope.
>> Suppose PMD drops commons-io, then there's no reason that this dependency
>> has the compile scope.
>> Assuming the unittests are using commons-io it makes sense that it has the
>> test-scope.
>> Be aware that users can overwrite dependencies of plugins in their pom.xml
>> Developers can only know about the dependencies for their src/main/java
>> and src/test/java code, and cannot do any assumptions about transitive
>> dependencies due to all the override mechanisms in Maven.
>> It may be clear that I don't like these changes.
>>
>> Robert
>>
>> On Sat, 24 Dec 2016 15:56:53 +0100, <sc...@apache.org> wrote:
>>> Author: schulte
>>> Date: Sat Dec 24 14:56:53 2016
>>> New Revision: 1775971
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1775971&view=rev
>>> Log:
>>> [MPMD-230] Required class missing: org/apache/commons/io/IOUtils
>>>
>>> Modified:
>>>      maven/plugins/trunk/maven-pmd-plugin/pom.xml
>>>
>>> Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xml?
>>> rev=1775971&r1=1775970&r2=1775971&view=diff
>>> =========================================================================
>>> ===== --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
>>> +++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53 2016
>>> @@ -216,13 +216,13 @@ under the License.
>>>
>>>         <groupId>org.apache.httpcomponents</groupId>
>>>         <artifactId>httpclient</artifactId>
>>>         <version>4.3.5</version>
>>>
>>> -      <scope>test</scope>
>>> +      <!-- scope>test</scope> Required by Doxia transitively. -->
>>>
>>>       </dependency>
>>>       <dependency>
>>>       
>>>         <groupId>commons-io</groupId>
>>>         <artifactId>commons-io</artifactId>
>>>         <version>2.5</version>
>>>
>>> -      <scope>test</scope>
>>> +      <!-- scope>test</scope> Required by PMD transitively. -->
>>>
>>>       </dependency>
>>>     
>>>     </dependencies>
>> ---------------------------------------------------------------------
>> 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
>


---
L'absence de virus dans ce courrier lectronique a t vrifie par le logiciel antivirus Avast.
https://www.avast.com/antivirus


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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

+1

notice that it may show that we have an issue with the way transitivity + 
nearest resolution are applied

IIUC this case, we have:
1. a direct dependency with scope = test
2. a transitive dependency with scope = compile

the result can't be just the direct dependency with scope=test: scope of 
direct dependency has to switch to compile (and I don't know which version 
should be kept: direct or transitive)

I'm sure we have edge cases with transitive dependencies algorithm and scopes

For a long time now, I want to create a builder API to create dependencies 
unit tests, to ease creating tests, avoiding the nightmare of creating a bunch 
of pom.xml files in a test local repo that are used by a unit test, with hard 
to document rationale
Seems like it is time to work on it now...

Regards,

Hervé

Le samedi 24 décembre 2016, 17:03:03 CET Robert Scholte a écrit :
> With this commit commons-io gets the default scope.
> Suppose PMD drops commons-io, then there's no reason that this dependency
> has the compile scope.
> Assuming the unittests are using commons-io it makes sense that it has the
> test-scope.
> Be aware that users can overwrite dependencies of plugins in their pom.xml
> Developers can only know about the dependencies for their src/main/java
> and src/test/java code, and cannot do any assumptions about transitive
> dependencies due to all the override mechanisms in Maven.
> It may be clear that I don't like these changes.
> 
> Robert
> 
> On Sat, 24 Dec 2016 15:56:53 +0100, <sc...@apache.org> wrote:
> > Author: schulte
> > Date: Sat Dec 24 14:56:53 2016
> > New Revision: 1775971
> > 
> > URL: http://svn.apache.org/viewvc?rev=1775971&view=rev
> > Log:
> > [MPMD-230] Required class missing: org/apache/commons/io/IOUtils
> > 
> > Modified:
> >     maven/plugins/trunk/maven-pmd-plugin/pom.xml
> > 
> > Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xml?
> > rev=1775971&r1=1775970&r2=1775971&view=diff
> > =========================================================================
> > ===== --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
> > +++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53 2016
> > @@ -216,13 +216,13 @@ under the License.
> > 
> >        <groupId>org.apache.httpcomponents</groupId>
> >        <artifactId>httpclient</artifactId>
> >        <version>4.3.5</version>
> > 
> > -      <scope>test</scope>
> > +      <!-- scope>test</scope> Required by Doxia transitively. -->
> > 
> >      </dependency>
> >      <dependency>
> >      
> >        <groupId>commons-io</groupId>
> >        <artifactId>commons-io</artifactId>
> >        <version>2.5</version>
> > 
> > -      <scope>test</scope>
> > +      <!-- scope>test</scope> Required by PMD transitively. -->
> > 
> >      </dependency>
> >    
> >    </dependencies>
> 
> ---------------------------------------------------------------------
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

With this commit commons-io gets the default scope.
Suppose PMD drops commons-io, then there's no reason that this dependency  
has the compile scope.
Assuming the unittests are using commons-io it makes sense that it has the  
test-scope.
Be aware that users can overwrite dependencies of plugins in their pom.xml
Developers can only know about the dependencies for their src/main/java  
and src/test/java code, and cannot do any assumptions about transitive  
dependencies due to all the override mechanisms in Maven.
It may be clear that I don't like these changes.

Robert

On Sat, 24 Dec 2016 15:56:53 +0100, <sc...@apache.org> wrote:

> Author: schulte
> Date: Sat Dec 24 14:56:53 2016
> New Revision: 1775971
>
> URL: http://svn.apache.org/viewvc?rev=1775971&view=rev
> Log:
> [MPMD-230] Required class missing: org/apache/commons/io/IOUtils
>
>
> Modified:
>     maven/plugins/trunk/maven-pmd-plugin/pom.xml
>
> Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
> URL:  
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xml?rev=1775971&r1=1775970&r2=1775971&view=diff
> ==============================================================================
> --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
> +++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53 2016
> @@ -216,13 +216,13 @@ under the License.
>        <groupId>org.apache.httpcomponents</groupId>
>        <artifactId>httpclient</artifactId>
>        <version>4.3.5</version>
> -      <scope>test</scope>
> +      <!-- scope>test</scope> Required by Doxia transitively. -->
>      </dependency>
>      <dependency>
>        <groupId>commons-io</groupId>
>        <artifactId>commons-io</artifactId>
>        <version>2.5</version>
> -      <scope>test</scope>
> +      <!-- scope>test</scope> Required by PMD transitively. -->
>      </dependency>
>    </dependencies>
>

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