For windows? Am I punished ? Bouhhh
Le lun. 19 déc. 2016 à 15:17, Stephen Connolly < [email protected]> 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 builds working will be "fun"... perhaps Arnaud can assist! > > > > On 19 December 2016 at 09:41, Stephen Connolly < > > [email protected]> wrote: > > > > > 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(CoreExtensionRetrievedFromAMir > > >> rorWithBasicAuthentication) > > >> > > >> 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 > > > > >
