Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/08/17 um 01:49 schrieb Fred Cooke: > Christian, some (potentially unwelcome) advice: Learn to use rebase, learn > to fetch, never pull, and review your changes in their new context before > pushing them. I just wasn't used to someone git push --force. As we discussed on dev@, it would have

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/07/17 um 04:00 schrieb Tibor Digana: > I have created a pull request > https://github.com/apache/maven-surefire/pull/139 > The build passed successfully. > Christian, Benedikt please have a look and I will amend the HEAD revision > in origin/master. > Thx. Damn it. I did not read your

Re: Cannot edit or comment on Wiki pages

Am 01/04/17 um 08:44 schrieb Hervé BOUTEMY: > Hi, > > I don't know how it was done (a good number of years ago) for me to have edit > karma, but I have. > I looked for INFRA documentation on the topic, and found related procedure I > didn't know [1] > > I don't know who is the "Space Admin"

Re: Flakey Integration Test in post-reset-master

Maybe just test if things change when running those ITs multiple times with Maven 3.0.5 instead of 3.3.9. Am 01/05/17 um 02:37 schrieb Christian Schulte: > Am 01/04/17 um 20:16 schrieb Stephen Connolly: >> https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset

Re: Flakey Integration Test in post-reset-master

Am 01/04/17 um 20:16 schrieb Stephen Connolly: > https://builds.apache.org/view/Maven/job/maven-jenkinsfile/job/post-reset-master/6/testReport/junit/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVTest/testitUseHttpProxyForWebDAV_2/ > > Seems to fail at random on Windows... > It may be a

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

+1 (committer) Am 01/04/17 um 13:16 schrieb Stephen Connolly: > Hi, > > We have collectively managed to mess up our ability to follow the original > release plan for 3.4.0 which was originally supposed to consist of an > effective no-op change of Eclipse's Aether for the code after migration to

Cannot edit or comment on Wiki pages

Hi, user name is "schulte". I am not sure about this, but I think I do not have permission to do anything in the Wiki. I can read everything, but cannot edit things or comment on things. Regards, -- Christian - To unsubscribe,

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 01/03/17 um 14:55 schrieb Robert Scholte: > Unscrubbed: > MNG-5670 - ConcurrentModificationException during > DefaultMaven.newRepositorySession This is related to MNG-6053 and MNG-6105. You can see that there is a commit @MNG-6105 touching 'MavenRepositorySystemUtils' as well. Should be

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/02/17 um 21:01 schrieb Benson Margulies: > On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY wrote: > >> Christian, >> >> Please read Tibor's concerns: >> - big change, >> - near release (with parallel branches for JUnit 5) >> And I'll add: noise, like addition of final,

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

There may be a misunderstanding here. I do not blame anyone for those surefire failures I am getting on Jenkins and locally. This is nothing I am interested in. I very seldomly take a look at commit history. If I do, only to find out about - well - the history of changes or because I need to

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/02/17 um 21:01 schrieb Benson Margulies: > On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY wrote: > >> Christian, >> >> Please read Tibor's concerns: >> - big change, >> - near release (with parallel branches for JUnit 5) >> And I'll add: noise, like addition of final,

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

Am 01/02/17 um 18:45 schrieb Tibor Digana: > Why then you did not provide logs in Jira? > MasterProcessCommand.java would behave with or without your change because > the read() method will always wait for at least one byte to read. The only > exception is read(byte[]) will return 0 if and only if

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

I am not checking out surefire because I am bored. I get blamed for failing ITs and I am quite pissed that the CI system is sending out failure notifications and all you see is an issue with surefire and not with the build job or the actual build you get an email for. With current master, there

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

On a side note to this: I am getting quite a few IT failures building surefire locally with Maven 3.3.9 also without that commit. If surefire is unreliable, Maven is unreliable. Am 01/02/17 um 18:22 schrieb Christian Schulte: > And now everyone please take a look at that commit and tell me w

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

And now everyone please take a look at that commit and tell me what is so hard about it to review? You are not able to scroll through this and verify what is going on? It's something very trivial.

Re: Build failed in Jenkins: core-it-maven-3-win #1433

