Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-22 Thread jieryn 
https://github.com/jieryn/maven-3.4.0-testing

On Mon, Aug 22, 2016 at 9:37 AM, jieryn  wrote:
> Sure, here is an example project boiled down to the minimum. The
> arquillian module demonstrates the problem, and it is a commonly
> recommended way by RedHat JBoss / Arquillian project to use
> scope=import for these bom dependency concentrators.
>
> After investigation, I find that several of these boms have redundant
> and mismatched dependency versions. Perhaps they ought to fix this,
> but I'm seeing huge amount of mess of messages with this common and
> recommended kind of arq configuration.
>
> Messages are of the format:
>
> [WARNING] Multiple conflicting imports of dependency
> 'org.seleniumhq.selenium:selenium-server:jar' into model
> 'com.acme:arquillian:pom:1.0-SNAPSHOT' @
> '/home/jieryn/workspaces/maven-3.4.0-testing/arquillian/pom.xml' ('42
> : 25, org.jboss.arquillian.selenium:selenium-bom:2.53.0
> /home/jieryn/.m2/repository/org/jboss/arquillian/selenium/selenium-bom/2.53.0/selenium-bom-2.53.0.pom',
> '42 : 25, org.jboss.arquillian.selenium:selenium-bom:2.53.1
> /home/jieryn/.m2/repository/org/jboss/arquillian/selenium/selenium-bom/2.53.1/selenium-bom-2.53.1.pom').
> To resolve this conflict, either declare the dependency directly in
> the dependency management of model
> 'com.acme:arquillian:pom:1.0-SNAPSHOT' to override what gets imported
> or, as of Maven 3.4, rearrange the causing imports in the inheritance
> hierarchy to apply standard override logic based on artifact
> coordinates. Without resolving this conflict, your build relies on
> indeterministic behaviour.
>
>
>
> On Sat, Aug 20, 2016 at 5:13 AM, Karl Heinz Marbaise  
> wrote:
>> Hi,
>>
>> On 20/08/16 07:05, Christian Schulte wrote:
>>>
>>> Am 08/19/16 um 21:10 schrieb jieryn:

 I am seeing a huge amount of additional warnings at the start of the
 build now, that is intentional I believe? Do we have a wiki or any
 documentation about resolving these issues? For example, I'm seeing
 this because I use Arquillian and their standard dependencyManagement
 bom scope=import style.
>>>
>>>
>>> Intentional. No release notes yet.
>>
>>
>>
>> I posted that for a longer time ago..that I started on them already..
>>
>> https://github.com/khmarbaise/maven-release-notes
>>
>> Kind regards
>> Karl Heinz
>>
>>
>> -
>> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-22 Thread jieryn 
Sure, here is an example project boiled down to the minimum. The
arquillian module demonstrates the problem, and it is a commonly
recommended way by RedHat JBoss / Arquillian project to use
scope=import for these bom dependency concentrators.

After investigation, I find that several of these boms have redundant
and mismatched dependency versions. Perhaps they ought to fix this,
but I'm seeing huge amount of mess of messages with this common and
recommended kind of arq configuration.

Messages are of the format:

[WARNING] Multiple conflicting imports of dependency
'org.seleniumhq.selenium:selenium-server:jar' into model
'com.acme:arquillian:pom:1.0-SNAPSHOT' @
'/home/jieryn/workspaces/maven-3.4.0-testing/arquillian/pom.xml' ('42
: 25, org.jboss.arquillian.selenium:selenium-bom:2.53.0
/home/jieryn/.m2/repository/org/jboss/arquillian/selenium/selenium-bom/2.53.0/selenium-bom-2.53.0.pom',
'42 : 25, org.jboss.arquillian.selenium:selenium-bom:2.53.1
/home/jieryn/.m2/repository/org/jboss/arquillian/selenium/selenium-bom/2.53.1/selenium-bom-2.53.1.pom').
To resolve this conflict, either declare the dependency directly in
the dependency management of model
'com.acme:arquillian:pom:1.0-SNAPSHOT' to override what gets imported
or, as of Maven 3.4, rearrange the causing imports in the inheritance
hierarchy to apply standard override logic based on artifact
coordinates. Without resolving this conflict, your build relies on
indeterministic behaviour.



On Sat, Aug 20, 2016 at 5:13 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> On 20/08/16 07:05, Christian Schulte wrote:
>>
>> Am 08/19/16 um 21:10 schrieb jieryn:
>>>
>>> I am seeing a huge amount of additional warnings at the start of the
>>> build now, that is intentional I believe? Do we have a wiki or any
>>> documentation about resolving these issues? For example, I'm seeing
>>> this because I use Arquillian and their standard dependencyManagement
>>> bom scope=import style.
>>
>>
>> Intentional. No release notes yet.
>
>
>
> I posted that for a longer time ago..that I started on them already..
>
> https://github.com/khmarbaise/maven-release-notes
>
> Kind regards
> Karl Heinz
>
>
> -
> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-20 Thread Karl Heinz Marbaise 

Hi,

On 20/08/16 07:05, Christian Schulte wrote:

Am 08/19/16 um 21:10 schrieb jieryn:

I am seeing a huge amount of additional warnings at the start of the
build now, that is intentional I believe? Do we have a wiki or any
documentation about resolving these issues? For example, I'm seeing
this because I use Arquillian and their standard dependencyManagement
bom scope=import style.


Intentional. No release notes yet.



I posted that for a longer time ago..that I started on them already..

https://github.com/khmarbaise/maven-release-notes

Kind regards
Karl Heinz

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-20 Thread Karl Heinz Marbaise 

Hi,

On 19/08/16 21:10, jieryn wrote:

That seems to be working, thank you!

I am seeing a huge amount of additional warnings at the start of the
build now, that is intentional I believe? Do we have a wiki or any
documentation about resolving these issues? For example, I'm seeing
this because I use Arquillian and their standard dependencyManagement
bom scope=import style.


Can you please post the warnings here and if you have an example 
project? So may be I need to add informations into the release notes...



So we can take a look ?

Kind regards
Karl Heinz Marbaise



On Fri, Aug 19, 2016 at 2:01 PM, Karl Heinz Marbaise  wrote:

Hi,

can you please check here[1] for a current version of Maven 3.4.0-SNAPSHOT
and recheck your issues please...

And if the keep being there please report...

Many thanks for your help...

[1]: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/

Kind regards
Karl Heinz Marbaise
On 19/08/16 05:11, jieryn wrote:


Sorry I am so late to this party.

I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be overriden by any actual parameters that I specify on the
command line.

Specifically, I am trying to override the maven.config --fail-at-end
via --fail-fast, and also --threads 2.0C with --threads 1. When I
invoke mvn, it seems the maven.config options are taken instead of my
local cli invocation. These have a bad effect on my invocation and
cause a lot of trouble. We do not check in our .mvn/maven.config, so I
can not simply rm -rf it and then check it out after... it's a pita,
and bad karma. Please examine it :) thank you.

On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise 
wrote:


Hi to all Maven users,

If you like to help making the next Maven release better it would be nice
if
you could help a little bit.

Please be aware of this *** This is not an official release ***

I have created downloadable packages which are available from here:


Windows: https://s.apache.org/vG4r
Linux/Mac: https://s.apache.org/FfRw

Every kind of feedback is helpful.

Important hint:

This is only a current state of development (Git hash:
90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
community...

The current list of changes can be seen in the issue tracker:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0

It would be nice if those who had found issues to retest their scenarios.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-19 Thread Christian Schulte 
Am 08/19/16 um 21:10 schrieb jieryn:
> I am seeing a huge amount of additional warnings at the start of the
> build now, that is intentional I believe? Do we have a wiki or any
> documentation about resolving these issues? For example, I'm seeing
> this because I use Arquillian and their standard dependencyManagement
> bom scope=import style.

Intentional. No release notes yet.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-19 Thread jieryn 
That seems to be working, thank you!

I am seeing a huge amount of additional warnings at the start of the
build now, that is intentional I believe? Do we have a wiki or any
documentation about resolving these issues? For example, I'm seeing
this because I use Arquillian and their standard dependencyManagement
bom scope=import style.

On Fri, Aug 19, 2016 at 2:01 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> can you please check here[1] for a current version of Maven 3.4.0-SNAPSHOT
> and recheck your issues please...
>
> And if the keep being there please report...
>
> Many thanks for your help...
>
> [1]: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/
>
> Kind regards
> Karl Heinz Marbaise
> On 19/08/16 05:11, jieryn wrote:
>>
>> Sorry I am so late to this party.
>>
>> I find that Apache Maven 3.4.0-SNAPSHOT
>> (90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
>> prefers .mvn/maven.config options instead of specifically listed
>> parameters. This is surprising to me. I expect the .mvn/maven.config
>> options to be overriden by any actual parameters that I specify on the
>> command line.
>>
>> Specifically, I am trying to override the maven.config --fail-at-end
>> via --fail-fast, and also --threads 2.0C with --threads 1. When I
>> invoke mvn, it seems the maven.config options are taken instead of my
>> local cli invocation. These have a bad effect on my invocation and
>> cause a lot of trouble. We do not check in our .mvn/maven.config, so I
>> can not simply rm -rf it and then check it out after... it's a pita,
>> and bad karma. Please examine it :) thank you.
>>
>> On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise 
>> wrote:
>>>
>>> Hi to all Maven users,
>>>
>>> If you like to help making the next Maven release better it would be nice
>>> if
>>> you could help a little bit.
>>>
>>> Please be aware of this *** This is not an official release ***
>>>
>>> I have created downloadable packages which are available from here:
>>>
>>>
>>> Windows: https://s.apache.org/vG4r
>>> Linux/Mac: https://s.apache.org/FfRw
>>>
>>> Every kind of feedback is helpful.
>>>
>>> Important hint:
>>>
>>> This is only a current state of development (Git hash:
>>> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
>>> community...
>>>
>>> The current list of changes can be seen in the issue tracker:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>>
>>> It would be nice if those who had found issues to retest their scenarios.
>>>
>>>
>
> -
> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-19 Thread Karl Heinz Marbaise 

Hi,

can you please check here[1] for a current version of Maven 
3.4.0-SNAPSHOT and recheck your issues please...


And if the keep being there please report...

Many thanks for your help...

[1]: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x/

Kind regards
Karl Heinz Marbaise
On 19/08/16 05:11, jieryn wrote:

Sorry I am so late to this party.

I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be overriden by any actual parameters that I specify on the
command line.

Specifically, I am trying to override the maven.config --fail-at-end
via --fail-fast, and also --threads 2.0C with --threads 1. When I
invoke mvn, it seems the maven.config options are taken instead of my
local cli invocation. These have a bad effect on my invocation and
cause a lot of trouble. We do not check in our .mvn/maven.config, so I
can not simply rm -rf it and then check it out after... it's a pita,
and bad karma. Please examine it :) thank you.

On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise  wrote:

Hi to all Maven users,

If you like to help making the next Maven release better it would be nice if
you could help a little bit.

Please be aware of this *** This is not an official release ***

I have created downloadable packages which are available from here:


Windows: https://s.apache.org/vG4r
Linux/Mac: https://s.apache.org/FfRw

Every kind of feedback is helpful.

Important hint:

This is only a current state of development (Git hash:
90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
community...

The current list of changes can be seen in the issue tracker:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0

It would be nice if those who had found issues to retest their scenarios.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-18 Thread jieryn 
Sorry I am so late to this party.

I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be overriden by any actual parameters that I specify on the
command line.

Specifically, I am trying to override the maven.config --fail-at-end
via --fail-fast, and also --threads 2.0C with --threads 1. When I
invoke mvn, it seems the maven.config options are taken instead of my
local cli invocation. These have a bad effect on my invocation and
cause a lot of trouble. We do not check in our .mvn/maven.config, so I
can not simply rm -rf it and then check it out after... it's a pita,
and bad karma. Please examine it :) thank you.

On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise  wrote:
> Hi to all Maven users,
>
> If you like to help making the next Maven release better it would be nice if
> you could help a little bit.
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
>
> Windows: https://s.apache.org/vG4r
> Linux/Mac: https://s.apache.org/FfRw
>
> Every kind of feedback is helpful.
>
> Important hint:
>
> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
> It would be nice if those who had found issues to retest their scenarios.
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> 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

New Maven Model version (was Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3))

2016-08-17 Thread Paul Benedict 
Moving this discussion to the dev@ list...

My advice is for the team to introduce the full functional consumption of a
4.1 POM in Maven 4.0. What should go in the 3.x branch is the appropriate
forward-compatible handling -- warning or error -- to allow 3.x users to
receive sensible diagnostic messages.

I see that as the best sole reason to increase Maven's major version. The
3.x has always been held back to using the current POM model. It sounds
like the future is almost here and I wouldn't set the bar any higher for a
Maven 4.0 release. That sounds like the feature that should drive tomorrow.

Cheers,
Paul

On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte  wrote:

> Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> >
> >> There is an easy way to solve this. Maven validates the model version in
> >> the POM to match "4.0.0". Based on that version, Maven can decide how to
> >> behave. I am thinking about introducing model version "4.1.0" in Maven
> >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> >
> > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> long time ago when we were doing the Google Hangouts discussions about a
> mental separation of build/deploy POM.
>
> Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> with Maven < 3.4. Tools parsing the POMs themselves (not using
> maven-model-builder) would need to support that as well.
>
> >
> > If deployed as 4.1.0 then you'd be forcing all consumers of that
> dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but
> that might hurt any consuming applications like Sonar, Jenkins, or other
> build tools.
> >
>
> That's the drawback I am seeing as well. It's the same syntax with
> different semantics. That's why Maven < 3.4 would need to abort.
> Everything < 3.4 cannot provide the behaviour for that model version and
> thus must not e.g. silently ignore XML elements leading to e.g.
> different dependency trees when used with >= 3.4. It's a question of how
> to progress Maven core when it comes to changes in behaviour making
> sense. "Has always been that way -> must not change." Means we can never
> change anything and must provide new features for changing things (e.g.
> keep the import scope the way it always has been and introduce an
> include scope with the new behaviour and document the import scope is
> considered deprecated). It's not always possible to introduce a change
> as a new feature. We recently discussed the addition of some kind of
> feature toggles or knobs. That won't work, in my opinion, because Maven
> would behave differently based on command line options. It's not
> possible to deploy a POM to central whose correct/intended behaviour
> depends on a specical command line option in use. I see no other way to
> incrementing the model version for such things. Maven needs to know how
> to behave solely based on what is in the POM. Nothing syntax related.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-16 Thread Mark Derricutt 
On 17 Aug 2016, at 12:32, Christian Schulte wrote:

> There is an easy way to solve this. Maven validates the model version in
> the POM to match "4.0.0". Based on that version, Maven can decide how to
> behave. I am thinking about introducing model version "4.1.0" in Maven
> 3.4. All existing 4.0.0 POMs will work the same way as before. Model

Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a long time 
ago when we were doing the Google Hangouts discussions about a mental 
separation of build/deploy POM.

If deployed as 4.1.0 then you'd be forcing all consumers of that dependency to 
use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but that might hurt 
any consuming applications like Sonar, Jenkins, or other build tools.



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-08-16 Thread Christian Schulte 
Am 08/16/16 um 23:14 schrieb Curtis Rueden:
> properly with Maven 3.4.0. But I am very concerned about the precedent
> here: at any point in the future, complex builds which used to work might
> stop doing so, even without a major version increment, due to future
> changes in the logic of core Maven.
> 
> It would be ideal if in the future (something for Maven 4?), as much of
> this logic as possible could be pushed out of core and into plugins, so
> that they can be pinned in the POM, to promote better build reproducibility.

There is an easy way to solve this. Maven validates the model version in
the POM to match "4.0.0". Based on that version, Maven can decide how to
behave. I am thinking about introducing model version "4.1.0" in Maven
3.4. All existing 4.0.0 POMs will work the same way as before. Model
version 4.1.0 POMs can only be used by Maven >= 3.4. As soon as a
project starts deploying model version 4.1.0 POMs, Maven < 3.4 will not
support that and abort with an error message. There are other features
we could/should change/introduce in 3.4 based on that model version.
There are no release notes yet. Jut for the 'import' scope there are 3
things we could control based on the model version in 3.4 already.
Nothing of that would be supported by Maven < 3.4 so based on this
discussion, these would need to be reverted as well.

o Version range support for 'import' scope (MNG-4463).
o Relocation support for 'import' scope (MNG-5527).
o Execlusion processing for 'import' scope (MNG-5600).

Put a version range in an 'import' scope declaration, Maven < 3.4 will
abort with an error. Use a relocation in an 'import' scope declaration,
Maven < 3.4 will ignore it. Add execlusions to an 'import' scope
declaration, Maven < 3.4 will ignore it. We added features like these in
the past without incrementing the model version.

In my opinion, everything which has ever been postponed or reverted due
to backwards compatibility should go into 3.4 based on model version
4.1.0. I am not talking about a model change. Just update Maven 3.4 to
validate the model version holds "4.0.0" or "4.1.0" and decide on that
value what to do.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-22 Thread Mark Derricutt 
On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
wrote:

> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>

Have been using daily HEAD builds as my daily driver for the past few
weeks, so far no issues on any of our projects, so here's my pre-emptive +2
:)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-07 Thread Ralph Goers 
Actually, for me the ideal would be a command line switch that could re-enable 
the feature that was deprecated. Then you don’t really have to wait a release, 
so long as it is documented. This makes sure user’s are aware since they have 
to take a minor action to continue to make things work.

