Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-11 um 22:30 schrieb Michael Osipov: Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Folks, this one is still lingering. Are we good to merge now after clearing out doubts? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Le mardi 16 mai 2017, 22:20:35 CEST Stephen Connolly a écrit : > On Tue 16 May 2017 at 22:40, Hervé BOUTEMYwrote: > > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit : > > > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY > > > > wrote: > > > > thank you Robert: this is exactly the logic I was looking for, and > > > > explanation > > > > of changes over time to improve user experience through > > > > reproducibility. > > > > > > Now the question is: should we change default plugin versions in Maven > > > > core? > > > > Does it improve Maven or not? > > > > > > I think we should. > > > > > > If we don't update, we have a more complex ux for new users. > > > > > > We already say to pin versions (iirc we even log warnings) > > > > > > If people choose to ignore the warnings of a build being at risk of > > > differential behaviour... they get what they configured: differential > > > > builds > > > > > > To me, changing default plugin versions lowers reproducibility. > > > > > > Which is why we warn users... and the warning is there *to allow us to > > > upgrade* > > > > no, for these default plugin bindings, there is no warning, since the > > default > > binding defines a default version: that's the magic that happens with > > minimal > > poms. > > > > The warning happens only when a new plugin is used without version. > > Hmmm then that must have changed at some time because I am 99% certain that > at some point in time there was a warning of plugins in the default > lifecycle did not have a version specified... > > But I recall at some point I lost the ability in the versions-m-p to detect > that "normally" on the 3.x line (perhaps from 3.1.x onwards... I cannot > recall) as Robert explained, reproducibility was introduced in 2.0.9 (see MNG-3395, and the mecanism changed later to not be in super pom but in bindings): this removed the warning just create a minimal pom with just groupId/artifactId/version and you'll see: no warning > > I think we should restore those warnings then. that's the whole complexity of ux: should we warn new users creating minimal poms? if not, when to warn them that minimal poms are just a fast track, that should rapidly be enhanced through a parent pom or an import? Regards, Hervé > > > Then no, I don't see what "more complex ux" is there for new users. > > This upgrade of default lifecycle plugin version looks to me just a big > > misunderstanding on the expected benefit (or loss IMHO) > > > > > > And it does not help users learn that they should define their own > > > > plugin > > > > > > versions instead of depending on the magic defaults that have to be > > > > included > > > > in Maven core to permit basic poms. > > > > > > This sounds like an argument that we should add a CLI flag turn > > > downgrade > > > the current warnings back to warnings and escalate them up to errors by > > > default. > > > > > > > Then in general, if we have found a bug in a plugin with default > > > > version > > > > > > that > > > > hits users using this default basic poms, we should update the > > > > version: > > > > good > > > > default behaviour requirement surpasses reproducibility over Maven > > > > version > > > > > > expectation. > > > > > > > > But if a plugin default version upgrade is just to have newer > > > > defaults, > > > > IMHO, > > > > we sacrifice reproducibility and teaching to users that basic poms are > > > > just a > > > > quick start but should soon be extended to manage explicitely plugins > > > > versions: is there a good reason to sacrifice this? I don't find any > > > > good > > > > > > reason: the sooner user discovers that he's using old plugins, the > > > > better. > > > > > > What we should give him are easy to discover and learn recipes to > > > > manage > > > > > > his > > > > plugin versions: for example through a basic neutral parent pom with > > > > newest > > > > plugins, or a BOM pom. Maybe there are other ideas. > > > > Yes, neutral parent pom or BOM pom are to me good ways to improve > > > > Maven > > > > for > > > > users: not changing default plugin versions in Maven core. > > > > > > > > Do I miss an aspect that should be taken into account? > > > > > > I've been through this path with Jenkins. My considered opinion is it is > > > better to just upgrade. We provide a path to lock down versions. We have > > > warned users for ages. > > > > no, definitely not on default plugin bindings: this is a magic that not > > many > > people understand, and I don't think upgrading default version will > > improve > > this understanding. > > Well if the warning was lost then yes, we would first need to restore the > warning... then we can move to start upgrading again. > > > > An alternative could be to leverage the prerequisites value as a > > > selector > > > of the version defaults... though that would be re-enabling it for > > > non-plugin packaging ;-) > > >
Re: [MNG-6169] Lifecycle/binding plugin version updates
On Tue 16 May 2017 at 22:40, Hervé BOUTEMYwrote: > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit : > > On Sun 14 May 2017 at 08:51, Hervé BOUTEMY > wrote: > > > thank you Robert: this is exactly the logic I was looking for, and > > > explanation > > > of changes over time to improve user experience through > reproducibility. > > > > > > Now the question is: should we change default plugin versions in Maven > > > core? > > > Does it improve Maven or not? > > > > I think we should. > > > > If we don't update, we have a more complex ux for new users. > > > > We already say to pin versions (iirc we even log warnings) > > > > If people choose to ignore the warnings of a build being at risk of > > differential behaviour... they get what they configured: differential > builds > > > To me, changing default plugin versions lowers reproducibility. > > > > Which is why we warn users... and the warning is there *to allow us to > > upgrade* > > > no, for these default plugin bindings, there is no warning, since the > default > binding defines a default version: that's the magic that happens with > minimal > poms. > > The warning happens only when a new plugin is used without version. > Hmmm then that must have changed at some time because I am 99% certain that at some point in time there was a warning of plugins in the default lifecycle did not have a version specified... But I recall at some point I lost the ability in the versions-m-p to detect that "normally" on the 3.x line (perhaps from 3.1.x onwards... I cannot recall) I think we should restore those warnings then. > Then no, I don't see what "more complex ux" is there for new users. > This upgrade of default lifecycle plugin version looks to me just a big > misunderstanding on the expected benefit (or loss IMHO) > > > > And it does not help users learn that they should define their own > plugin > > > versions instead of depending on the magic defaults that have to be > > > included > > > in Maven core to permit basic poms. > > > > This sounds like an argument that we should add a CLI flag turn downgrade > > the current warnings back to warnings and escalate them up to errors by > > default. > > > > > Then in general, if we have found a bug in a plugin with default > version > > > that > > > hits users using this default basic poms, we should update the version: > > > good > > > default behaviour requirement surpasses reproducibility over Maven > version > > > expectation. > > > > > > But if a plugin default version upgrade is just to have newer defaults, > > > IMHO, > > > we sacrifice reproducibility and teaching to users that basic poms are > > > just a > > > quick start but should soon be extended to manage explicitely plugins > > > versions: is there a good reason to sacrifice this? I don't find any > good > > > reason: the sooner user discovers that he's using old plugins, the > better. > > > > > > What we should give him are easy to discover and learn recipes to > manage > > > his > > > plugin versions: for example through a basic neutral parent pom with > > > newest > > > plugins, or a BOM pom. Maybe there are other ideas. > > > Yes, neutral parent pom or BOM pom are to me good ways to improve Maven > > > for > > > users: not changing default plugin versions in Maven core. > > > > > > Do I miss an aspect that should be taken into account? > > > > I've been through this path with Jenkins. My considered opinion is it is > > better to just upgrade. We provide a path to lock down versions. We have > > warned users for ages. > no, definitely not on default plugin bindings: this is a magic that not > many > people understand, and I don't think upgrading default version will improve > this understanding. > Well if the warning was lost then yes, we would first need to restore the warning... then we can move to start upgrading again. > > > > An alternative could be to leverage the prerequisites value as a selector > > of the version defaults... though that would be re-enabling it for > > non-plugin packaging ;-) > yes, this could be a solution: that would give a meaning to this > prerequisites > field in case of non-plugin packaging. > But it would be more complex than just providing a parent pom, or an import > pom Yes... and we've just told everyone to stop using it... but I do see it as a good solution. > > Regards, > > Hervé > > > > > > Regards, > > > > > > Hervé > > > > > > Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit : > > > > >> If you are saying that depending on default version is a bad > practice > > > > > > it > > > > > > > >> actually means to me that this should change in the new major. > > > > >> Shouldn't it? > > > > > > > > > > this is a bad practice from a very long time, even in the Maven 2.x > > > > > time: what > > > > > should change more in next Maven version that would show it more, > > > > > > without > > > > > > > > breaking the magic that these
Re: [MNG-6169] Lifecycle/binding plugin version updates
Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit : > On Sun 14 May 2017 at 08:51, Hervé BOUTEMYwrote: > > thank you Robert: this is exactly the logic I was looking for, and > > explanation > > of changes over time to improve user experience through reproducibility. > > > > Now the question is: should we change default plugin versions in Maven > > core? > > Does it improve Maven or not? > > I think we should. > > If we don't update, we have a more complex ux for new users. > > We already say to pin versions (iirc we even log warnings) > > If people choose to ignore the warnings of a build being at risk of > differential behaviour... they get what they configured: differential builds > > To me, changing default plugin versions lowers reproducibility. > > Which is why we warn users... and the warning is there *to allow us to > upgrade* > no, for these default plugin bindings, there is no warning, since the default binding defines a default version: that's the magic that happens with minimal poms. The warning happens only when a new plugin is used without version. Then no, I don't see what "more complex ux" is there for new users. This upgrade of default lifecycle plugin version looks to me just a big misunderstanding on the expected benefit (or loss IMHO) > > And it does not help users learn that they should define their own plugin > > versions instead of depending on the magic defaults that have to be > > included > > in Maven core to permit basic poms. > > This sounds like an argument that we should add a CLI flag turn downgrade > the current warnings back to warnings and escalate them up to errors by > default. > > > Then in general, if we have found a bug in a plugin with default version > > that > > hits users using this default basic poms, we should update the version: > > good > > default behaviour requirement surpasses reproducibility over Maven version > > expectation. > > > > But if a plugin default version upgrade is just to have newer defaults, > > IMHO, > > we sacrifice reproducibility and teaching to users that basic poms are > > just a > > quick start but should soon be extended to manage explicitely plugins > > versions: is there a good reason to sacrifice this? I don't find any good > > reason: the sooner user discovers that he's using old plugins, the better. > > > > What we should give him are easy to discover and learn recipes to manage > > his > > plugin versions: for example through a basic neutral parent pom with > > newest > > plugins, or a BOM pom. Maybe there are other ideas. > > Yes, neutral parent pom or BOM pom are to me good ways to improve Maven > > for > > users: not changing default plugin versions in Maven core. > > > > Do I miss an aspect that should be taken into account? > > I've been through this path with Jenkins. My considered opinion is it is > better to just upgrade. We provide a path to lock down versions. We have > warned users for ages. no, definitely not on default plugin bindings: this is a magic that not many people understand, and I don't think upgrading default version will improve this understanding. > > An alternative could be to leverage the prerequisites value as a selector > of the version defaults... though that would be re-enabling it for > non-plugin packaging ;-) yes, this could be a solution: that would give a meaning to this prerequisites field in case of non-plugin packaging. But it would be more complex than just providing a parent pom, or an import pom Regards, Hervé > > > Regards, > > > > Hervé > > > > Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit : > > > >> If you are saying that depending on default version is a bad practice > > > > it > > > > > >> actually means to me that this should change in the new major. > > > >> Shouldn't it? > > > > > > > > this is a bad practice from a very long time, even in the Maven 2.x > > > > time: what > > > > should change more in next Maven version that would show it more, > > > > without > > > > > > breaking the magic that these defaults are used to? A warning message > > > > proposing to add pluginManagement corresponding to current Maven > > > > version > > > > > > used? > > > > Or propose a parent pom to add? > > > > > > IIRC up until Maven 2.0.8 there were no default plugin version, it was > > > always selecting the latest when not specified. This was bad, because a > > > new release of a plugin could suddenly make projects fail. > > > Since Maven 2.0.9 there we started specifying default values to make > > > everything more predictable. > > > Right now we're also moving these information to the matching > > > packaging-plugin, so the maven-jar-plugins specifies the > > > > lifecycle-plugins > > > > > and their versions. > > > So in the end we should only specify the packaging-plugins in Maven > > > core. > > > Ideally these should not be part of maven-core, but that will it harder > > > > to > > > > > start
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-15 um 09:20 schrieb Stephen Connolly: On Sun 14 May 2017 at 08:51, Hervé BOUTEMYwrote: thank you Robert: this is exactly the logic I was looking for, and explanation of changes over time to improve user experience through reproducibility. Now the question is: should we change default plugin versions in Maven core? Does it improve Maven or not? I think we should. If we don't update, we have a more complex ux for new users. We already say to pin versions (iirc we even log warnings) If people choose to ignore the warnings of a build being at risk of differential behaviour... they get what they configured: differential builds To me, changing default plugin versions lowers reproducibility. Which is why we warn users... and the warning is there *to allow us to upgrade* And it does not help users learn that they should define their own plugin versions instead of depending on the magic defaults that have to be included in Maven core to permit basic poms. We do not have two opposite opinions on this. What now, what to do with the branch? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
On Sun 14 May 2017 at 08:51, Hervé BOUTEMYwrote: > thank you Robert: this is exactly the logic I was looking for, and > explanation > of changes over time to improve user experience through reproducibility. > > Now the question is: should we change default plugin versions in Maven > core? > Does it improve Maven or not? I think we should. If we don't update, we have a more complex ux for new users. We already say to pin versions (iirc we even log warnings) If people choose to ignore the warnings of a build being at risk of differential behaviour... they get what they configured: differential builds > > To me, changing default plugin versions lowers reproducibility. Which is why we warn users... and the warning is there *to allow us to upgrade* > And it does not help users learn that they should define their own plugin > versions instead of depending on the magic defaults that have to be > included > in Maven core to permit basic poms. This sounds like an argument that we should add a CLI flag turn downgrade the current warnings back to warnings and escalate them up to errors by default. > > Then in general, if we have found a bug in a plugin with default version > that > hits users using this default basic poms, we should update the version: > good > default behaviour requirement surpasses reproducibility over Maven version > expectation. > > But if a plugin default version upgrade is just to have newer defaults, > IMHO, > we sacrifice reproducibility and teaching to users that basic poms are > just a > quick start but should soon be extended to manage explicitely plugins > versions: is there a good reason to sacrifice this? I don't find any good > reason: the sooner user discovers that he's using old plugins, the better. > > What we should give him are easy to discover and learn recipes to manage > his > plugin versions: for example through a basic neutral parent pom with newest > plugins, or a BOM pom. Maybe there are other ideas. > Yes, neutral parent pom or BOM pom are to me good ways to improve Maven for > users: not changing default plugin versions in Maven core. > > Do I miss an aspect that should be taken into account? I've been through this path with Jenkins. My considered opinion is it is better to just upgrade. We provide a path to lock down versions. We have warned users for ages. An alternative could be to leverage the prerequisites value as a selector of the version defaults... though that would be re-enabling it for non-plugin packaging ;-) > > Regards, > > Hervé > > Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit : > > >> If you are saying that depending on default version is a bad practice > it > > >> actually means to me that this should change in the new major. > > >> Shouldn't it? > > > > > > this is a bad practice from a very long time, even in the Maven 2.x > > > time: what > > > should change more in next Maven version that would show it more, > without > > > breaking the magic that these defaults are used to? A warning message > > > proposing to add pluginManagement corresponding to current Maven > version > > > used? > > > Or propose a parent pom to add? > > > > IIRC up until Maven 2.0.8 there were no default plugin version, it was > > always selecting the latest when not specified. This was bad, because a > > new release of a plugin could suddenly make projects fail. > > Since Maven 2.0.9 there we started specifying default values to make > > everything more predictable. > > Right now we're also moving these information to the matching > > packaging-plugin, so the maven-jar-plugins specifies the > lifecycle-plugins > > and their versions. > > So in the end we should only specify the packaging-plugins in Maven core. > > Ideally these should not be part of maven-core, but that will it harder > to > > start using Maven. For that reason it will be likely that some plugins > > will still need to be specified with the Maven distribution. > > > > Robert > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-14 um 09:33 schrieb Hervé BOUTEMY: I don't understand what changed in Maven 3.1.0-alpha-1 that changed the behaviour: did you find which issue was fixed? Unfortunately not. Issue titles weren't helpful, commit messages also. I assume this is an Aether update. Adding a pointer to that issue as comment (and not only in git commit message) would be useful before merging so that this change is understood when reading the code Did update JIRA issues. I will go ahead and merge the commit. Regards, Hervé Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit : I need to have a closer look at it through the Maven versions. Tackled it. Any objections to merge 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
thank you Robert: this is exactly the logic I was looking for, and explanation of changes over time to improve user experience through reproducibility. Now the question is: should we change default plugin versions in Maven core? Does it improve Maven or not? To me, changing default plugin versions lowers reproducibility. And it does not help users learn that they should define their own plugin versions instead of depending on the magic defaults that have to be included in Maven core to permit basic poms. Then in general, if we have found a bug in a plugin with default version that hits users using this default basic poms, we should update the version: good default behaviour requirement surpasses reproducibility over Maven version expectation. But if a plugin default version upgrade is just to have newer defaults, IMHO, we sacrifice reproducibility and teaching to users that basic poms are just a quick start but should soon be extended to manage explicitely plugins versions: is there a good reason to sacrifice this? I don't find any good reason: the sooner user discovers that he's using old plugins, the better. What we should give him are easy to discover and learn recipes to manage his plugin versions: for example through a basic neutral parent pom with newest plugins, or a BOM pom. Maybe there are other ideas. Yes, neutral parent pom or BOM pom are to me good ways to improve Maven for users: not changing default plugin versions in Maven core. Do I miss an aspect that should be taken into account? Regards, Hervé Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit : > >> If you are saying that depending on default version is a bad practice it > >> actually means to me that this should change in the new major. > >> Shouldn't it? > > > > this is a bad practice from a very long time, even in the Maven 2.x > > time: what > > should change more in next Maven version that would show it more, without > > breaking the magic that these defaults are used to? A warning message > > proposing to add pluginManagement corresponding to current Maven version > > used? > > Or propose a parent pom to add? > > IIRC up until Maven 2.0.8 there were no default plugin version, it was > always selecting the latest when not specified. This was bad, because a > new release of a plugin could suddenly make projects fail. > Since Maven 2.0.9 there we started specifying default values to make > everything more predictable. > Right now we're also moving these information to the matching > packaging-plugin, so the maven-jar-plugins specifies the lifecycle-plugins > and their versions. > So in the end we should only specify the packaging-plugins in Maven core. > Ideally these should not be part of maven-core, but that will it harder to > start using Maven. For that reason it will be likely that some plugins > will still need to be specified with the Maven distribution. > > Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
I don't understand what changed in Maven 3.1.0-alpha-1 that changed the behaviour: did you find which issue was fixed? Adding a pointer to that issue as comment (and not only in git commit message) would be useful before merging so that this change is understood when reading the code thanks for digging into this Regards, Hervé Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit : > > I need to have a closer look at it through the Maven versions. > > Tackled it. Any objections to merge > 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs? > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-13 um 23:39 schrieb Michael Osipov: Am 2017-05-13 um 22:38 schrieb Hervé BOUTEMY: Le samedi 13 mai 2017, 00:58:45 CEST Michael Osipov a écrit : Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through. beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96ca c95545e8568acd044b6d7dc ok, just tested with Maven 3.0.5: this does not add more failures (notice that existing failures show we already did some mistakes in the past regarding some updated ITs...) I reran Maven 3.5.0, 3.3.9 on Core ITs master on two operating systems. Both pass. Then I ran 3.0.5, it fails just like you noticed. Except one failure, this is due to the embedded mode. Several ITs are not wellsuited for embedded mode (single VM). The single in 3.0.5 is in MavenITmng0947OptionalDependencyTest. You might remember that I have done recently some improvements to "optional" in Core as well es to Core IT Support plugins: MNG-6229. It now payed off. The optional flag was missing on the dep tree output, so the test was impcomplete. Now, an issue has been detected in 3.0.5 or the IT itself: Actual: [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\compile.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 [INFO] [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:runtime (test) @ consumer --- [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\runtime.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:c:jar:0.1 [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 [INFO] [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:test (test) @ consumer --- [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\test.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:c:jar:0.1 [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 Expected: List compile = verifier.loadLines( "target/compile.txt", "UTF-8" ); assertTrue( compile.toString(), compile.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( compile.toString(), compile.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 2, compile.size() ); List runtime = verifier.loadLines( "target/runtime.txt", "UTF-8" ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:c:jar:0.1" ) ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 3, runtime.size() ); List test = verifier.loadLines( "target/test.txt", "UTF-8" ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:c:jar:0.1" ) ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 3, test.size() ); I need to have a closer look at it through the Maven versions. Tackled it. Any objections to merge 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-13 um 22:38 schrieb Hervé BOUTEMY: Le samedi 13 mai 2017, 00:58:45 CEST Michael Osipov a écrit : Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through. beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96ca c95545e8568acd044b6d7dc ok, just tested with Maven 3.0.5: this does not add more failures (notice that existing failures show we already did some mistakes in the past regarding some updated ITs...) I reran Maven 3.5.0, 3.3.9 on Core ITs master on two operating systems. Both pass. Then I ran 3.0.5, it fails just like you noticed. Except one failure, this is due to the embedded mode. Several ITs are not wellsuited for embedded mode (single VM). The single in 3.0.5 is in MavenITmng0947OptionalDependencyTest. You might remember that I have done recently some improvements to "optional" in Core as well es to Core IT Support plugins: MNG-6229. It now payed off. The optional flag was missing on the dep tree output, so the test was impcomplete. Now, an issue has been detected in 3.0.5 or the IT itself: Actual: [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\compile.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 [INFO] [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:runtime (test) @ consumer --- [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\runtime.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:c:jar:0.1 [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 [INFO] [INFO] --- maven-it-plugin-dependency-resolution:2.1-SNAPSHOT:test (test) @ consumer --- [INFO] [MAVEN-CORE-IT-LOG] Dumping artifact list: D:\Entwicklung\Projekte\maven-integration-testing\core-it-suite\target\test-classes\mng-0947\target\test.txt [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:c:jar:0.1 [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:e:jar:0.1 (optional) [INFO] [MAVEN-CORE-IT-LOG] org.apache.maven.its.mng0947:d:jar:0.1 Expected: List compile = verifier.loadLines( "target/compile.txt", "UTF-8" ); assertTrue( compile.toString(), compile.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( compile.toString(), compile.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 2, compile.size() ); List runtime = verifier.loadLines( "target/runtime.txt", "UTF-8" ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:c:jar:0.1" ) ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( runtime.toString(), runtime.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 3, runtime.size() ); List test = verifier.loadLines( "target/test.txt", "UTF-8" ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:c:jar:0.1" ) ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:d:jar:0.1 (optional)" ) ); assertTrue( test.toString(), test.contains( "org.apache.maven.its.mng0947:e:jar:0.1 (optional)" ) ); assertEquals( 3, test.size() ); I need to have a closer look at it through the Maven versions. that's why I don't like changing default plugins versions: 1. depending on default plugins versions is a bad practice: IMHO, having old plugins helps people know that they should not rely on it This basically means that people would need to provide versions explicitly in the POMs starting with Maven 4. ??? Why are you talking about Maven 4? If you are saying that depending on default version is a bad practice it actually means to me that this should change in the new major. Shouldn't it? this is a bad practice from a very long time, even in the Maven 2.x time: what should change more in next Maven version that would show it more, without breaking the magic that these defaults are used to? A warning message proposing to add pluginManagement corresponding to current Maven version used? Or propose a parent pom to add? I think a warning for < 4.0 to fix the version would be best and have it fail in 4.0 if the version of
Re: [MNG-6169] Lifecycle/binding plugin version updates
On Sat, 13 May 2017 22:38:55 +0200, Hervé BOUTEMYwrote: Le samedi 13 mai 2017, 00:58:45 CEST Michael Osipov a écrit : Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: > Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: >>> Jenkins build is not flaky: it is strict on dependency resolution from >>> cache, which is an intent, not a bug >> >> This pretty much explains why a lot of ITs fail here at work with a >> empty repo. I will to work this through. > > beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96ca c95545e8568acd044b6d7dc ok, just tested with Maven 3.0.5: this does not add more failures (notice that existing failures show we already did some mistakes in the past regarding some updated ITs...) >>> that's why I don't like changing default plugins versions: >>> >>> 1. depending on default plugins versions is a bad practice: IMHO, having >>> old plugins helps people know that they should not rely on it >> >> This basically means that people would need to provide versions >> explicitly in the POMs starting with Maven 4. > > ??? Why are you talking about Maven 4? If you are saying that depending on default version is a bad practice it actually means to me that this should change in the new major. Shouldn't it? this is a bad practice from a very long time, even in the Maven 2.x time: what should change more in next Maven version that would show it more, without breaking the magic that these defaults are used to? A warning message proposing to add pluginManagement corresponding to current Maven version used? Or propose a parent pom to add? IIRC up until Maven 2.0.8 there were no default plugin version, it was always selecting the latest when not specified. This was bad, because a new release of a plugin could suddenly make projects fail. Since Maven 2.0.9 there we started specifying default values to make everything more predictable. Right now we're also moving these information to the matching packaging-plugin, so the maven-jar-plugins specifies the lifecycle-plugins and their versions. So in the end we should only specify the packaging-plugins in Maven core. Ideally these should not be part of maven-core, but that will it harder to start using Maven. For that reason it will be likely that some plugins will still need to be specified with the Maven distribution. Robert >> Looks like a lot of >> hassle, doesn't it? I'd better see this in the Super POM rather embedded >> in a JAR. > > ??? "embedded in a JAR"? what did I say that lead to something like this? I assumed that your idea is rather nothing this up to the Super POM: ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xm the super pom is in Maven: anything in Maven won't change that default will be dependent on Maven version used, which is not good for reproducibility [...] >> Do you know completely reject the issue to be merged? > > I'd like to have us understand each other: > - what do you expect to win? > - what do we loose? > I know doing this update is easy to do and corresponds to a lot of good > intentions on giving latest of everything for lazy users: but the > consequences are IMHO not so positive and are for the moment > misunderstood/ignored My position is not definitive, the discussion on > evaluating with multiple many eyes if this change is really good or not, > and goot at what, will make my final opinion on this: but sure, for the > moment, I'm not convinced this update goes in a good direction It wasn't easy. I invested quite some time to make all ITs pass. yes, changing the versions in Maven is easy, but updating ITs and checking that everything works better is harder: once again, I don't see the value to updating these default values, since people should define their own plugins versions in their pom. But I see value of having the same plugins versions in every Maven 3.x release, to have some de-facto reproducibility. Some plugins weren't even updated because they cause regressions in ITs which I still haven't investigated yet. Some even cause zlib failures in native code (known JVM issue due to bad code). uh! Regards, Hervé >> Michael >> >>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail:
Re: [MNG-6169] Lifecycle/binding plugin version updates
Le samedi 13 mai 2017, 00:58:45 CEST Michael Osipov a écrit : > Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: > > Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : > >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: > >>> Jenkins build is not flaky: it is strict on dependency resolution from > >>> cache, which is an intent, not a bug > >> > >> This pretty much explains why a lot of ITs fail here at work with a > >> empty repo. I will to work this through. > > > > beware to not make the ITs fail with previous Maven versions > > All I did is this: > https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96ca > c95545e8568acd044b6d7dc ok, just tested with Maven 3.0.5: this does not add more failures (notice that existing failures show we already did some mistakes in the past regarding some updated ITs...) > >>> that's why I don't like changing default plugins versions: > >>> > >>> 1. depending on default plugins versions is a bad practice: IMHO, having > >>> old plugins helps people know that they should not rely on it > >> > >> This basically means that people would need to provide versions > >> explicitly in the POMs starting with Maven 4. > > > > ??? Why are you talking about Maven 4? > > If you are saying that depending on default version is a bad practice it > actually means to me that this should change in the new major. Shouldn't it? this is a bad practice from a very long time, even in the Maven 2.x time: what should change more in next Maven version that would show it more, without breaking the magic that these defaults are used to? A warning message proposing to add pluginManagement corresponding to current Maven version used? Or propose a parent pom to add? > >> Looks like a lot of > >> hassle, doesn't it? I'd better see this in the Super POM rather embedded > >> in a JAR. > > > > ??? "embedded in a JAR"? what did I say that lead to something like this? > > I assumed that your idea is rather nothing this up to the Super POM: > ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xm the super pom is in Maven: anything in Maven won't change that default will be dependent on Maven version used, which is not good for reproducibility [...] > >> Do you know completely reject the issue to be merged? > > > > I'd like to have us understand each other: > > - what do you expect to win? > > - what do we loose? > > I know doing this update is easy to do and corresponds to a lot of good > > intentions on giving latest of everything for lazy users: but the > > consequences are IMHO not so positive and are for the moment > > misunderstood/ignored My position is not definitive, the discussion on > > evaluating with multiple many eyes if this change is really good or not, > > and goot at what, will make my final opinion on this: but sure, for the > > moment, I'm not convinced this update goes in a good direction > > It wasn't easy. I invested quite some time to make all ITs pass. yes, changing the versions in Maven is easy, but updating ITs and checking that everything works better is harder: once again, I don't see the value to updating these default values, since people should define their own plugins versions in their pom. But I see value of having the same plugins versions in every Maven 3.x release, to have some de-facto reproducibility. > Some > plugins weren't even updated because they cause regressions in ITs which > I still haven't investigated yet. Some even cause zlib failures in > native code (known JVM issue due to bad code). uh! Regards, Hervé > > >> Michael > >> > >>> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : > Who seconds MNG-6169 for 3.5.1? I have a fully working branch > (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 > and FreeBSD 10.3-RELEASE. > > Jenkins build is flaky with notorious file://target/null artifact not > found. > > Some bindings haven't been updated because they cause several ITs to > fail (regressions). I will report them separately. > > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [MNG-6169] Lifecycle/binding plugin version updates
Good Morning Michael any timeline on pom.xml creation for tomcat source distros? i d/l 8.5.4 https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.4/src/ and i see only 1 pom.xml for jdbc-pool but I see 3 build.xml find . name build.xml ./modules/jdbc-pool/build.xml ./res/deployer/build.xml ./webapps/ROOT/build.xml for each attempt to track down a TC problem i am forced to create pom.xml from scratch so I can build, package and deploy the war to locate the problem I of course will help you *behind the scenes* for any assistance you may require thanks, Martin __ "why do you help the british?..in 1812 they burned your capitol"..The Great Escape From: Michael Osipov <micha...@apache.org> Sent: Friday, May 12, 2017 6:58 PM To: Maven Developers List Subject: Re: [MNG-6169] Lifecycle/binding plugin version updates Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: > Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: >>> Jenkins build is not flaky: it is strict on dependency resolution from >>> cache, which is an intent, not a bug >> >> This pretty much explains why a lot of ITs fail here at work with a >> empty repo. I will to work this through. > beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc [https://avatars3.githubusercontent.com/u/573017?v=3=200]<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc> [MNG-6169] Lifecycle/binding plugin version updates · apache/maven-integration-testing@5c01864<https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc> github.com MNG-5895 and MNG-6090 with ArtifactResolutionException. Add dependencies Maven Resources Plugin 3.0.2 and Maven Surefire 2.2.0 to bootstrap's group 7. >> >>> that's why I don't like changing default plugins versions: >>> >>> 1. depending on default plugins versions is a bad practice: IMHO, having >>> old plugins helps people know that they should not rely on it >> >> This basically means that people would need to provide versions >> explicitly in the POMs starting with Maven 4. > ??? Why are you talking about Maven 4? If you are saying that depending on default version is a bad practice it actually means to me that this should change in the new major. Shouldn't it? >> Looks like a lot of >> hassle, doesn't it? I'd better see this in the Super POM rather embedded >> in a JAR. > ??? "embedded in a JAR"? what did I say that lead to something like this? I assumed that your idea is rather nothing this up to the Super POM: ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml >>> 2. people who do a "dependency:go-offline" with a previous Maven version >>> but run offline with updated Maven version will see their build fail and >>> report about dependency:go-offline not being reliable, which is >>> technically not true, but is sensitive to Maven version (something that >>> is hard to explain) >> >> Pretty good point. We should actually ad this information to the goal >> doc. This will also fail if your change your POM. >> >>> On the first objection, it's a question of choice on how to promote the >>> good practice about explicitely choosing your plugins versions >>> >>> On the second objection, I had an idea of Maven core improvement that >>> would fix the go-offline dependency on Maven version used: what if Maven >>> core distribution did contain a (read-only) local repo with default >>> plugins already resolved? >>> >>> With such a feature, go-offline would not be dependant on Maven version >>> used (starting from the Maven version that has this pre-built repo). And >>> user would better see the default dependencies by looking at this >>> pre-builot repo = something I'm sure they will do (but they don't have a >>> look at lifecycle definition files, which are opaque for them) >>> >>> I didn't have time to work on implementing this idea, I suppose this would >>> just require a new default repository with file://${maven.home}/default- >>> plugins/ url, and to fill this repo at build time with appropriate >>> go-offline >> Sounds like a good idea but would produce a lot of bloat, wouldn't it? > what do you call "bloat"? and what do you call "a lot"? Is it better to > download plugin artifacts from network instea
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-13 um 00:30 schrieb Hervé BOUTEMY: Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through. beware to not make the ITs fail with previous Maven versions All I did is this: https://github.com/apache/maven-integration-testing/commit/5c01864e44c7c96cac95545e8568acd044b6d7dc that's why I don't like changing default plugins versions: 1. depending on default plugins versions is a bad practice: IMHO, having old plugins helps people know that they should not rely on it This basically means that people would need to provide versions explicitly in the POMs starting with Maven 4. ??? Why are you talking about Maven 4? If you are saying that depending on default version is a bad practice it actually means to me that this should change in the new major. Shouldn't it? Looks like a lot of hassle, doesn't it? I'd better see this in the Super POM rather embedded in a JAR. ??? "embedded in a JAR"? what did I say that lead to something like this? I assumed that your idea is rather nothing this up to the Super POM: ./maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml 2. people who do a "dependency:go-offline" with a previous Maven version but run offline with updated Maven version will see their build fail and report about dependency:go-offline not being reliable, which is technically not true, but is sensitive to Maven version (something that is hard to explain) Pretty good point. We should actually ad this information to the goal doc. This will also fail if your change your POM. On the first objection, it's a question of choice on how to promote the good practice about explicitely choosing your plugins versions On the second objection, I had an idea of Maven core improvement that would fix the go-offline dependency on Maven version used: what if Maven core distribution did contain a (read-only) local repo with default plugins already resolved? With such a feature, go-offline would not be dependant on Maven version used (starting from the Maven version that has this pre-built repo). And user would better see the default dependencies by looking at this pre-builot repo = something I'm sure they will do (but they don't have a look at lifecycle definition files, which are opaque for them) I didn't have time to work on implementing this idea, I suppose this would just require a new default repository with file://${maven.home}/default- plugins/ url, and to fill this repo at build time with appropriate go-offline Sounds like a good idea but would produce a lot of bloat, wouldn't it? what do you call "bloat"? and what do you call "a lot"? Is it better to download plugin artifacts from network instead? All plugin dependency trees. This should be configurable in settings.xml and MDEP should provide a goal to populate such a repo. I am afraid that no one will pick this up anytime soon. Do you know completely reject the issue to be merged? I'd like to have us understand each other: - what do you expect to win? - what do we loose? I know doing this update is easy to do and corresponds to a lot of good intentions on giving latest of everything for lazy users: but the consequences are IMHO not so positive and are for the moment misunderstood/ignored My position is not definitive, the discussion on evaluating with multiple many eyes if this change is really good or not, and goot at what, will make my final opinion on this: but sure, for the moment, I'm not convinced this update goes in a good direction It wasn't easy. I invested quite some time to make all ITs pass. Some plugins weren't even updated because they cause regressions in ITs which I still haven't investigated yet. Some even cause zlib failures in native code (known JVM issue due to bad code). Michael Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
Re: [MNG-6169] Lifecycle/binding plugin version updates
Le vendredi 12 mai 2017, 13:50:37 CEST Michael Osipov a écrit : > Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: > > Jenkins build is not flaky: it is strict on dependency resolution from > > cache, which is an intent, not a bug > > This pretty much explains why a lot of ITs fail here at work with a > empty repo. I will to work this through. beware to not make the ITs fail with previous Maven versions > > > that's why I don't like changing default plugins versions: > > > > 1. depending on default plugins versions is a bad practice: IMHO, having > > old plugins helps people know that they should not rely on it > > This basically means that people would need to provide versions > explicitly in the POMs starting with Maven 4. ??? Why are you talking about Maven 4? > Looks like a lot of > hassle, doesn't it? I'd better see this in the Super POM rather embedded > in a JAR. ??? "embedded in a JAR"? what did I say that lead to something like this? > > > 2. people who do a "dependency:go-offline" with a previous Maven version > > but run offline with updated Maven version will see their build fail and > > report about dependency:go-offline not being reliable, which is > > technically not true, but is sensitive to Maven version (something that > > is hard to explain) > > Pretty good point. We should actually ad this information to the goal > doc. This will also fail if your change your POM. > > > On the first objection, it's a question of choice on how to promote the > > good practice about explicitely choosing your plugins versions > > > > On the second objection, I had an idea of Maven core improvement that > > would fix the go-offline dependency on Maven version used: what if Maven > > core distribution did contain a (read-only) local repo with default > > plugins already resolved? > > > > With such a feature, go-offline would not be dependant on Maven version > > used (starting from the Maven version that has this pre-built repo). And > > user would better see the default dependencies by looking at this > > pre-builot repo = something I'm sure they will do (but they don't have a > > look at lifecycle definition files, which are opaque for them) > > > > I didn't have time to work on implementing this idea, I suppose this would > > just require a new default repository with file://${maven.home}/default- > > plugins/ url, and to fill this repo at build time with appropriate > > go-offline > Sounds like a good idea but would produce a lot of bloat, wouldn't it? what do you call "bloat"? and what do you call "a lot"? Is it better to download plugin artifacts from network instead? > All plugin dependency trees. This should be configurable in settings.xml > and MDEP should provide a goal to populate such a repo. > I am afraid that no one will pick this up anytime soon. > > Do you know completely reject the issue to be merged? I'd like to have us understand each other: - what do you expect to win? - what do we loose? I know doing this update is easy to do and corresponds to a lot of good intentions on giving latest of everything for lazy users: but the consequences are IMHO not so positive and are for the moment misunderstood/ignored My position is not definitive, the discussion on evaluating with multiple many eyes if this change is really good or not, and goot at what, will make my final opinion on this: but sure, for the moment, I'm not convinced this update goes in a good direction Any other view on this? Regards, Hervé > > Michael > > > Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : > >> Who seconds MNG-6169 for 3.5.1? I have a fully working branch > >> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 > >> and FreeBSD 10.3-RELEASE. > >> > >> Jenkins build is flaky with notorious file://target/null artifact not > >> found. > >> > >> Some bindings haven't been updated because they cause several ITs to > >> fail (regressions). I will report them separately. > >> > >> > >> Michael > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug Traced down last missing dependencies and added them to Bootstrap IT. Branch MNG-6169 created on the Core ITs. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-11 um 22:46 schrieb Robert Scholte: Is m-compiler-p on 3.6.1? please change to 3.5.1 until jigsaw stuff works correctly. Version has been downgraded. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Can we declare explicitly that this pom does not inherit from super pom? Chas > On May 12, 2017, at 4:50 AM, Michael Osipovwrote: > >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: >> Jenkins build is not flaky: it is strict on dependency resolution from cache, >> which is an intent, not a bug > > This pretty much explains why a lot of ITs fail here at work with a empty > repo. I will to work this through. > >> that's why I don't like changing default plugins versions: >> >> 1. depending on default plugins versions is a bad practice: IMHO, having old >> plugins helps people know that they should not rely on it > > This basically means that people would need to provide versions explicitly in > the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd > better see this in the Super POM rather embedded in a JAR. > >> 2. people who do a "dependency:go-offline" with a previous Maven version but >> run >> offline with updated Maven version will see their build fail and report about >> dependency:go-offline not being reliable, which is technically not true, but >> is >> sensitive to Maven version (something that is hard to explain) > > Pretty good point. We should actually ad this information to the goal doc. > This will also fail if your change your POM. > >> On the first objection, it's a question of choice on how to promote the good >> practice about explicitely choosing your plugins versions >> >> On the second objection, I had an idea of Maven core improvement that would >> fix >> the go-offline dependency on Maven version used: what if Maven core >> distribution >> did contain a (read-only) local repo with default plugins already resolved? >> >> With such a feature, go-offline would not be dependant on Maven version used >> (starting from the Maven version that has this pre-built repo). And user >> would >> better see the default dependencies by looking at this pre-builot repo = >> something I'm sure they will do (but they don't have a look at lifecycle >> definition files, which are opaque for them) >> >> I didn't have time to work on implementing this idea, I suppose this would >> just require a new default repository with file://${maven.home}/default- >> plugins/ url, and to fill this repo at build time with appropriate go-offline > > Sounds like a good idea but would produce a lot of bloat, wouldn't it? All > plugin dependency trees. This should be configurable in settings.xml and MDEP > should provide a goal to populate such a repo. > I am afraid that no one will pick this up anytime soon. > > Do you know completely reject the issue to be merged? > > Michael > >> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : >>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch >>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 >>> and FreeBSD 10.3-RELEASE. >>> >>> Jenkins build is flaky with notorious file://target/null artifact not found. >>> >>> Some bindings haven't been updated because they cause several ITs to >>> fail (regressions). I will report them separately. >>> >>> >>> Michael >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-12 um 19:23 schrieb Chas Honton: How can the super pom be explicitly added to the project's pom? Not necessary, the Super POM is in a JAR distributed with Maven and automatically used. On May 12, 2017, at 4:50 AM, Michael Osipovwrote: Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through. that's why I don't like changing default plugins versions: 1. depending on default plugins versions is a bad practice: IMHO, having old plugins helps people know that they should not rely on it This basically means that people would need to provide versions explicitly in the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd better see this in the Super POM rather embedded in a JAR. 2. people who do a "dependency:go-offline" with a previous Maven version but run offline with updated Maven version will see their build fail and report about dependency:go-offline not being reliable, which is technically not true, but is sensitive to Maven version (something that is hard to explain) Pretty good point. We should actually ad this information to the goal doc. This will also fail if your change your POM. On the first objection, it's a question of choice on how to promote the good practice about explicitely choosing your plugins versions On the second objection, I had an idea of Maven core improvement that would fix the go-offline dependency on Maven version used: what if Maven core distribution did contain a (read-only) local repo with default plugins already resolved? With such a feature, go-offline would not be dependant on Maven version used (starting from the Maven version that has this pre-built repo). And user would better see the default dependencies by looking at this pre-builot repo = something I'm sure they will do (but they don't have a look at lifecycle definition files, which are opaque for them) I didn't have time to work on implementing this idea, I suppose this would just require a new default repository with file://${maven.home}/default- plugins/ url, and to fill this repo at build time with appropriate go-offline Sounds like a good idea but would produce a lot of bloat, wouldn't it? All plugin dependency trees. This should be configurable in settings.xml and MDEP should provide a goal to populate such a repo. I am afraid that no one will pick this up anytime soon. Do you know completely reject the issue to be merged? Michael Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
How can the super pom be explicitly added to the project's pom? Chas > On May 12, 2017, at 4:50 AM, Michael Osipovwrote: > >> Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: >> Jenkins build is not flaky: it is strict on dependency resolution from cache, >> which is an intent, not a bug > > This pretty much explains why a lot of ITs fail here at work with a empty > repo. I will to work this through. > >> that's why I don't like changing default plugins versions: >> >> 1. depending on default plugins versions is a bad practice: IMHO, having old >> plugins helps people know that they should not rely on it > > This basically means that people would need to provide versions explicitly in > the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd > better see this in the Super POM rather embedded in a JAR. > >> 2. people who do a "dependency:go-offline" with a previous Maven version but >> run >> offline with updated Maven version will see their build fail and report about >> dependency:go-offline not being reliable, which is technically not true, but >> is >> sensitive to Maven version (something that is hard to explain) > > Pretty good point. We should actually ad this information to the goal doc. > This will also fail if your change your POM. > >> On the first objection, it's a question of choice on how to promote the good >> practice about explicitely choosing your plugins versions >> >> On the second objection, I had an idea of Maven core improvement that would >> fix >> the go-offline dependency on Maven version used: what if Maven core >> distribution >> did contain a (read-only) local repo with default plugins already resolved? >> >> With such a feature, go-offline would not be dependant on Maven version used >> (starting from the Maven version that has this pre-built repo). And user >> would >> better see the default dependencies by looking at this pre-builot repo = >> something I'm sure they will do (but they don't have a look at lifecycle >> definition files, which are opaque for them) >> >> I didn't have time to work on implementing this idea, I suppose this would >> just require a new default repository with file://${maven.home}/default- >> plugins/ url, and to fill this repo at build time with appropriate go-offline > > Sounds like a good idea but would produce a lot of bloat, wouldn't it? All > plugin dependency trees. This should be configurable in settings.xml and MDEP > should provide a goal to populate such a repo. > I am afraid that no one will pick this up anytime soon. > > Do you know completely reject the issue to be merged? > > Michael > >> Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : >>> Who seconds MNG-6169 for 3.5.1? I have a fully working branch >>> (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 >>> and FreeBSD 10.3-RELEASE. >>> >>> Jenkins build is flaky with notorious file://target/null artifact not found. >>> >>> Some bindings haven't been updated because they cause several ITs to >>> fail (regressions). I will report them separately. >>> >>> >>> Michael >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-12 um 08:25 schrieb Hervé BOUTEMY: Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug This pretty much explains why a lot of ITs fail here at work with a empty repo. I will to work this through. that's why I don't like changing default plugins versions: 1. depending on default plugins versions is a bad practice: IMHO, having old plugins helps people know that they should not rely on it This basically means that people would need to provide versions explicitly in the POMs starting with Maven 4. Looks like a lot of hassle, doesn't it? I'd better see this in the Super POM rather embedded in a JAR. 2. people who do a "dependency:go-offline" with a previous Maven version but run offline with updated Maven version will see their build fail and report about dependency:go-offline not being reliable, which is technically not true, but is sensitive to Maven version (something that is hard to explain) Pretty good point. We should actually ad this information to the goal doc. This will also fail if your change your POM. On the first objection, it's a question of choice on how to promote the good practice about explicitely choosing your plugins versions On the second objection, I had an idea of Maven core improvement that would fix the go-offline dependency on Maven version used: what if Maven core distribution did contain a (read-only) local repo with default plugins already resolved? With such a feature, go-offline would not be dependant on Maven version used (starting from the Maven version that has this pre-built repo). And user would better see the default dependencies by looking at this pre-builot repo = something I'm sure they will do (but they don't have a look at lifecycle definition files, which are opaque for them) I didn't have time to work on implementing this idea, I suppose this would just require a new default repository with file://${maven.home}/default- plugins/ url, and to fill this repo at build time with appropriate go-offline Sounds like a good idea but would produce a lot of bloat, wouldn't it? All plugin dependency trees. This should be configurable in settings.xml and MDEP should provide a goal to populate such a repo. I am afraid that no one will pick this up anytime soon. Do you know completely reject the issue to be merged? Michael Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Jenkins build is not flaky: it is strict on dependency resolution from cache, which is an intent, not a bug that's why I don't like changing default plugins versions: 1. depending on default plugins versions is a bad practice: IMHO, having old plugins helps people know that they should not rely on it 2. people who do a "dependency:go-offline" with a previous Maven version but run offline with updated Maven version will see their build fail and report about dependency:go-offline not being reliable, which is technically not true, but is sensitive to Maven version (something that is hard to explain) On the first objection, it's a question of choice on how to promote the good practice about explicitely choosing your plugins versions On the second objection, I had an idea of Maven core improvement that would fix the go-offline dependency on Maven version used: what if Maven core distribution did contain a (read-only) local repo with default plugins already resolved? With such a feature, go-offline would not be dependant on Maven version used (starting from the Maven version that has this pre-built repo). And user would better see the default dependencies by looking at this pre-builot repo = something I'm sure they will do (but they don't have a look at lifecycle definition files, which are opaque for them) I didn't have time to work on implementing this idea, I suppose this would just require a new default repository with file://${maven.home}/default- plugins/ url, and to fill this repo at build time with appropriate go-offline WDYT? Regards, Hervé Le jeudi 11 mai 2017, 22:30:43 CEST Michael Osipov a écrit : > Who seconds MNG-6169 for 3.5.1? I have a fully working branch > (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 > and FreeBSD 10.3-RELEASE. > > Jenkins build is flaky with notorious file://target/null artifact not found. > > Some bindings haven't been updated because they cause several ITs to > fail (regressions). I will report them separately. > > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Am 2017-05-11 um 22:46 schrieb Robert Scholte: Is m-compiler-p on 3.6.1? please change to 3.5.1 until jigsaw stuff works correctly. Yes, it is 3.5.1. I will downgrade to 3.5.1 shortly. Michael Oorspronkelijk bericht Van: Michael OsipovDatum:11-05-2017 22:30 (GMT+01:00) Aan: Maven Developers List Onderwerp: [MNG-6169] Lifecycle/binding plugin version updates Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MNG-6169] Lifecycle/binding plugin version updates
Is m-compiler-p on 3.6.1? please change to 3.5.1 until jigsaw stuff works correctly. Verzonden vanaf Samsung Mobile. Oorspronkelijk bericht Van: Michael OsipovDatum:11-05-2017 22:30 (GMT+01:00) Aan: Maven Developers List Onderwerp: [MNG-6169] Lifecycle/binding plugin version updates Who seconds MNG-6169 for 3.5.1? I have a fully working branch (MNG-6169_2/not-updated-MJAR-MCOMPILER) passing all ITs on Windows 10 and FreeBSD 10.3-RELEASE. Jenkins build is flaky with notorious file://target/null artifact not found. Some bindings haven't been updated because they cause several ITs to fail (regressions). I will report them separately. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org