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

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

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

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

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

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

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

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

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)

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

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

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

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)

-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

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