Ralph

> On Jul 7, 2016, at 9:27 AM, Paul Benedict  wrote:
> 
> Christian, you are right that introducing a warning does delay delivering
> the fix. Thanks for pointing that out. With that said, it's not all that
> bad because there are some choices...
> 
> 1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix
> enabled, and ask users@ to concurrently test both.
> 
> 2) A variation of #1, publish SNAPSHOT from the feature branch that
> contains the fix enabled.
> 
> 3) Do something Oracle-ish like introduce a command line option to enable
> prototype features. Pretending that -Z represents that new option, using
> -Z:MNG5277 would tentatively enable the fix and perhaps any -Z option
> would spit out a warning into the log saying you turned on an incomplete
> feature at your own risk.
> 
> To your point about "cluttering the different code bases", I personally
> just consider it a necessary development tax. Where's it possible, spit out
> the warning; otherwise not. Please also note option #3 also "clutters" even
> more by introducing if-checking for different behavior. Since I'd rather
> have less cluster than more, I personally prefer emitting the warning with
> a // TODO or // XXX marker in the code so the fix isn't not forgotten (with
> a reference to the MNG ticket).
> 
> Cheers,
> Paul
> 
> On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte  wrote:
> 
>> Am 07/07/16 um 17:49 schrieb Paul Benedict:
>>> If there is a change that will prevent a build from working, asking for
>>> users@ testing is not the way to do this. The way to do this is to
>>> introduce emit a "warning" first in the next version of Maven, and then
>>> convert it to an "error" in the next version after that. We can't just
>> say
>>> to users "hey, we may break your build now so please test" -- that's not
>>> nice of us. Let them test the warning, if anything, to make sure all
>> cases
>>> are correctly captured. If all cases are correctly captured, then
>>> converting the "warning" to an "error" will be simple.
>>> 
>>> I really propose we give users enough up-front notice that things are
>> going
>>> to break in a future build -- but not without introducing warnings into
>>> their build first. Let's give time for the community to correct their
>> POMs
>>> without creating emergency changes for developers.
>>> 
>> 
>> Then that's the way we are going to deliver bugfixes. So be it. Any news
>> on that 'feature toggle API'? Just emitting warnings everywhere is not
>> always possible. There is no logger available everywhere. I really would
>> like to capture things like these with an API. Having an API forcing you
>> to add references to issues in JIRA and so on you can search usages and
>> things like this. Cluttering the different codebases with warnings
>> everywhere whenever a bug is found/a new feature is introduced means we
>> will not fix the bug/introduce the feature but add a warning. So noone
>> will have a chance to test builds with the bugs fixed/features enabled.
>> Maybe we add a '-pedantic' command line option users can use to test
>> "what will happen when Maven does error out instead of warning me".
>> Someone still working on that MNG-6056 branch? We really need a shared
>> component for this. It's not only about Maven core. Do we all agree on
>> those feature toggles, BTW?
>> 
>> Regards,
>> --
>> Christian
>> 
>> 
>> -
>> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-07 Thread Gary Gregory 
On Thu, Jul 7, 2016 at 8:49 AM, Paul Benedict  wrote:

