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 >