Really no one knows why that IT has started to fail sporadically on Windows? Am 01/01/17 um 23:06 schrieb Apache Jenkins Server: > See > > Changes: > > [stephen.alan.connolly] hopefully the final Jenkinsfile fix > >

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 01/01/17 um 16:09 schrieb Stephen Connolly: > If you want to know the current status check > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 Can I edit that page myself? User name is "schulte". Regarding the drop in replacement for 3.3.9: MNG-2199 was already working in Maven

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 01/01/17 um 18:44 schrieb Guillaume Boué: > > There is a commit about MRESOLVER-9 in tag 2.11 of Wagon: > https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422. > > I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:23 schrieb Christian Schulte: > Am 01/01/17 um 08:18 schrieb Christian Schulte: >> Once more I asked someone to test a snapshot and provided a link to >> Jenkins. That's where all those commits come from. I hope I'll get >> feedback on this one and

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:06 schrieb Christian Schulte: > It's not even needed to change the plugin tools version any more. Only > plugins having declared > > 3.4 > > would get the correct resolution. As of yesterday. Happy new

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:18 schrieb Christian Schulte: > Once more I asked someone to test a snapshot and provided a link to > Jenkins. That's where all those commits come from. I hope I'll get > feedback on this one and that could again lead to commits. Doing this on > a release branch -

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte: > Number of fixes to plugin POMs was lower than 10 commits. During all of > this quite a few other bugs have been identified in the core, the ITs, > the plugins, the plugin ITs, etc. Last issue I created in JIRA due to this is

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 08:06 schrieb Christian Schulte: > Am 01/01/17 um 07:52 schrieb Christian Schulte: >> is uncovering bugs in the poms. Current master is passing all core ITs, >> all plugin ITs and also can be used to build all plugins, if you >> manually change to a different

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 01/01/17 um 07:52 schrieb Christian Schulte: > is uncovering bugs in the poms. Current master is passing all core ITs, > all plugin ITs and also can be used to build all plugins, if you > manually change to a different plugin tools release > (-DmavenPluginToolsVersion=3.3 or

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 12:13 schrieb Guillaume Boué: > > Having a vote on all changes to master sounds too much. I think it > should be up to the developers to always raise discussions whenever a > change would have impacts on existing ITs, or whenever a new feature is > considered to be added. Bug

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 17:36 schrieb Hervé BOUTEMY: > looks like 1.1.0 was released without tagging the repo: no tag even in > Eclipse > git [1]. I hope it is a state that is in git, even without tag: if someone > can > define the git hash, it would be useful to add a tag, just for reference > > I

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

What I marked FIX-3.6.0 could also be marked FIX-4.0.0. I cannot tell. I would have made it part of 3.4.0 so better someone else decides that. Am 01/01/17 um 05:42 schrieb Christian Schulte: > Am 12/31/16 um 21:10 schrieb Stephen Connolly: >> Here are the changes in current master si

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

I think it would be easier if we just update the JIRA issues and set the version the issue will be shipped in. We already have a 3.5.0 version available. That will be the next Maven release? So we would need a 3.6.0 version and a 4.0.0 version and a 5.0.0 version. Let 4.0.0 be the next major

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 12/31/16 um 21:10 schrieb Stephen Connolly: > Here are the changes in current master since 3.3.9 (with some minor changes > omitted) > > Issue ID Target Version Summary > == > MNG-1577 WONTFIX

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 12/31/16 um 22:14 schrieb Stephen Connolly: > FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837, > MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001, > MNG-6003, MNG-6078 MNG-5968 will require updates to the ITs due to the maven-plugin-plugin no longer

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

I'd also like to add FIX-3.5.0: MNG-2199 It was working in Maven 3.2.2 but got broken the next release. This went unnoticed because the ITs were not correct. Back then I did not notice that Maven does not fail the build if it cannot resolve a parent but just logs a warning. The ITs did not check

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 01/01/17 um 01:55 schrieb Michael Osipov: > Undecided: > MNG-5708: fixed by Christian's work Should not be done in that release. Let's ship all bugfixes affecting resolution together - not just one after the other. All or nothing. So nothing.

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

Am 31.12.2016 um 22:14 schrieb Stephen Connolly: > FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837, > MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001, > MNG-6003, MNG-6078 > > I think colourised logging probably should be 3.5.x but I am open to the >

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 03:27 schrieb Christian Schulte: > Am 12/29/16 um 13:49 schrieb Robert Scholte: >> My worries are more about: how to manage which issues should be cherry >> picked and who decides that list. Otherwise we might end up in the same >> situation. E.g. do

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/31/16 um 03:27 schrieb Christian Schulte: > Am 12/29/16 um 13:49 schrieb Robert Scholte: >> My worries are more about: how to manage which issues should be cherry >> picked and who decides that list. Otherwise we might end up in the same >> situation. E.g. do

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 13:49 schrieb Robert Scholte: > My worries are more about: how to manage which issues should be cherry > picked and who decides that list. Otherwise we might end up in the same > situation. E.g. do we have to do a vote on the branch (which might cover > multiple issues but

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 19:05 schrieb Stephen Connolly: > Focus on the versions we have released. That IT also fails with Maven 3.3.9 due to the same reason. [ERROR] The following builds failed: [ERROR] * projects\basic-features\space & special char\pom.xml

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 22:06 schrieb Christian Schulte: > Am 12/30/16 um 19:05 schrieb Stephen Connolly: >> Given that I'm not seeing any objections yet to throwing out 3.4.x and >> redoing via cherry-pick as 3.5.x I think we should forget about any tests >> run with 3.4.0-

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 19:05 schrieb Stephen Connolly: > Given that I'm not seeing any objections yet to throwing out 3.4.x and > redoing via cherry-pick as 3.5.x I think we should forget about any tests > run with 3.4.0-SNAPSHOTs > > Focus on the versions we have released. The IT is running with

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 11:00 schrieb Guillaume Boué: > Hi Christian, > > I remember adding those 2 ITs after raising a concern on dev (see > attached mail). They were passing with 3.3.9 and latest 3.4.0 at that time. > > Is there an issue updating those tests with regard to MNG-5457? I > noticed this

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/30/16 um 09:01 schrieb Robert Scholte: > On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY > wrote: > >> perhaps maven-resolver will require same reset > > +1 > > IMO we forgot to do a release with the original Aether code with the new > GAVs. > Keep in mind

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 15:47 schrieb Christian Schulte: > Am 12/30/16 um 11:00 schrieb Guillaume Boué: >> Is there an issue updating those tests with regard to MNG-5457? > > I do not have a Windows box. Issue was due to the ITs failing on > Windows. I verified the scripts compile w

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

Am 12/30/16 um 11:00 schrieb Guillaume Boué: > Is there an issue updating those tests with regard to MNG-5457? I do not have a Windows box. Issue was due to the ITs failing on Windows. I verified the scripts compile with groovy locally. Currently there still seems to be an issue with the Windows

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: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 16:04 schrieb Michael Osipov: > Am 2016-12-29 um 12:18 schrieb Stephen Connolly: >> On ASF infra, our master branch is supposed to be a protected branch and >> thus cannot be reset or force-pushed without an INFRA ticket. >> >> If we want to reset our master branch in order to clean

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 18:57 schrieb Hervé BOUTEMY: > perhaps maven-resolver will require same reset No need for this. Reverting MRESOLVER-8 and MRESOLVER-9 will be sufficient. Those are one-line style of commits. The rest of the commits do not change any behaviour.

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

Am 12/29/16 um 12:18 schrieb Stephen Connolly: > I propose that we reset master back > to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of > master for the integration tests, and then immediately commit a dummy > commit so that nobody accidentally does a fast-forward push. +1

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:50 schrieb Robert Scholte: > "That's always been that way." > Well, apparently not. Maybe it was documented that way, but I expect that > users did their dependency management which felt natural and which worked. I created an issue in JIRA to track this:

Re: [VOTE] Releasing Wagon 2.11

>> Right now I see Wagon as a reference project for Maven 3.4.0: I disagree. It relies on overriding management althought that correctly is not supported when consumed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 03:19 schrieb Christian Schulte: > Am 12/29/16 um 02:41 schrieb Christian Schulte: >> Am 12/29/16 um 02:36 schrieb Christian Schulte: >>> Am 12/29/16 um 00:41 schrieb Michael Osipov: >>>> If this is how it should (I am neither pro nor cons) w

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:41 schrieb Christian Schulte: > Am 12/29/16 um 02:36 schrieb Christian Schulte: >> Am 12/29/16 um 00:41 schrieb Michael Osipov: >>> If this is how it should (I am neither pro nor cons) work, we should >>> deprecate this element or at least put a

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:36 schrieb Christian Schulte: > Am 12/29/16 um 00:41 schrieb Michael Osipov: >> If this is how it should (I am neither pro nor cons) work, we should >> deprecate this element or at least put a big WARNING on it. > > We should spit out a big fat war

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov: > If this is how it should (I am neither pro nor cons) work, we should > deprecate this element or at least put a big WARNING on it. We should spit out a big fat warning whenever someone overrides hers/his own management. It shouldn't even be possible

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:12 schrieb Christian Schulte: > Am 12/29/16 um 00:41 schrieb Michael Osipov: >> Am 2016-12-28 um 22:51 schrieb Christian Schulte: >>> I just pushed a fix for this. I could also have made that transitive >>> dependency a direct one, where it is used, an

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov: > Am 2016-12-28 um 22:51 schrieb Christian Schulte: >> I just pushed a fix for this. I could also have made that transitive >> dependency a direct one, where it is used, and could have left the scope >> management in. >>

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > > How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then? > I'd say this is the root cause of nearly all issues we are having a hard time fixing and shipping. It does not make sense to compare some recent behaviour to some former

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > This is the tree with Maven 3.3.9: > > [DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT > [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile > [DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test > [DEBUG]

Re: [VOTE] Releasing Wagon 2.11

To be even more clear: It's bullshit you can override the management in the POM when those overrides disappear transitively. Do not override management and be done with it. - To unsubscribe, e-mail:

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:50 schrieb Robert Scholte: > Which makes me wonder if this really is a fix. Wagon can be built with a > wide range of Maven version covering a lot of years AND the > maven-dependency-plugin shows what you would expect: junit is available > with test-scope. > > "That's

Re: [VOTE] Releasing Wagon 2.11

I just pushed a fix for this. I could also have made that transitive dependency a direct one, where it is used, and could have left the scope management in. "Dependency management overrides are not transitive." - To

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué: > > How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then? Because it does not come with MRESOLVER-9 fixed. - To unsubscribe, e-mail:

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 21:34 schrieb Guillaume Boué: > I have the same results as Hervé, both on Windows and Ubuntu. This is > what I have with Maven 3.3.9: > > - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in > HugeFileDownloadTest (perhaps the timeout should be increased?) > - Ubuntu

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

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

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

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

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 >

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

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

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

ieb Christian Schulte: > Am 12/25/16 um 11:57 schrieb Robert Scholte: >> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte <c...@schulte.it> >> wrote: >> >>> Am 12/24/16 um 18:40 schrieb Guillaume Boué: >>>> Why would the PMD plugin care about what Doxi

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 <c...@schulte.it> > wrote: > >> Am 12/24/16 um 18:40 schrieb Guillaume Boué: >>> Why would the PMD plugin care about what Doxia require transitively? >>>

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

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

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.

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

maven-pmd-plugin >= 3.4 is affected. - To unsubscribe, e-mail:

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

maven-resources-plugin < 3.0.2 also is affected. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

emails today until things are setup correctly. Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY: > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit : >> Am 12/22/16 um 19:14 schrieb Robert Scholte: >>> -0.9 for the commandline option, there should be only one truth. &g

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY: > Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit : >> Am 12/22/16 um 19:14 schrieb Robert Scholte: >>> -0.9 for the commandline option, there should be only one truth. >> >> +1 >> >>> De

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

Am 12/22/16 um 19:14 schrieb Robert Scholte: > -0.9 for the commandline option, there should be only one truth. +1 > Dependency management is way too important, you should not have an option > to choose. Better to agree that we are indeed fixing a bug or that we > should maintain the

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

Boils down to: Decide the list of issues part of the next release. Update JIRA to reflect that. Provide the release nodes and what else needs to be documented. Personally, cut a resolver release 1.2.0 from current resolver master and throw out tons of RCs of current core master using either 3.4.0

Re: Improving Jenkins

Am 12/21/16 um 08:04 schrieb Hervé BOUTEMY: > And remember we'll require to prepare a list of known plugins Older findbugs plugin versions are not working with 3.4. The maven-plugin-plugin 3.4 is not working with 3.4. You can downgrade to 3.3 or upgrade to 3.5. That's the plugins I know of.

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

Am 12/21/16 um 13:46 schrieb Christian Schulte: > ago. The next commits from me would be for the Maven site and for the > release notes. Except that command line option. Ok. It really depends on That command line option got added with this commit: <https://git-wip-us.apache.org/re

Roadmap to the next Maven release (Re: Improving Jenkins)

Am 21.12.2016 um 08:04 schrieb Hervé BOUTEMY: > remember: we'll have to explain users why we did a breaking change > I don't think such an explanation will be possible for users: for long-dev > like me, it's hardly a valid explanation > > Can you explain in plain english some cases, please? > >

Re: Scope promotion of managed dependencies in current Maven master

Am 12/20/16 um 10:28 schrieb Michael Osipov: >> Am 12/19/16 um 15:56 schrieb Michael Osipov: >>> [DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile >>> [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from >>> test by

Re: Improving Jenkins

Am 12/20/16 um 08:06 schrieb Hervé BOUTEMY: > I must confess I never investigated why this "provided" recipe worked: it > just > looked nice :) > > but you didn't answer the important part of the question: > From a purist point of view, I understand > From a user point of view, do you have any

Re: Improving Jenkins

Am 12/20/16 um 03:45 schrieb Christian Schulte: > Collaboration is important. It has helped a lot getting those changes > sorted out. In fact, we are still sorting things out now. That's > something very positive. I do use the 3.4.0-SNAPSHOT locally for everything. Whenever I build a new

Re: Improving Jenkins

Am 12/19/16 um 08:32 schrieb Hervé BOUTEMY: > Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit : >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: >> Thats what the resolver does when requested to collect dependencies for >> a POM or for a dependency. I j

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/20/16 um 01:58 schrieb Christian Schulte: > 2. Collect dependency > - > CollectRequest.setRoot(Dependency): > The dependency passed to this method is some *direct* dependency you got > from somewhere. Management is considered to already be applied. Thi

Re: Improving Jenkins

Am 12/19/16 um 23:22 schrieb Hervé BOUTEMY: > Le lundi 19 décembre 2016, 03:39:15 CET Christian Schulte a écrit : >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: > different: IIUC, if the resolution was not different, the failure would have > happened at build time, isn't it? &

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/19/16 um 18:26 schrieb Stephen Connolly: > We need to clarify. > > There is stuff that is "wrong" but has become expected behaviour because we > never "fixed" it => we cannot "fix" now because it will break too many users > > There is stuff that is "wrong" because we broke it, some users

Re: Scope promotion of managed dependencies in current Maven master

Am 12/19/16 um 15:56 schrieb Michael Osipov: > [DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile > [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from > test by com.company.project:project-parent:0.11-SNAPSHOT)

Re: Improving Jenkins

Am 12/19/16 um 00:44 schrieb Christian Schulte: > Master is WIP. Working on a branch does not make Jenkins check anything. > I can continue to use my machine during Jenkins doing it's job. Running > the ITs locally means my machine is unuseable for nearly an hour. Ok. It's not nearl

Re: Improving Jenkins

Am 12/19/16 um 03:39 schrieb Christian Schulte: > Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: > You know what? We want also that libraries classpath are consistent > when built >> and when used as dependencies: nothing specific to plugins and core >> extensions. >> Ev

Re: Improving Jenkins

Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: You know what? We want also that libraries classpath are consistent when built > and when used as dependencies: nothing specific to plugins and core > extensions. > Everything is built some time then used. > If there are some unexpected discrepencies,

Re: Improving Jenkins

Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: > Notice I use the word "update", not "fix": I don't care if you think that the > required update is a positive fix because everything was buggy for 10 years > and > you're the guy who is saving us from the bugs we lived with: for normal > users, >

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

Am 12/18/16 um 13:36 schrieb Robert Scholte: > On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte <c...@schulte.it> > wrote: > >> Am 12/16/16 um 20:30 schrieb Robert Scholte: >>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte <c...@schulte.it> >

Re: Improving Jenkins

Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY: > you are completely missing my point: simply put, when doing such risky change > (that require Review Then Commit), *please do it on a branch*, not on master > (that you'll later revert to postpone to a future Maven version: tracking > changes on

Re: Cannot build any Maven plugins with current 3.4.0

Am 12/17/16 um 21:56 schrieb Guillaume Boué: > Yes, I confirm that the build of the Maven plugins is OK when checking > out cc5af1306ff91d9bef68737c96c364a371a477d7. > > > Le 17/12/2016 à 16:43, Hervé BOUTEMY a écrit : >> if you avoid the 3 last commits flagged as MNG-6135, you get a fairly

Re: Cannot build any Maven plugins with current 3.4.0

Am 12/17/16 um 21:56 schrieb Guillaume Boué: > Yes, I confirm that the build of the Maven plugins is OK when checking > out cc5af1306ff91d9bef68737c96c364a371a477d7. There is one more issue I need to fix in the core to make the ITs pass again. This is only about dependencies of plugins declared

<    1   2   3   4   5   6   7   >