> If there is a change that will prevent a build from working, asking for
> users@ testing is not the way to do this. The way to do this is to
> introduce emit a "warning" first in the next version of Maven, and then
> convert it to an "error" in the next version after that. We can't just say
> to users "hey, we may break your build now so please test" -- that's not
> nice of us. Let them test the warning, if anything, to make sure all cases
> are correctly captured. If all cases are correctly captured, then
> converting the "warning" to an "error" will be simple.
>
> I really propose we give users enough up-front notice that things are going
> to break in a future build -- but not without introducing warnings into
> their build first. Let's give time for the community to correct their POMs
> without creating emergency changes for developers.
>

+1, just like when you deprecate an API in Java.

The trick for Maven is to define what deprecation means for itself.

Of course that does not help you when you jump multiple versions at once,
but at least you can then go back and update one version at a time.

Gary


>
> Cheers,
> Paul
>
> On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte  wrote:
>
> > Am 07/06/16 um 23:32 schrieb Christian Schulte:
> > > Am 07/06/16 um 23:19 schrieb Christian Schulte:
> > >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> > >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
> >  Hi to all Maven users,
> > 
> >  If you like to help making the next Maven release better it would be
> >  nice if you could help a little bit.
> > 
> >  Please be aware of this *** This is not an official release ***
> > 
> >  I have created downloadable packages which are available from here:
> > 
> >  Windows: https://s.apache.org/qDs1
> >  Linux/Mac: https://s.apache.org/Sn7X
> > 
> >  Every kind of feedback is helpful.
> > 
> >  Important hint:
> > 
> >  Based on the following issue
> >  https://issues.apache.org/jira/browse/MNG-5227 the optional flag
> in a
> >  dependencyManagement was simply ignored with previous Maven
> versions.
> >  This Maven version starts to handle that correct. If you have
> problems
> >  with that please report.
> > 
> > 
> > >>>
> > >>> I believe this build (git hash
> > 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the
> fix
> > for MNG-5227. The previous testing snapshot built from
> > 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for
> MNG-5227,
> > but the fix was reverted to avoid breaking builds which relied on the old
> > behaviour.
> > >>>
> > >>> (this is just based on my reading of the commit history)
> > >>
> > >> There is MNG-5935 which is fixed and has an impact on the optional
> flag
> > >> in dependency management. See this commit and its message.
> > >> <
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e
> > >
> > >> and there is MNG-5227 which has an impact on the optional flag in
> > >> dependency management. See this commit and its message.
> > >> <
> >
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a
> > >.
> > >> Someone on dev@ has reported that he is using the optional flag in
> > >> dependency management (setting it to true) and that he has noticed
> that
> > >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> > >> noticed it is not working before. What is important to know is that
> > >> before the fix for MNG-5935 all managed dependencies were implicitly
> > >> managing optional to false. Aether got updated to change the optional
> > >> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> > >> reflect that. So instead of passing 'null' to Aether, it passed
> 'false'
> > >> meaning 'manage the optional flag to false' where it should have
> passed
> > >> 'null' meaning 'do not manage the optional flag in any way'.
> > >>
> > >
> > > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> > > test contained an Aether bugfix. That bugfix has lead to reports about
> > > missing 'test' dependencies. See this commit and it's message
> > > <
> >
> https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d
> > >
> > > and the description in the bugtracker
> > > .
> > > That bugfix has been reverted in 3.4 but will re-appear as soon as we
> > > update Aether which contains that bugfix correctly.
> > >
> > > Regards,
> > >
> >
> >
> > Long drum-roll here.
> >
> > What we were discussing on users@ was how we are going to ship bugfixes
> > like these to the users. Either they will notice something has not
> > worked before and starts working or they will not notice

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-07 Thread Paul Benedict 
Christian, you are right that introducing a warning does delay delivering
the fix. Thanks for pointing that out. With that said, it's not all that
bad because there are some choices...

1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix
enabled, and ask users@ to concurrently test both.

2) A variation of #1, publish SNAPSHOT from the feature branch that
contains the fix enabled.

