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

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

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

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.

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

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.

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

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

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

On Wed, 28 Dec 2016 11:47:40 +0100, Hervé BOUTEMY 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 a

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

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

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

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

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

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 depe

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

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

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

On Mon, 26 Dec 2016 17:07:14 +0100, Christian Schulte 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 b

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

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 wh

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

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

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

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

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

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

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

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

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

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 c

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

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

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

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

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

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 >

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

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 tha

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

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

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

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

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

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

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

Am 12/25/16 um 11:57 schrieb Robert Scholte: > In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte > 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 ar

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

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 si

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

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 injecte

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

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 wrote: Am 12/24/16 um 17:03 sc

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

In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte 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 w

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

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 wrote: > Am 12/24/16 um 17:59 schrieb Hervé BOUTEMY: > > > +1 > > > > > > notice that it may show that

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

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 resul

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

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 usi

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

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

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

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

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

+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

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

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