Can we declare explicitly that this pom does not inherit from super pom? Chas
> On May 12, 2017, at 4:50 AM, Michael Osipov <micha...@apache.org> wrote: > >> 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