3) Do something Oracle-ish like introduce a command line option to enable
prototype features. Pretending that -Z represents that new option, using
-Z:MNG5277 would tentatively enable the fix and perhaps any -Z option
would spit out a warning into the log saying you turned on an incomplete
feature at your own risk.

To your point about "cluttering the different code bases", I personally
just consider it a necessary development tax. Where's it possible, spit out
the warning; otherwise not. Please also note option #3 also "clutters" even
more by introducing if-checking for different behavior. Since I'd rather
have less cluster than more, I personally prefer emitting the warning with
a // TODO or // XXX marker in the code so the fix isn't not forgotten (with
a reference to the MNG ticket).

Cheers,
Paul

On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte  wrote:

> Am 07/07/16 um 17:49 schrieb Paul Benedict:
> > If there is a change that will prevent a build from working, asking for
> > users@ testing is not the way to do this. The way to do this is to
> > introduce emit a "warning" first in the next version of Maven, and then
> > convert it to an "error" in the next version after that. We can't just
> say
> > to users "hey, we may break your build now so please test" -- that's not
> > nice of us. Let them test the warning, if anything, to make sure all
> cases
> > are correctly captured. If all cases are correctly captured, then
> > converting the "warning" to an "error" will be simple.
> >
> > I really propose we give users enough up-front notice that things are
> going
> > to break in a future build -- but not without introducing warnings into
> > their build first. Let's give time for the community to correct their
> POMs
> > without creating emergency changes for developers.
> >
>
> Then that's the way we are going to deliver bugfixes. So be it. Any news
> on that 'feature toggle API'? Just emitting warnings everywhere is not
> always possible. There is no logger available everywhere. I really would
> like to capture things like these with an API. Having an API forcing you
> to add references to issues in JIRA and so on you can search usages and
> things like this. Cluttering the different codebases with warnings
> everywhere whenever a bug is found/a new feature is introduced means we
> will not fix the bug/introduce the feature but add a warning. So noone
> will have a chance to test builds with the bugs fixed/features enabled.
> Maybe we add a '-pedantic' command line option users can use to test
> "what will happen when Maven does error out instead of warning me".
> Someone still working on that MNG-6056 branch? We really need a shared
> component for this. It's not only about Maven core. Do we all agree on
> those feature toggles, BTW?
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-07 Thread Christian Schulte 
Am 07/07/16 um 17:49 schrieb Paul Benedict:
> If there is a change that will prevent a build from working, asking for
> users@ testing is not the way to do this. The way to do this is to
> introduce emit a "warning" first in the next version of Maven, and then
> convert it to an "error" in the next version after that. We can't just say
> to users "hey, we may break your build now so please test" -- that's not
> nice of us. Let them test the warning, if anything, to make sure all cases
> are correctly captured. If all cases are correctly captured, then
> converting the "warning" to an "error" will be simple.
> 
> I really propose we give users enough up-front notice that things are going
> to break in a future build -- but not without introducing warnings into
> their build first. Let's give time for the community to correct their POMs
> without creating emergency changes for developers.
> 

