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 significantly reduce the impact of org-folders on API limits... we should check with infra and see if that will make it into the "usable" zone (otherwise we'll need to wait for my 2nd gen improvements...) Other than that, in the interim we can set up jobs for a "DEV" branch if that helps... we need to be keeping master releasable... the current state of master does not seem to match that expectation On Sun 18 Dec 2016 at 23:45, Christian Schulte <[email protected]> wrote: > 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 > > designed. > > > > POM > > - depdency (always selected, no matter what) > > - transitive dependency (selected only if not non-transitive) > > > > Dependency > > - 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? > > > > > mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthentication) > > FAILURE (3.5 s) > > > > I am looking into this one right now. > > > > Regards, > > -- > > Christian > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- Sent from my phone
