maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schulte>
Subject Re: Improving Jenkins
Date Sun, 18 Dec 2016 23:44:48 GMT
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 master is a big giant mess lately, with updates and reverts in 
> every place!)

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. If the
ITs are running fine locally, it happened way to often that the ITs on
Jenkins failed due to other reasons. I do run them locally whenever
Jenkins sends out failure notices to reproduce things locally. I am no
fan of developers working for weeks on theire own and then trying to
integrate their weeks of work all in one go no-one has ever had a chance
to follow and comment.

> and on "As far as I understand it we want the plugins and core
>  extensions to use the same classpath when executed and when build"
> 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. 

I am not the author who made that a difference but there is a
difference. There is a reason some logic is in place deciding to select
a transitive dependency or to ignore it. That's just the way Maven is

- depdency (always selected, no matter what)
  - transitive dependency (selected only if not non-transitive)

- transitive dependency (selected if not non-transitive)

Thats what the resolver does when requested to collect dependencies for
a POM or for a dependency. I just made two selector implementations
behave the same. Some were updated to reflect this difference. Some were
not. They are now all behaving the same. Plugins and core extensions
were resolved as dependencies. This started to work consistently. That
led to MNG-6135. That should be implemented now. I had to update an IT
when plugin resolution (as dependency) started to work. I could revert
that update since they are now resolved as projects.

> Everything is built some time then used.
> If there are some unexpected discrepencies, we have an issue.

See above. This is how things have been implemented for years. I am not
the author.

> 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

What is broken? The number of failing ITs is down to one already. How
many commits did it take to get the ANSI colors going?

FAILURE (3.5 s)

I am looking into this one right now.


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

View raw message