Then that's the way we are going to deliver bugfixes. So be it. Any news
on that 'feature toggle API'? Just emitting warnings everywhere is not
always possible. There is no logger available everywhere. I really would
like to capture things like these with an API. Having an API forcing you
to add references to issues in JIRA and so on you can search usages and
things like this. Cluttering the different codebases with warnings
everywhere whenever a bug is found/a new feature is introduced means we
will not fix the bug/introduce the feature but add a warning. So noone
will have a chance to test builds with the bugs fixed/features enabled.
Maybe we add a '-pedantic' command line option users can use to test
"what will happen when Maven does error out instead of warning me".
Someone still working on that MNG-6056 branch? We really need a shared
component for this. It's not only about Maven core. Do we all agree on
those feature toggles, BTW?

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-07 Thread Paul Benedict 
If there is a change that will prevent a build from working, asking for
users@ testing is not the way to do this. The way to do this is to
introduce emit a "warning" first in the next version of Maven, and then
convert it to an "error" in the next version after that. We can't just say
to users "hey, we may break your build now so please test" -- that's not
nice of us. Let them test the warning, if anything, to make sure all cases
are correctly captured. If all cases are correctly captured, then
converting the "warning" to an "error" will be simple.

I really propose we give users enough up-front notice that things are going
to break in a future build -- but not without introducing warnings into
their build first. Let's give time for the community to correct their POMs
without creating emergency changes for developers.

