No. my son is only in school during the AM, so you might have a chance to try some iterations to get it working sooner... we are only prodding the dark! (And I'm validating my complaints about how literate is better than jenkinsfile... but I lost that popularity contest)
Or anyone else can too (just remember until infra upgrades you need to trigger a manual indexing to pick up new branches/commits faster than once per hour) On Mon 19 Dec 2016 at 14:20, Arnaud Héritier <aherit...@gmail.com> wrote: > For windows? Am I punished ? > > > > Bouhhh > > > > Le lun. 19 déc. 2016 à 15:17, Stephen Connolly < > > stephen.alan.conno...@gmail.com> 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 < > > > > > > stephen.alan.conno...@gmail.com> 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 <c...@schulte.it> 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: dev-unsubscr...@maven.apache.org > > > > > > >> > > > > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> -- > > > > > > > Sent from my phone > > > > > > > > > > > > > > > -- Sent from my phone
