maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <>
Subject Re: Improving Jenkins
Date Sun, 18 Dec 2016 10:33:46 GMT
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 big giant mess lately, with updates and reverts in
> every place!)

I must agree here, I cannot not read the Git log anymore. It is terribly 

> 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 the guy who is saving us from the bugs we lived with: for normal users,
> it worked and you're once again  breaking Maven

Fixing long-standing issues people lived with is hard, I do agree, but 
this does not mean we shouldn't do it. Rather this has to be a new major 

> Le samedi 17 décembre 2016, 21:34:54 CET Christian Schulte a écrit :
>> 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 the same way as projects": why? what does that
>>> mean? they are not really currently built project either
>>> I'm not yet asking to revert, but seriously, such changes done now without
>>> explanations, tests (and after having maven-resolver-provider that caused
>>> false positives on ASF Jenkins => we're in the blue), I really dislike it
>>> I'm starting to be really tired of constant heavy changes like that :(
>> I am still looking into it. I'll provide some examples later we can talk
>> about. Currently I agree with Igor that the resolution should be done
>> that way. As far as I understand it we want the plugins and core
>> extensions to use the same classpath when executed and when build.
>> Currently this is not the case.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message