Cheers,
Paul

On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte  wrote:

> Am 07/06/16 um 23:32 schrieb Christian Schulte:
> > Am 07/06/16 um 23:19 schrieb Christian Schulte:
> >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
>  Hi to all Maven users,
> 
>  If you like to help making the next Maven release better it would be
>  nice if you could help a little bit.
> 
>  Please be aware of this *** This is not an official release ***
> 
>  I have created downloadable packages which are available from here:
> 
>  Windows: https://s.apache.org/qDs1
>  Linux/Mac: https://s.apache.org/Sn7X
> 
>  Every kind of feedback is helpful.
> 
>  Important hint:
> 
>  Based on the following issue
>  https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
>  dependencyManagement was simply ignored with previous Maven versions.
>  This Maven version starts to handle that correct. If you have problems
>  with that please report.
> 
> 
> >>>
> >>> I believe this build (git hash
> 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the fix
> for MNG-5227. The previous testing snapshot built from
> 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for MNG-5227,
> but the fix was reverted to avoid breaking builds which relied on the old
> behaviour.
> >>>
> >>> (this is just based on my reading of the commit history)
> >>
> >> There is MNG-5935 which is fixed and has an impact on the optional flag
> >> in dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e
> >
> >> and there is MNG-5227 which has an impact on the optional flag in
> >> dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a
> >.
> >> Someone on dev@ has reported that he is using the optional flag in
> >> dependency management (setting it to true) and that he has noticed that
> >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> >> noticed it is not working before. What is important to know is that
> >> before the fix for MNG-5935 all managed dependencies were implicitly
> >> managing optional to false. Aether got updated to change the optional
> >> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> >> reflect that. So instead of passing 'null' to Aether, it passed 'false'
> >> meaning 'manage the optional flag to false' where it should have passed
> >> 'null' meaning 'do not manage the optional flag in any way'.
> >>
> >
> > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> > test contained an Aether bugfix. That bugfix has lead to reports about
> > missing 'test' dependencies. See this commit and it's message
> > <
> https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d
> >
> > and the description in the bugtracker
> > .
> > That bugfix has been reverted in 3.4 but will re-appear as soon as we
> > update Aether which contains that bugfix correctly.
> >
> > Regards,
> >
>
>
> Long drum-roll here.
>
> What we were discussing on users@ was how we are going to ship bugfixes
> like these to the users. Either they will notice something has not
> worked before and starts working or they will not notice anything and
> just complain the build is no longer working as before. And we cannot
> revert things like these for eternity.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Christian Schulte 
Am 07/06/16 um 23:32 schrieb Christian Schulte:
> Am 07/06/16 um 23:19 schrieb Christian Schulte:
>> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
>>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
 Hi to all Maven users,
  
 If you like to help making the next Maven release better it would be  
 nice if you could help a little bit.
  
 Please be aware of this *** This is not an official release ***
  
 I have created downloadable packages which are available from here:
  
 Windows: https://s.apache.org/qDs1
 Linux/Mac: https://s.apache.org/Sn7X
  
 Every kind of feedback is helpful.
  
 Important hint:
  
 Based on the following issue  
 https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a  
 dependencyManagement was simply ignored with previous Maven versions.  
 This Maven version starts to handle that correct. If you have problems  
 with that please report.
  
  
>>>
>>> I believe this build (git hash 227085283b6379038ec16f4cf9ad2e8869cef694) 
>>> doesn’t actually contain the fix for MNG-5227. The previous testing 
>>> snapshot built from 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain 
>>> the fix for MNG-5227, but the fix was reverted to avoid breaking builds 
>>> which relied on the old behaviour.
>>>
>>> (this is just based on my reading of the commit history)  
>>
>> There is MNG-5935 which is fixed and has an impact on the optional flag
>> in dependency management. See this commit and its message.
>> 
>> and there is MNG-5227 which has an impact on the optional flag in
>> dependency management. See this commit and its message.
>> .
>> Someone on dev@ has reported that he is using the optional flag in
>> dependency management (setting it to true) and that he has noticed that
>> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
>> noticed it is not working before. What is important to know is that
>> before the fix for MNG-5935 all managed dependencies were implicitly
>> managing optional to false. Aether got updated to change the optional
>> flag from 'boolean' to 'Boolean' and Maven has not been updated to
>> reflect that. So instead of passing 'null' to Aether, it passed 'false'
>> meaning 'manage the optional flag to false' where it should have passed
>> 'null' meaning 'do not manage the optional flag in any way'.
>>
> 
> To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> test contained an Aether bugfix. That bugfix has lead to reports about
> missing 'test' dependencies. See this commit and it's message
> 
> and the description in the bugtracker
> .
> That bugfix has been reverted in 3.4 but will re-appear as soon as we
> update Aether which contains that bugfix correctly.
> 
> Regards,
> 


Long drum-roll here.

What we were discussing on users@ was how we are going to ship bugfixes
like these to the users. Either they will notice something has not
worked before and starts working or they will not notice anything and
just complain the build is no longer working as before. And we cannot
revert things like these for eternity.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Christian Schulte 
Am 07/06/16 um 23:19 schrieb Christian Schulte:
> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
>>> Hi to all Maven users,
>>>  
>>> If you like to help making the next Maven release better it would be  
>>> nice if you could help a little bit.
>>>  
>>> Please be aware of this *** This is not an official release ***
>>>  
>>> I have created downloadable packages which are available from here:
>>>  
>>> Windows: https://s.apache.org/qDs1
>>> Linux/Mac: https://s.apache.org/Sn7X
>>>  
>>> Every kind of feedback is helpful.
>>>  
>>> Important hint:
>>>  
>>> Based on the following issue  
>>> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a  
>>> dependencyManagement was simply ignored with previous Maven versions.  
>>> This Maven version starts to handle that correct. If you have problems  
>>> with that please report.
>>>  
>>>  
>>
>> I believe this build (git hash 227085283b6379038ec16f4cf9ad2e8869cef694) 
>> doesn’t actually contain the fix for MNG-5227. The previous testing snapshot 
>> built from 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for 
>> MNG-5227, but the fix was reverted to avoid breaking builds which relied on 
>> the old behaviour.
>>
>> (this is just based on my reading of the commit history)  
> 
> There is MNG-5935 which is fixed and has an impact on the optional flag
> in dependency management. See this commit and its message.
> 
> and there is MNG-5227 which has an impact on the optional flag in
> dependency management. See this commit and its message.
> .
> Someone on dev@ has reported that he is using the optional flag in
> dependency management (setting it to true) and that he has noticed that
> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> noticed it is not working before. What is important to know is that
> before the fix for MNG-5935 all managed dependencies were implicitly
> managing optional to false. Aether got updated to change the optional
> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> reflect that. So instead of passing 'null' to Aether, it passed 'false'
> meaning 'manage the optional flag to false' where it should have passed
> 'null' meaning 'do not manage the optional flag in any way'.
> 

To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
test contained an Aether bugfix. That bugfix has lead to reports about
missing 'test' dependencies. See this commit and it's message

and the description in the bugtracker
.
That bugfix has been reverted in 3.4 but will re-appear as soon as we
update Aether which contains that bugfix correctly.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Christian Schulte 
Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
>> Hi to all Maven users,
>>  
>> If you like to help making the next Maven release better it would be  
>> nice if you could help a little bit.
>>  
>> Please be aware of this *** This is not an official release ***
>>  
>> I have created downloadable packages which are available from here:
>>  
>> Windows: https://s.apache.org/qDs1
>> Linux/Mac: https://s.apache.org/Sn7X
>>  
>> Every kind of feedback is helpful.
>>  
>> Important hint:
>>  
>> Based on the following issue  
>> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a  
>> dependencyManagement was simply ignored with previous Maven versions.  
>> This Maven version starts to handle that correct. If you have problems  
>> with that please report.
>>  
>>  
> 
> I believe this build (git hash 227085283b6379038ec16f4cf9ad2e8869cef694) 
> doesn’t actually contain the fix for MNG-5227. The previous testing snapshot 
> built from 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for 
> MNG-5227, but the fix was reverted to avoid breaking builds which relied on 
> the old behaviour.
> 
> (this is just based on my reading of the commit history)  

There is MNG-5935 which is fixed and has an impact on the optional flag
in dependency management. See this commit and its message.

and there is MNG-5227 which has an impact on the optional flag in
dependency management. See this commit and its message.
.
Someone on dev@ has reported that he is using the optional flag in
dependency management (setting it to true) and that he has noticed that
this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
noticed it is not working before. What is important to know is that
before the fix for MNG-5935 all managed dependencies were implicitly
managing optional to false. Aether got updated to change the optional
flag from 'boolean' to 'Boolean' and Maven has not been updated to
reflect that. So instead of passing 'null' to Aether, it passed 'false'
meaning 'manage the optional flag to false' where it should have passed
'null' meaning 'do not manage the optional flag in any way'.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Stuart McCulloch 
On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
> Hi to all Maven users,
>  
> If you like to help making the next Maven release better it would be  
> nice if you could help a little bit.
>  
> Please be aware of this *** This is not an official release ***
>  
> I have created downloadable packages which are available from here:
>  
> Windows: https://s.apache.org/qDs1
> Linux/Mac: https://s.apache.org/Sn7X
>  
> Every kind of feedback is helpful.
>  
> Important hint:
>  
> Based on the following issue  
> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a  
> dependencyManagement was simply ignored with previous Maven versions.  
> This Maven version starts to handle that correct. If you have problems  
> with that please report.
>  
>  

I believe this build (git hash 227085283b6379038ec16f4cf9ad2e8869cef694) 
doesn’t actually contain the fix for MNG-5227. The previous testing snapshot 
built from 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for 
MNG-5227, but the fix was reverted to avoid breaking builds which relied on the 
old behaviour.

(this is just based on my reading of the commit history)  
>  
> This is only a current state of development (Git hash:  
> 227085283b6379038ec16f4cf9ad2e8869cef694) to get some feedback from the  
> community...
>  
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>  
> It would be nice if those who had found issues to retest their scenarios.
>  
>  
> Kind regards
> Karl Heinz Marbaise
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
>  
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Gary Gregory 
I like the idea of a deprecation warning.

Gary

On Wed, Jul 6, 2016 at 12:55 PM, Paul Benedict  wrote:

> Karl, I still believe the user who recommended that MNG-5227 be emitted as
> a warning (not error) in 3.4 was onto something correct. It's clear people
> aren't getting any lead time to know that their POM has a problem and thus
> breaks when using 3.4. Making it a warning now and switching it to an error
> in 3.5 is more friendly to the upgrade path, I believe. I still hope you
> can reconsider the issue because it's not a nice thing to fail a build for
> the sake of fixing thing within 1 point release. At least for anyone who
> tries jumping 2 point releases, the Maven developers could say "we gave you
> the chance" but there is no chance at this moment.
>
> Cheers,
> Paul
>
> On Wed, Jul 6, 2016 at 2:46 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi to all Maven users,
> >
> > If you like to help making the next Maven release better it would be nice
> > if you could help a little bit.
> >
> > Please be aware of this *** This is not an official release ***
> >
> > I have created downloadable packages which are available from here:
> >
> > Windows: https://s.apache.org/qDs1
> > Linux/Mac: https://s.apache.org/Sn7X
> >
> > Every kind of feedback is helpful.
> >
> > Important hint:
> >
> > Based on the following issue
> > https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
> > dependencyManagement was simply ignored with previous Maven versions.
> This
> > Maven version starts to handle that correct. If you have problems with
> that
> > please report.
> >
> >
> > This is only a current state of development (Git hash:
> > 227085283b6379038ec16f4cf9ad2e8869cef694) to get some feedback from the
> > community...
> >
> > The current list of changes can be seen in the issue tracker:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
> >
> > It would be nice if those who had found issues to retest their scenarios.
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

2016-07-06 Thread Paul Benedict 
Karl, I still believe the user who recommended that MNG-5227 be emitted as
a warning (not error) in 3.4 was onto something correct. It's clear people
aren't getting any lead time to know that their POM has a problem and thus
breaks when using 3.4. Making it a warning now and switching it to an error
in 3.5 is more friendly to the upgrade path, I believe. I still hope you
can reconsider the issue because it's not a nice thing to fail a build for
the sake of fixing thing within 1 point release. At least for anyone who
tries jumping 2 point releases, the Maven developers could say "we gave you
the chance" but there is no chance at this moment.

Cheers,
Paul

On Wed, Jul 6, 2016 at 2:46 PM, Karl Heinz Marbaise 
wrote:

> Hi to all Maven users,
>
> If you like to help making the next Maven release better it would be nice
> if you could help a little bit.
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/qDs1
> Linux/Mac: https://s.apache.org/Sn7X
>
> Every kind of feedback is helpful.
>
> Important hint:
>
> Based on the following issue
> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
> dependencyManagement was simply ignored with previous Maven versions. This
> Maven version starts to handle that correct. If you have problems with that
> please report.
>
>
> This is only a current state of development (Git hash:
> 227085283b6379038ec16f4cf9ad2e8869cef694) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
> It would be nice if those who had found issues to retest their scenarios.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>