Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit : > 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. you're just missing "by default": if you need a branch build job, we can add it and you can even be added as Jenkins admin to do it yourself
> I can continue to use my machine during Jenkins doing it's job. you *must* do it, particularly if you're working on master > Running > the ITs locally means my machine is unuseable for nearly an hour. yes, working on Maven core is hard > 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. wrong process, particularly when you're working on core master and on changing key features like dependency and plugins management > 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. the requirements you describe are requirements for a branch > > > 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) ok, we're starting to have an explanation the initial facts: thank you > > 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. that's the risky job: changing key Maven core feature => require a lot of explanation for everybody before changing it on master And a choice on when to include such breaking change > 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. "I'm not the author": wrong conclusion right conclusion is: "change with extreme care, because even if your intentions are the best, such change will bite a lot of users" > > > 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? remember we have thousands or millions of users: the change will make a lot of builds fail > The number of failing ITs is down to one already. How > many commits did it take to get the ANSI colors going? adding a new feature that don't change existing builds is far easier beast: and even then, notice I did branches when some changes could cause issues. Sometimes, even if we can continue CTR on master, doing RTC through a branch is the way to go: it takes more time but improves team decision process > > mng5771CoreExtensions(CoreExtensionRetrievedFromAMirrorWithBasicAuthenticati > on) FAILURE (3.5 s) > > I am looking into this one right now. > > Regards, As a conclusion: you're working on changing dependencies and plugin management, which is the most difficult and risky part of Maven changes, that has a lot of impact on every user (Maven developers being only the first level of users) Then this require extreme caution that you missed at the moment I want to be supportive of such changes, but that will require other working methods for the whole Maven team to be able to explain to ouor end users why *we* changed something that breaks existing builds On the short term, I think that everything can't go into Maven 3.4.0 but will have to be explained,documented and included in a future version: perhaps Robert's idea on rewinding to a past state to rework what goes into Maven 3.4.0 and what will go in a future version will be the best solution to help us work back on a shared vision and clean codebase Don't hesitate to come on IRC also to discuss and interact in additional ways to sourcecontrol or email after having changed hard things Regards, Hervé --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
