How can the super pom be explicitly added to the project's 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
