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

No that is not quite what I am saying... I'll respond in detail later On Thu 12 Jan 2017 at 20:32, Christian Schulte wrote: > Am 12.01.2017 um 12:09 schrieb Robert Scholte: > > > On Thu, 12 Jan 2017 09:00:16 +0100, Hervé BOUTEMY > > > > wrote: > > > > > >> Do we agree on the initial explanation

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

Am 12.01.2017 um 12:09 schrieb Robert Scholte: > On Thu, 12 Jan 2017 09:00:16 +0100, Hervé BOUTEMY > wrote: > >> Do we agree on the initial explanation about the plugin runtime >> resolution hack? > > The first thing Maven does is create a BuildPlan. This means that the > plugins being par

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

On Thu, 12 Jan 2017 09:00:16 +0100, Hervé BOUTEMY wrote: Do we agree on the initial explanation about the plugin runtime resolution hack? The first thing Maven does is create a BuildPlan. This means that the plugins being part of this run are initiated. This is also the reason why a ma

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

I'm not ok with the "maven baseline" approach: IMHO, there is no such thing during plugin dependencies resolution. AFAIK, plugin dependencies resolution happens "normally" (or more precisely with the current hack for test or provided scoped dependencies), then when plugin "classpath" creation h

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

Am 12/23/16 um 10:33 schrieb Stephen Connolly: > Ok, so I think we need to change how we describe things a bit. > > Project resolution starts from a clean baseline. If you have a project with > zero dependencies (other than those implicit in being a java project say... > which means the JRE classp

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

Le samedi 24 décembre 2016, 18:33:06 CET Guillaume Boué a écrit : > Yes, I agree with this. The plugin doesn't need to inspect its own > annotations at runtime, so the dependency is "only needed at > compile-time, unused at run-time". The provided scope may be a bit of an > abuse for lack of a "com

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

Le 24/12/2016 à 17:11, Hervé BOUTEMY a écrit : Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit : 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

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

seriously, you should make an effort to improve description of the failures caused by the MRESOLVER-8 bugfix (which AFAIK only causes breaks: not so many, but only breaks currently, so it's hard to call MRESOLVER-8 a real fix...) Regards, Hervé Le samedi 24 décembre 2016, 15:58:20 CET Christia

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

Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit : > 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 on

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

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

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)

Ok, so I think we need to change how we describe things a bit. Project resolution starts from a clean baseline. If you have a project with zero dependencies (other than those implicit in being a java project say... which means the JRE classpath is an implicit dependency) then you just have the imp

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

I setup a Jenkins job today running weekly testing that a release build can be performed successfully with the current Maven master and that core and plugin ITs do pass with the result of that build. It will send mails to dev@ with a subject starting with [NOTIFICATION].

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 >> >>> Dependency management is way too important, you s

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

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 > > > Dependency management is way too important, you should not have an option > > to choose. Better t

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 curren

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

-0.9 for the commandline option, there should be only one truth. 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 current behavior. And that'll take time. I will have a look at

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:

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: Improving Jenkins

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? And remember we'll require to prepare a list of known plugin

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

Le mardi 20 décembre 2016, 03:45:47 CET Christian Schulte a écrit : > 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 depe

Re: Improving Jenkins

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 case where the new behaviour fixes a non-working configura

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 snapshot

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 just made two selector implemen

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? >From what I can tell

Re: Improving Jenkins

Le lundi 19 décembre 2016, 03:39:15 CET Christian Schulte a écrit : > 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

Re: Improving Jenkins

No. my son is only in school during the AM, so you might have a chance to try some iterations to get it working sooner... we are only prodding the dark! (And I'm validating my complaints about how literate is better than jenkinsfile... but I lost that popularity contest) Or anyone else can too (ju

Re: Improving Jenkins

For windows? Am I punished ? Bouhhh Le lun. 19 déc. 2016 à 15:17, Stephen Connolly < stephen.alan.conno...@gmail.com> a écrit : > https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile > > > > Working on a Jenkinsfile... should work for linux on Java 7 & 8... getting > > the Windows

Re: Improving Jenkins

https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkinsfile Working on a Jenkinsfile... should work for linux on Java 7 & 8... getting the Windows builds working will be "fun"... perhaps Arnaud can assist! On 19 December 2016 at 09:41, Stephen Connolly < stephen.alan.conno...@gmail.com> w

Re: Improving Jenkins

We should probably look at switching to multi-branch / org folders... I released a set of -beta-1 releases on Friday (due to some scaredy-cats not being comfortable with pushing full releases to the update centre on a Friday afternoon before I start a 2 week break! Chickens!) These releases sign

Re: Re: Improving Jenkins

> > And updating plugins for Maven own builds to work now won't help Maven > > users > > to update their builds > > 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: Improving Jenkins

thank you for these explanations: I'll have a deep look tonight Regards, Hervé Le lundi 19 décembre 2016, 04:12:01 CET Christian Schulte a écrit : > 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 cla

Re: Improving Jenkins

Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit : > 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

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 nearly an hour but i

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. >> Everything is built some time

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

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 mast

Re: Improving Jenkins

Am 2016-12-18 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 master is a

Re: Improving Jenkins

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 master is a big giant mess lately, with updates and reve

Re: Improving Jenkins

Am 12/17/16 um 11:52 schrieb Hervé BOUTEMY: > looks like MNG-6135 causes a lot of issues > > "Maven plugins and core extensions are not dependencies, they should be > resolved the same way as projects." > "Maven plugins and core extensions are not dependencies": why not > "they should be resolved

Re: Improving Jenkins

looks like MNG-6135 causes a lot of issues "Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects." "Maven plugins and core extensions are not dependencies": why not "they should be resolved the same way as projects": why? what does that mean? t

Re: Improving Jenkins

I fixed core-integration-testing-maven-3-embedded job (since wiping out the workspace was not sufficient because this target was re- appearing and rat complained, I just ran a build with -Drat.skip) Other Maven 3 jobs are failing for other cause [1], I did not investigate Regards, Hervé [1] ht

Improving Jenkins

Hi, I renamed the 'maven-aether-provider' module to 'maven-resolver-provider'. What happens on Jenkins is this: The 'maven-aether-provider' folder will not get deleted correctly when Jenkins performs the SCM update/checkout. This may be due to the existence of the 'maven-aether-provider/target' fo