[vote] MNG-1577 as the default behavior

[Jason van Zyl-2]

On 16 Mar 07, at 10:39 AM 16 Mar 07, Brian E. Fox wrote:

> I agree (already voted) but which is easier to defend? A user who gets
> upset that giving them more control broke their build

I'm all for testing this more thoroughly for anything that might not  
be spot on with the resolution but the process is that any transitive  
dependency is aligned to the depMan section unless a dependency in a  
child project overrides the version. I believe users would expect  
this to be the behavior and has only resulted in making additions  
which is counter intuitive. I think staging a release that folks can  
try this behavior would be prudent. The desired behavior is now in  
effect but we should ferret out anything but this patch has been used  
in production and if we can get 10-15 largish production builds to  
try this I think we would be safe in releasing it.

> (but is easy to
> fix) or constantly telling people who assume the new functionality  
> that
> the need to turn it on? Won't they be even more annoyed that it wasn't
> until they debugged the problem that they found out it was already
> fixed, it just wasn't enabled?
>

I think people would jump prematurely to 2.1 alphas for the behavior  
which has way more potential for breaking their builds. Having to go  
override manually and then flip back would be annoying, but the most  
likely scenario is that people won't read the release notes or be on  
the mailing list and continue getting the current behavior which is  
confusing. What we are doing here is providing the expected behavior.  
I'm trying to think of counter examples but I can't see how this  
patch could pull in the wrong dependency. Of course we don't want to  
break people's builds, but I think this patch alleviates much pain  
for the vast majority of users.

Jason.

> -----Original Message-----
> From: John Casey [mailto:casey.john.d@...]
> Sent: Friday, March 16, 2007 10:33 AM
> To: Maven Developers List
> Subject: Re: [vote] MNG-1577 as the default behavior
>
> I'm +1.
>
> I don't think that making dependencies in Maven more predictable or
> deterministic can wait for 2.1, especially considering that it has a
> fairly lengthy road before it gets to 2.1-final. Currently, what we  
> have
> in place seems buggy, whatever the reality, so I don't see it as worth
> defending as a feature of 2.0.x. As others have pointed out, any  
> broken
> builds caused by this should be easy to fix, since the builder now has
> much more - not less - control over his build.
>
> -john
>
> On 3/16/07, Patrick Schneider <pschneider@...> wrote:
>>
>> +1 (non-binding)
>>
>>> Our integration tests are way too simplistic to test this so we
>> definitely
>>> need to test this against 'real life' complex builds.
>>
>> FWIW, we have been using this patch on our 60+ module build for two
>> months or so, with extensive use of demMgmt/transitive dependencies
>> exercising the new behavior.
>>
>>
>> Patrick
>>
>> On 3/16/07, Kenney Westerhof <kenney@...> wrote:
>>>
>>>
>>> I think it won't break builds at all.
>>> I think that people have lots of workarounds in their poms right now
>
>>> to overcome this problem - specifying transitive dependencies
>>> directly, which they don't directly use, but just to enforce that
>>> version being used. I've done so myself quite a few times. Those
>>> builds will not fail since the extra dependency will be redundant.
>>>
>>> What could be a possible usecase where a build will break?
>>>
>>> I agree with the fact that we need to test this thorougly.
>>> Our integration tests are way too simplistic to test this so we
>> definitely
>>> need to test this against 'real life' complex builds.
>>> The best way to do that I think is to apply it to 2.0.x and let
>>> people test it on their builds for a while.
>>> If it's breaking more than it fixes we can always roll back before
>>> the release.
>>>
>>> -- Kenney
>>>
>>> Brett Porter wrote:
>>>> -1, at this point. I'd like to look at some specific test cases to
>
>>>> see how badly it might break a build - so I could be convinced.
>>>>
>>>> No matter how bad the existing behaviour, it is consistent once in
>
>>>> place. I think it's unacceptable to drop this into a .0.x release,
>
>>>> no matter what the release notes say. Even if it makes it better
>>>> for new builds, the people that have their current one
>>>> mysteriously break will be rightly livid. I think we suffered this
>
>>>> a little earlier when we enforced order when it wasn't
>>>> deterministic - I think this would be
>> more
>>>> confusing than in that instance.
>>>>
>>>> Our users must be able to trust point releases are safe upgrades.
>> Let's
>>>> start moving on putting out 2.1 milestone releases instead.
>>>>
>>>> - Brett
>>>>
>>>> On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> After working with it a little this week I would like to propose
>>>>> to make MNG-1577 behavior introduced the default. Builds are
>>>>> completely and totally unpredictable without this behavior. The
>>>>> behavior in
>> 2.0.5
>>>>> is fundamentally broken. To are totally prey to any dependency
>>>>> introduced by a dependency which makes no sense and completely
>> counter
>>>>> intuitive. I stabilized a massive build this week simply by using
>
>>>>> the behavior present in the 2.0.x branch. I don't think we're
>>>>> doing
>> anyone
>>>>> any favors leaving the old behavior in. After watching a disaster
>
>>>>> be recovered by using this new behavior I feel that the patch
>>>>> should go in as is and become the default behavior. This puts the
>
>>>>> user in control which is the way it should be.
>>>>>
>>>>> I propose we make this the default behavior. Can anyone think of
>>>>> a case where this degree of control would break an existing
> build?
>>>>>
>>>>> This patch saved my bacon this week, I think this behavior makes
>>>>> a world of difference to users.
>>>>>
>>>>> Jason.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------
>>>>> ---- To unsubscribe, e-mail: dev-unsubscribe@... For
>
>>>>> additional commands, e-mail: dev-help@...
>>>>
>>>> ------------------------------------------------------------------
>>>> --- To unsubscribe, e-mail: dev-unsubscribe@... For
>>>> additional commands, e-mail: dev-help@...
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@... For
>>> additional commands, e-mail: dev-help@...
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

>I'm all for testing this more thoroughly for anything that might not be
> spot on with the resolution but the process is that any transitive
>dependency is aligned to the depMan section unless a dependency in a
>child project overrides the version. I believe users would expect this
>to be the behavior and has only resulted in making additions which is
counter
>intuitive. I think staging a release that folks can try this behavior
would
>be prudent. The desired behavior is now in effect but we should ferret
out
>anything but this patch has been used in production and if we can get
10-15
>largish production builds to try this I think we would be safe in
releasing it.

I'm agreeing that this should be the default ;-)

I have a very large build and will try this out once it's staged (maybe
even sooner if I have time). I do know that I have some workarounds in
place because of this.

This new feature will make it safer to use the dependency-analyzer. Now
I will know its safe to remove an unused direct dependency once I update
my depMgt. Right now, I would have to remember that I put it there to
override a problem.
 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Andrew Williams-5]

+1, I agree with Kenney that folk will be able to remove a lot of  
workaround snippets from their poms,
the sooner the better.

Andy

On 16 Mar 2007, at 11:48, Kenney Westerhof wrote:

>
> I think it won't break builds at all.
> I think that people have lots of workarounds in their poms right now
> to overcome this problem - specifying transitive dependencies  
> directly,
> which they don't directly use, but just to enforce that version  
> being used. I've
> done so myself quite a few times. Those builds will not fail since the
> extra dependency will be redundant.
>
> What could be a possible usecase where a build will break?
>
> I agree with the fact that we need to test this thorougly.
> Our integration tests are way too simplistic to test this so we  
> definitely
> need to test this against 'real life' complex builds.
> The best way to do that I think is to apply it to 2.0.x and let  
> people test it
> on their builds for a while.
> If it's breaking more than it fixes we can always roll back before  
> the release.
>
> -- Kenney
>
> Brett Porter wrote:
>> -1, at this point. I'd like to look at some specific test cases to  
>> see how badly it might break a build - so I could be convinced.
>> No matter how bad the existing behaviour, it is consistent once in  
>> place. I think it's unacceptable to drop this into a .0.x release,  
>> no matter what the release notes say. Even if it makes it better  
>> for new builds, the people that have their current one  
>> mysteriously break will be rightly livid. I think we suffered this  
>> a little earlier when we enforced order when it wasn't  
>> deterministic - I think this would be more confusing than in that  
>> instance.
>> Our users must be able to trust point releases are safe upgrades.  
>> Let's start moving on putting out 2.1 milestone releases instead.
>> - Brett
>> On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:
>>> Hi,
>>>
>>> After working with it a little this week I would like to propose  
>>> to make MNG-1577 behavior introduced the default. Builds are  
>>> completely and totally unpredictable without this behavior. The  
>>> behavior in 2.0.5 is fundamentally broken. To are totally prey to  
>>> any dependency introduced by a dependency which makes no sense  
>>> and completely counter intuitive. I stabilized a massive build  
>>> this week simply by using the behavior present in the 2.0.x  
>>> branch. I don't think we're doing anyone any favors leaving the  
>>> old behavior in. After watching a disaster be recovered by using  
>>> this new behavior I feel that the patch should go in as is and  
>>> become the default behavior. This puts the user in control which  
>>> is the way it should be.
>>>
>>> I propose we make this the default behavior. Can anyone think of  
>>> a case where this degree of control would break an existing build?
>>>
>>> This patch saved my bacon this week, I think this behavior makes  
>>> a world of difference to users.
>>>
>>> Jason.
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

I agree with Brett, this is a 2.1 change, not a 2.0.x

Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
get an earlier 2.1, i though we were going to do it anyway.


On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:

> On 3/16/07, Brett Porter <brett@...> wrote:
>
> > Our users must be able to trust point releases are safe upgrades.
> > Let's start moving on putting out 2.1 milestone releases instead.
>
> Agreed. On the other hand, most others seem to consider this change important.
>
> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should satisfy all.
>
> Jochen
>
> --
> Emacs 22 will support MacOS and CygWin. It is not yet decided, whether
> these will be used to run Emacs or the other way round.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:

> I agree with Brett, this is a 2.1 change, not a 2.0.x
>

Do you fully understand what the current behavior is and what this  
patch fixes? You are essentially condemning users to complete  
unpredictability. I really think that a build should be staged and  
explain to users what the change is and let people build with it. If  
we don't get enough feedback or there is a consensus that they think  
it's not good then we don't put it in. But we already have many users  
who are suffering and asking for this to be the default behavior.

Jason.

> Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> get an earlier 2.1, i though we were going to do it anyway.
>
>
> On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
>> On 3/16/07, Brett Porter <brett@...> wrote:
>>
>> > Our users must be able to trust point releases are safe upgrades.
>> > Let's start moving on putting out 2.1 milestone releases instead.
>>
>> Agreed. On the other hand, most others seem to consider this  
>> change important.
>>
>> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should  
>> satisfy all.
>>
>> Jochen
>>
>> --
>> Emacs 22 will support MacOS and CygWin. It is not yet decided,  
>> whether
>> these will be used to run Emacs or the other way round.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eric Redmond]

+1 for patching 2.0.6

I have yet to hear a single convincing argument for maintaining broken
behavior. Who cares if people depend on it being broken? Don't upgrade. It's
a defect, not a feature change. Pushing this to a major version is way
overkill.

On 3/16/07, Carlos Sanchez <carlos@...> wrote:

>
> I agree with Brett, this is a 2.1 change, not a 2.0.x
>
> Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> get an earlier 2.1, i though we were going to do it anyway.
>
>
> On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> > On 3/16/07, Brett Porter <brett@...> wrote:
> >
> > > Our users must be able to trust point releases are safe upgrades.
> > > Let's start moving on putting out 2.1 milestone releases instead.
> >
> > Agreed. On the other hand, most others seem to consider this change
> important.
> >
> > So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should satisfy
> all.
> >
> > Jochen
> >
> > --
> > Emacs 22 will support MacOS and CygWin. It is not yet decided, whether
> > these will be used to run Emacs or the other way round.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Eric Redmond
http://codehaus.org/~eredmond

[J. Daniel Kulp]

I agree.   Anything that makes a "unpredictable behavior" predictable is
a bug fix that should go in a patch.   We've had to do all kinds of
wacky things to work around unpredictable behavior.   (we gotten
different behavior depend on the JDK we use, that's bad) 2.0.5 helped in
some cases, but this is still needed.

Dan

On Friday 16 March 2007 14:22, Jason van Zyl wrote:

> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>
> Do you fully understand what the current behavior is and what this
> patch fixes? You are essentially condemning users to complete
> unpredictability. I really think that a build should be staged and
> explain to users what the change is and let people build with it. If
> we don't get enough feedback or there is a consensus that they think
> it's not good then we don't put it in. But we already have many users
> who are suffering and asking for this to be the default behavior.
>
> Jason.
>
> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2
> > and get an earlier 2.1, i though we were going to do it anyway.
> >
> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >> > Our users must be able to trust point releases are safe upgrades.
> >> > Let's start moving on putting out 2.1 milestone releases instead.
> >>
> >> Agreed. On the other hand, most others seem to consider this
> >> change important.
> >>
> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> satisfy all.
> >>
> >> Jochen
> >>
> >> --
> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> whether
> >> these will be used to run Emacs or the other way round.
> >>
> >> -------------------------------------------------------------------
> >>-- To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@...
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

How hard would it be to make a tool to detect the condition where this
would cause a problem? Wouldn't you just compare the resolved artifacts
with the dependencyManagement section and see where there are
differences? Something like a pre-upgrade validator.

-----Original Message-----
From: Daniel Kulp [mailto:daniel.kulp@...]
Sent: Friday, March 16, 2007 2:29 PM
To: dev@...
Subject: Re: [vote] MNG-1577 as the default behavior


I agree.   Anything that makes a "unpredictable behavior" predictable is

a bug fix that should go in a patch.   We've had to do all kinds of
wacky things to work around unpredictable behavior.   (we gotten
different behavior depend on the JDK we use, that's bad) 2.0.5 helped in
some cases, but this is still needed.

Dan

On Friday 16 March 2007 14:22, Jason van Zyl wrote:

> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>
> Do you fully understand what the current behavior is and what this
> patch fixes? You are essentially condemning users to complete
> unpredictability. I really think that a build should be staged and
> explain to users what the change is and let people build with it. If
> we don't get enough feedback or there is a consensus that they think
> it's not good then we don't put it in. But we already have many users
> who are suffering and asking for this to be the default behavior.
>
> Jason.
>
> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2
> > and get an earlier 2.1, i though we were going to do it anyway.
> >
> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >> > Our users must be able to trust point releases are safe upgrades.
> >> > Let's start moving on putting out 2.1 milestone releases instead.
> >>
> >> Agreed. On the other hand, most others seem to consider this change

> >> important.
> >>
> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> satisfy all.
> >>
> >> Jochen
> >>
> >> --
> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> whether these will be used to run Emacs or the other way round.
> >>
> >> -------------------------------------------------------------------
> >>-- To unsubscribe, e-mail: dev-unsubscribe@...  For
> >>additional commands, e-mail: dev-help@...
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: dev-unsubscribe@...  For
> >additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@... For
> additional commands, e-mail: dev-help@...

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@...
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@... For additional
commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation, and even in the jira issue Brett says that it was
done on purpose.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

now poms in the repo that have dependencyManagement sections will
start to change the behavior of current builds and people with 2.0.5
will get very different results than people with 2.0.6 which i don't
think it's acceptable for 2.0.x

I'm not against the fix, and I wouldn't really care if this is shipped
next week as 2.1 and current 2.1 is moved to 2.2, or even better get
2.1 alpha now with this fix (+100!)


On 3/16/07, Jason van Zyl <jason@...> wrote:

>
> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>
> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> >
>
> Do you fully understand what the current behavior is and what this
> patch fixes? You are essentially condemning users to complete
> unpredictability. I really think that a build should be staged and
> explain to users what the change is and let people build with it. If
> we don't get enough feedback or there is a consensus that they think
> it's not good then we don't put it in. But we already have many users
> who are suffering and asking for this to be the default behavior.
>
> Jason.
>
> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> > get an earlier 2.1, i though we were going to do it anyway.
> >
> >
> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >>
> >> > Our users must be able to trust point releases are safe upgrades.
> >> > Let's start moving on putting out 2.1 milestone releases instead.
> >>
> >> Agreed. On the other hand, most others seem to consider this
> >> change important.
> >>
> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> satisfy all.
> >>
> >> Jochen
> >>
> >> --
> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> whether
> >> these will be used to run Emacs or the other way round.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

If my choice was 2.0.6 without this or call it 2.1 with it, then I say
call it 2.1. This move should imply an end to 2.0 releases though
because the last thing we need is 3 active releases.

-----Original Message-----
From: carlossg@... [mailto:carlossg@...] On Behalf Of Carlos
Sanchez
Sent: Friday, March 16, 2007 2:47 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior

it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in the
documentation, and even in the jira issue Brett says that it was done on
purpose.

http://maven.apache.org/guides/introduction/introduction-to-dependency-m
echanism.html

now poms in the repo that have dependencyManagement sections will start
to change the behavior of current builds and people with 2.0.5 will get
very different results than people with 2.0.6 which i don't think it's
acceptable for 2.0.x

I'm not against the fix, and I wouldn't really care if this is shipped
next week as 2.1 and current 2.1 is moved to 2.2, or even better get
2.1 alpha now with this fix (+100!)


On 3/16/07, Jason van Zyl <jason@...> wrote:

>
> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>
> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> >
>
> Do you fully understand what the current behavior is and what this
> patch fixes? You are essentially condemning users to complete
> unpredictability. I really think that a build should be staged and
> explain to users what the change is and let people build with it. If
> we don't get enough feedback or there is a consensus that they think
> it's not good then we don't put it in. But we already have many users
> who are suffering and asking for this to be the default behavior.
>
> Jason.
>
> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2
> > and get an earlier 2.1, i though we were going to do it anyway.
> >
> >
> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >>
> >> > Our users must be able to trust point releases are safe upgrades.
> >> > Let's start moving on putting out 2.1 milestone releases instead.
> >>
> >> Agreed. On the other hand, most others seem to consider this change

> >> important.
> >>
> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> satisfy all.
> >>
> >> Jochen
> >>
> >> --
> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> whether these will be used to run Emacs or the other way round.
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: dev-unsubscribe@... For
> >> additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@... For
> > additional commands, e-mail: dev-help@...
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@... For
> additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@... For additional
commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote:

> it's not unpredictable at all, it is pretty clear that to force a
> version in a project you need to add it in your pom and
> dependencyManagement doesn't affect transitive dependencies, it's in
> the documentation, and even in the jira issue Brett says that it was
> done on purpose.

It's not clear because it's bites people all the time because it's  
not intuitive at all.

>
> http://maven.apache.org/guides/introduction/introduction-to- 
> dependency-mechanism.html
>

You think anyone reads that first? It's simply not what's expected.

> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2.0.6 which i don't
> think it's acceptable for 2.0.x

No they won't. If you have overridden a dependency in a child that  
definition wins. Again as expected. As you expect if you override the  
version. What people can start doing to improve their situation is  
remove that version, manage it from depMan and still get the correct  
version, the one they selected, put into the graph. This behavior  
would not change how child project define dependencies i.e. the  
definition in the child will win. The patch allows real management  
from the depMan of the versions used and that's really what it boils  
down to.

>
> I'm not against the fix, and I wouldn't really care if this is shipped
> next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> 2.1 alpha now with this fix (+100!)

It's not a feature change, it's a fundamental defect.

Jason.

>
>
> On 3/16/07, Jason van Zyl <jason@...> wrote:
>>
>> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>>
>> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>> >
>>
>> Do you fully understand what the current behavior is and what this
>> patch fixes? You are essentially condemning users to complete
>> unpredictability. I really think that a build should be staged and
>> explain to users what the change is and let people build with it. If
>> we don't get enough feedback or there is a consensus that they think
>> it's not good then we don't put it in. But we already have many users
>> who are suffering and asking for this to be the default behavior.
>>
>> Jason.
>>
>> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to  
>> 2.2 and
>> > get an earlier 2.1, i though we were going to do it anyway.
>> >
>> >
>> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
>> >> On 3/16/07, Brett Porter <brett@...> wrote:
>> >>
>> >> > Our users must be able to trust point releases are safe  
>> upgrades.
>> >> > Let's start moving on putting out 2.1 milestone releases  
>> instead.
>> >>
>> >> Agreed. On the other hand, most others seem to consider this
>> >> change important.
>> >>
>> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> >> satisfy all.
>> >>
>> >> Jochen
>> >>
>> >> --
>> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> >> whether
>> >> these will be used to run Emacs or the other way round.
>> >>
>> >>  
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> >                             -- The Princess Bride
>> >
>> >  
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kenney Westerhof-3]

Carlos Sanchez wrote:
> it's not unpredictable at all, it is pretty clear that to force a
> version in a project you need to add it in your pom and
> dependencyManagement doesn't affect transitive dependencies, it's in
> the documentation,

Where?

> and even in the jira issue Brett says that it was
> done on purpose.
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html 

Nothing about this mentioned there..

> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2.0.6 which i don't
> think it's acceptable for 2.0.x

How? a pom in the repo with a depMgt section will only affect it's own
dependencies, not the project depending on that pom in that repo.
If it didn't already specify a depMgt it will be unpredictable, and if it does,
then this change has no effect, since to fix a transitive dep's version
the dependency has to be specified in that pom too; so it'll contain both
a depMgt _and_ a dependency.

> I'm not against the fix, and I wouldn't really care if this is shipped
> next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> 2.1 alpha now with this fix (+100!)

It's a bugfix, I don't see why this can't be applied to the version that contains
the bug, but this bug has to be supported throughout the 2.0.x line.

So we've established that this bugfix is something we want and it should go in
2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
I simply cannot understand how we can make 2.0.6 or newer behave in the same
unpredictable way (the case where the dependency is NOT specified to override
the depMgt section). That's just unsupportable.

-- Kenney

>
>
> On 3/16/07, Jason van Zyl <jason@...> wrote:
>>
>> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>>
>> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>> >
>>
>> Do you fully understand what the current behavior is and what this
>> patch fixes? You are essentially condemning users to complete
>> unpredictability. I really think that a build should be staged and
>> explain to users what the change is and let people build with it. If
>> we don't get enough feedback or there is a consensus that they think
>> it's not good then we don't put it in. But we already have many users
>> who are suffering and asking for this to be the default behavior.
>>
>> Jason.
>>
>> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
>> > get an earlier 2.1, i though we were going to do it anyway.
>> >
>> >
>> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
>> >> On 3/16/07, Brett Porter <brett@...> wrote:
>> >>
>> >> > Our users must be able to trust point releases are safe upgrades.
>> >> > Let's start moving on putting out 2.1 milestone releases instead.
>> >>
>> >> Agreed. On the other hand, most others seem to consider this
>> >> change important.
>> >>
>> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> >> satisfy all.
>> >>
>> >> Jochen
>> >>
>> >> --
>> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> >> whether
>> >> these will be used to run Emacs or the other way round.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> >                             -- The Princess Bride
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 16 Mar 07, at 2:49 PM 16 Mar 07, Brian E. Fox wrote:

> If my choice was 2.0.6 without this or call it 2.1 with it, then I say
> call it 2.1. This move should imply an end to 2.0 releases though
> because the last thing we need is 3 active releases.
>

I will work with Patrick to put the old and new in 2.0.x. If it  
really comes down to turning it off by default, which would be an  
immense shame, then so be it and people will just have to turn it on.  
We'll just devise a very easy way to turn it on like a property in  
the top-level POM. We can't jump from 2.0.6 to a 2.1 for this.

Jason.

> -----Original Message-----
> From: carlossg@... [mailto:carlossg@...] On Behalf Of  
> Carlos
> Sanchez
> Sent: Friday, March 16, 2007 2:47 PM
> To: Maven Developers List
> Subject: Re: [vote] MNG-1577 as the default behavior
>
> it's not unpredictable at all, it is pretty clear that to force a
> version in a project you need to add it in your pom and
> dependencyManagement doesn't affect transitive dependencies, it's  
> in the
> documentation, and even in the jira issue Brett says that it was  
> done on
> purpose.
>
> http://maven.apache.org/guides/introduction/introduction-to- 
> dependency-m
> echanism.html
>
> now poms in the repo that have dependencyManagement sections will  
> start
> to change the behavior of current builds and people with 2.0.5 will  
> get
> very different results than people with 2.0.6 which i don't think it's
> acceptable for 2.0.x
>
> I'm not against the fix, and I wouldn't really care if this is shipped
> next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> 2.1 alpha now with this fix (+100!)
>
>
> On 3/16/07, Jason van Zyl <jason@...> wrote:
>>
>> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>>
>>> I agree with Brett, this is a 2.1 change, not a 2.0.x
>>>
>>
>> Do you fully understand what the current behavior is and what this
>> patch fixes? You are essentially condemning users to complete
>> unpredictability. I really think that a build should be staged and
>> explain to users what the change is and let people build with it. If
>> we don't get enough feedback or there is a consensus that they think
>> it's not good then we don't put it in. But we already have many users
>> who are suffering and asking for this to be the default behavior.
>>
>> Jason.
>>
>>> Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2
>>> and get an earlier 2.1, i though we were going to do it anyway.
>>>
>>>
>>> On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
>>>> On 3/16/07, Brett Porter <brett@...> wrote:
>>>>
>>>>> Our users must be able to trust point releases are safe upgrades.
>>>>> Let's start moving on putting out 2.1 milestone releases instead.
>>>>
>>>> Agreed. On the other hand, most others seem to consider this change
>
>>>> important.
>>>>
>>>> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>>>> satisfy all.
>>>>
>>>> Jochen
>>>>
>>>> --
>>>> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>>>> whether these will be used to run Emacs or the other way round.
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: dev-unsubscribe@... For
>>>> additional commands, e-mail: dev-help@...
>>>>
>>>>
>>>
>>>
>>> --
>>> I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                             -- The Princess Bride
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@... For
>>> additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@... For
>> additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@... For  
> additional
> commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey]

If the solution to this situation has been to define the dependency locally
with the version you want, how can having a dependencyManagement section
that works transitively possibly be relevant to those builds? Carlos, how
can this possibly break those builds?

I think this issue is way too important to leave out of the 2.0.x line. It's
nowhere near big enough as far as the feature itself to force an
entire 2.1release (or even an alpha of
2.1, IMO), BUT it is hampering Maven adoption now. To me that means that our
application doesn't do a good enough job of explaining what you should do in
these cases, and more importantly, WHY you should do it. Solving
counter-intuitive configuration with web documentation is certainly one way
to address it, but it will not pass the five-minute adoption test.

-john

On 3/16/07, Jason van Zyl <jason@...> wrote:

>
>
> On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote:
>
> > it's not unpredictable at all, it is pretty clear that to force a
> > version in a project you need to add it in your pom and
> > dependencyManagement doesn't affect transitive dependencies, it's in
> > the documentation, and even in the jira issue Brett says that it was
> > done on purpose.
>
> It's not clear because it's bites people all the time because it's
> not intuitive at all.
>
> >
> > http://maven.apache.org/guides/introduction/introduction-to-
> > dependency-mechanism.html
> >
>
> You think anyone reads that first? It's simply not what's expected.
>
> > now poms in the repo that have dependencyManagement sections will
> > start to change the behavior of current builds and people with 2.0.5
> > will get very different results than people with 2.0.6 which i don't
> > think it's acceptable for 2.0.x
>
> No they won't. If you have overridden a dependency in a child that
> definition wins. Again as expected. As you expect if you override the
> version. What people can start doing to improve their situation is
> remove that version, manage it from depMan and still get the correct
> version, the one they selected, put into the graph. This behavior
> would not change how child project define dependencies i.e. the
> definition in the child will win. The patch allows real management
> from the depMan of the versions used and that's really what it boils
> down to.
>
> >
> > I'm not against the fix, and I wouldn't really care if this is shipped
> > next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> > 2.1 alpha now with this fix (+100!)
>
> It's not a feature change, it's a fundamental defect.
>
> Jason.
>
> >
> >
> > On 3/16/07, Jason van Zyl <jason@...> wrote:
> >>
> >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> >>
> >> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> >> >
> >>
> >> Do you fully understand what the current behavior is and what this
> >> patch fixes? You are essentially condemning users to complete
> >> unpredictability. I really think that a build should be staged and
> >> explain to users what the change is and let people build with it. If
> >> we don't get enough feedback or there is a consensus that they think
> >> it's not good then we don't put it in. But we already have many users
> >> who are suffering and asking for this to be the default behavior.
> >>
> >> Jason.
> >>
> >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to
> >> 2.2 and
> >> > get an earlier 2.1, i though we were going to do it anyway.
> >> >
> >> >
> >> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >> >>
> >> >> > Our users must be able to trust point releases are safe
> >> upgrades.
> >> >> > Let's start moving on putting out 2.1 milestone releases
> >> instead.
> >> >>
> >> >> Agreed. On the other hand, most others seem to consider this
> >> >> change important.
> >> >>
> >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> >> satisfy all.
> >> >>
> >> >> Jochen
> >> >>
> >> >> --
> >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> >> whether
> >> >> these will be used to run Emacs or the other way round.
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >> For additional commands, e-mail: dev-help@...
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > I could give you my word as a Spaniard.
> >> > No good. I've known too many Spaniards.
> >> >                             -- The Princess Bride
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> > For additional commands, e-mail: dev-help@...
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                             -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Carlos Sanchez-4]

On 3/16/07, Kenney Westerhof <kenney@...> wrote:

>
>
> Carlos Sanchez wrote:
>
> > now poms in the repo that have dependencyManagement sections will
> > start to change the behavior of current builds and people with 2.0.5
> > will get very different results than people with 2.0.6 which i don't
> > think it's acceptable for 2.0.x
>
> How? a pom in the repo with a depMgt section will only affect it's own
> dependencies, not the project depending on that pom in that repo.
> If it didn't already specify a depMgt it will be unpredictable, and if it does,
> then this change has no effect, since to fix a transitive dep's version
> the dependency has to be specified in that pom too; so it'll contain both
> a depMgt _and_ a dependency.

you have to make dependencyManagement transitive, if i publish B
depending on C saying in the depMng that C must be 2.0, A depending on
B has to get that C, so you need transitive dependencyManagement

> So we've established that this bugfix is something we want and it should go in
> 2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
> I simply cannot understand how we can make 2.0.6 or newer behave in the same
> unpredictable way (the case where the dependency is NOT specified to override
> the depMgt section). That's just unsupportable.

I don't think it's unpredictable at all, counter intuitive sure, but
not unpredictable.

It's not acceptable for 2.0.6 to have a very different behavior than 2.0.5
my 2 cents

>
> -- Kenney
>
> >
> >
> > On 3/16/07, Jason van Zyl <jason@...> wrote:
> >>
> >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> >>
> >> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> >> >
> >>
> >> Do you fully understand what the current behavior is and what this
> >> patch fixes? You are essentially condemning users to complete
> >> unpredictability. I really think that a build should be staged and
> >> explain to users what the change is and let people build with it. If
> >> we don't get enough feedback or there is a consensus that they think
> >> it's not good then we don't put it in. But we already have many users
> >> who are suffering and asking for this to be the default behavior.
> >>
> >> Jason.
> >>
> >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> >> > get an earlier 2.1, i though we were going to do it anyway.
> >> >
> >> >
> >> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> >> >> On 3/16/07, Brett Porter <brett@...> wrote:
> >> >>
> >> >> > Our users must be able to trust point releases are safe upgrades.
> >> >> > Let's start moving on putting out 2.1 milestone releases instead.
> >> >>
> >> >> Agreed. On the other hand, most others seem to consider this
> >> >> change important.
> >> >>
> >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> >> >> satisfy all.
> >> >>
> >> >> Jochen
> >> >>
> >> >> --
> >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> >> >> whether
> >> >> these will be used to run Emacs or the other way round.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >> For additional commands, e-mail: dev-help@...
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > I could give you my word as a Spaniard.
> >> > No good. I've known too many Spaniards.
> >> >                             -- The Princess Bride
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> > For additional commands, e-mail: dev-help@...
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

On 3/16/07, John Casey <casey.john.d@...> wrote:
> If the solution to this situation has been to define the dependency locally
> with the version you want, how can having a dependencyManagement section
> that works transitively possibly be relevant to those builds? Carlos, how
> can this possibly break those builds?

not in that case, but this one

A -> B -> C -> D 1.0

B inherits dependencyManagement from somewhere with D 2.0 but doesn't
depend on D explicitly

A gets D 1.0 in 2.0.5
A gets D 2.0 in 2.0.6


>
> I think this issue is way too important to leave out of the 2.0.x line. It's
> nowhere near big enough as far as the feature itself to force an
> entire 2.1release (or even an alpha of
> 2.1, IMO), BUT it is hampering Maven adoption now. To me that means that our
> application doesn't do a good enough job of explaining what you should do in
> these cases, and more importantly, WHY you should do it. Solving
> counter-intuitive configuration with web documentation is certainly one way
> to address it, but it will not pass the five-minute adoption test.


I guess I have lower expectations for 2.1 than other people here,
thinking that it doesn't need so many new stuff. I would like to avoid
getting to the same point where 1.1 is.

I'd guess that most of the people that want the issue to be fixed in
2.0.6 don't care if it's 2.1 as long as its sooner than later.

>
> -john
>
> On 3/16/07, Jason van Zyl <jason@...> wrote:
> >
> >
> > On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote:
> >
> > > it's not unpredictable at all, it is pretty clear that to force a
> > > version in a project you need to add it in your pom and
> > > dependencyManagement doesn't affect transitive dependencies, it's in
> > > the documentation, and even in the jira issue Brett says that it was
> > > done on purpose.
> >
> > It's not clear because it's bites people all the time because it's
> > not intuitive at all.
> >
> > >
> > > http://maven.apache.org/guides/introduction/introduction-to-
> > > dependency-mechanism.html
> > >
> >
> > You think anyone reads that first? It's simply not what's expected.
> >
> > > now poms in the repo that have dependencyManagement sections will
> > > start to change the behavior of current builds and people with 2.0.5
> > > will get very different results than people with 2.0.6 which i don't
> > > think it's acceptable for 2.0.x
> >
> > No they won't. If you have overridden a dependency in a child that
> > definition wins. Again as expected. As you expect if you override the
> > version. What people can start doing to improve their situation is
> > remove that version, manage it from depMan and still get the correct
> > version, the one they selected, put into the graph. This behavior
> > would not change how child project define dependencies i.e. the
> > definition in the child will win. The patch allows real management
> > from the depMan of the versions used and that's really what it boils
> > down to.
> >
> > >
> > > I'm not against the fix, and I wouldn't really care if this is shipped
> > > next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> > > 2.1 alpha now with this fix (+100!)
> >
> > It's not a feature change, it's a fundamental defect.
> >
> > Jason.
> >
> > >
> > >
> > > On 3/16/07, Jason van Zyl <jason@...> wrote:
> > >>
> > >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> > >>
> > >> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> > >> >
> > >>
> > >> Do you fully understand what the current behavior is and what this
> > >> patch fixes? You are essentially condemning users to complete
> > >> unpredictability. I really think that a build should be staged and
> > >> explain to users what the change is and let people build with it. If
> > >> we don't get enough feedback or there is a consensus that they think
> > >> it's not good then we don't put it in. But we already have many users
> > >> who are suffering and asking for this to be the default behavior.
> > >>
> > >> Jason.
> > >>
> > >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to
> > >> 2.2 and
> > >> > get an earlier 2.1, i though we were going to do it anyway.
> > >> >
> > >> >
> > >> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> > >> >> On 3/16/07, Brett Porter <brett@...> wrote:
> > >> >>
> > >> >> > Our users must be able to trust point releases are safe
> > >> upgrades.
> > >> >> > Let's start moving on putting out 2.1 milestone releases
> > >> instead.
> > >> >>
> > >> >> Agreed. On the other hand, most others seem to consider this
> > >> >> change important.
> > >> >>
> > >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> > >> >> satisfy all.
> > >> >>
> > >> >> Jochen
> > >> >>
> > >> >> --
> > >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> > >> >> whether
> > >> >> these will be used to run Emacs or the other way round.
> > >> >>
> > >> >>
> > >> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> > >> >> For additional commands, e-mail: dev-help@...
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > I could give you my word as a Spaniard.
> > >> > No good. I've known too many Spaniards.
> > >> >                             -- The Princess Bride
> > >> >
> > >> >
> > >> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@...
> > >> > For additional commands, e-mail: dev-help@...
> > >> >
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@...
> > >> For additional commands, e-mail: dev-help@...
> > >>
> > >>
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > >                             -- The Princess Bride
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey]

First, it's not clear to me that depMgmt is used from a POM that is loaded
out of the repository...I'll take another look, though. In any case,
whatever B does to specify its own dependencies, you'll have to override in
one form or another in A, correct? If B specifies a dependency on D ==
2.0directly (to override C's dep on D ==
1.0, maybe), then A will also have to depend directly on D == whatever to
get its desired behavior. How does transitive dependencyManagement change
that?

Second, are you really saying that we need to support three active branches
of Maven at once? Or, are you saying that you're fine shutting down the
2.0.x branch and moving that stuff (the lower-risk refactorings, etc.) on to
2.1, with trunk becoming 2.2?

-john

On 3/16/07, Carlos Sanchez <carlos@...> wrote:

>
> On 3/16/07, John Casey <casey.john.d@...> wrote:
> > If the solution to this situation has been to define the dependency
> locally
> > with the version you want, how can having a dependencyManagement section
> > that works transitively possibly be relevant to those builds? Carlos,
> how
> > can this possibly break those builds?
>
> not in that case, but this one
>
> A -> B -> C -> D 1.0
>
> B inherits dependencyManagement from somewhere with D 2.0 but doesn't
> depend on D explicitly
>
> A gets D 1.0 in 2.0.5
> A gets D 2.0 in 2.0.6
>
>
> >
> > I think this issue is way too important to leave out of the 2.0.x line.
> It's
> > nowhere near big enough as far as the feature itself to force an
> > entire 2.1release (or even an alpha of
> > 2.1, IMO), BUT it is hampering Maven adoption now. To me that means that
> our
> > application doesn't do a good enough job of explaining what you should
> do in
> > these cases, and more importantly, WHY you should do it. Solving
> > counter-intuitive configuration with web documentation is certainly one
> way
> > to address it, but it will not pass the five-minute adoption test.
>
>
> I guess I have lower expectations for 2.1 than other people here,
> thinking that it doesn't need so many new stuff. I would like to avoid
> getting to the same point where 1.1 is.
>
> I'd guess that most of the people that want the issue to be fixed in
> 2.0.6 don't care if it's 2.1 as long as its sooner than later.
>
>
> >
> > -john
> >
> > On 3/16/07, Jason van Zyl <jason@...> wrote:
> > >
> > >
> > > On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote:
> > >
> > > > it's not unpredictable at all, it is pretty clear that to force a
> > > > version in a project you need to add it in your pom and
> > > > dependencyManagement doesn't affect transitive dependencies, it's in
> > > > the documentation, and even in the jira issue Brett says that it was
> > > > done on purpose.
> > >
> > > It's not clear because it's bites people all the time because it's
> > > not intuitive at all.
> > >
> > > >
> > > > http://maven.apache.org/guides/introduction/introduction-to-
> > > > dependency-mechanism.html
> > > >
> > >
> > > You think anyone reads that first? It's simply not what's expected.
> > >
> > > > now poms in the repo that have dependencyManagement sections will
> > > > start to change the behavior of current builds and people with 2.0.5
> > > > will get very different results than people with 2.0.6 which i don't
> > > > think it's acceptable for 2.0.x
> > >
> > > No they won't. If you have overridden a dependency in a child that
> > > definition wins. Again as expected. As you expect if you override the
> > > version. What people can start doing to improve their situation is
> > > remove that version, manage it from depMan and still get the correct
> > > version, the one they selected, put into the graph. This behavior
> > > would not change how child project define dependencies i.e. the
> > > definition in the child will win. The patch allows real management
> > > from the depMan of the versions used and that's really what it boils
> > > down to.
> > >
> > > >
> > > > I'm not against the fix, and I wouldn't really care if this is
> shipped
> > > > next week as 2.1 and current 2.1 is moved to 2.2, or even better get
> > > > 2.1 alpha now with this fix (+100!)
> > >
> > > It's not a feature change, it's a fundamental defect.
> > >
> > > Jason.
> > >
> > > >
> > > >
> > > > On 3/16/07, Jason van Zyl <jason@...> wrote:
> > > >>
> > > >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> > > >>
> > > >> > I agree with Brett, this is a 2.1 change, not a 2.0.x
> > > >> >
> > > >>
> > > >> Do you fully understand what the current behavior is and what this
> > > >> patch fixes? You are essentially condemning users to complete
> > > >> unpredictability. I really think that a build should be staged and
> > > >> explain to users what the change is and let people build with it.
> If
> > > >> we don't get enough feedback or there is a consensus that they
> think
> > > >> it's not good then we don't put it in. But we already have many
> users
> > > >> who are suffering and asking for this to be the default behavior.
> > > >>
> > > >> Jason.
> > > >>
> > > >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to
> > > >> 2.2 and
> > > >> > get an earlier 2.1, i though we were going to do it anyway.
> > > >> >
> > > >> >
> > > >> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
> > > >> >> On 3/16/07, Brett Porter <brett@...> wrote:
> > > >> >>
> > > >> >> > Our users must be able to trust point releases are safe
> > > >> upgrades.
> > > >> >> > Let's start moving on putting out 2.1 milestone releases
> > > >> instead.
> > > >> >>
> > > >> >> Agreed. On the other hand, most others seem to consider this
> > > >> >> change important.
> > > >> >>
> > > >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
> > > >> >> satisfy all.
> > > >> >>
> > > >> >> Jochen
> > > >> >>
> > > >> >> --
> > > >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
> > > >> >> whether
> > > >> >> these will be used to run Emacs or the other way round.
> > > >> >>
> > > >> >>
> > > >>
> ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> > > >> >> For additional commands, e-mail: dev-help@...
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > I could give you my word as a Spaniard.
> > > >> > No good. I've known too many Spaniards.
> > > >> >                             -- The Princess Bride
> > > >> >
> > > >> >
> > > >>
> ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@...
> > > >> > For additional commands, e-mail: dev-help@...
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@...
> > > >> For additional commands, e-mail: dev-help@...
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > I could give you my word as a Spaniard.
> > > > No good. I've known too many Spaniards.
> > > >                             -- The Princess Bride
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > > For additional commands, e-mail: dev-help@...
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                              -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Kenney Westerhof-3]

Carlos Sanchez wrote:

> On 3/16/07, Kenney Westerhof <kenney@...> wrote:
>>
>>
>> Carlos Sanchez wrote:
>>
>> > now poms in the repo that have dependencyManagement sections will
>> > start to change the behavior of current builds and people with 2.0.5
>> > will get very different results than people with 2.0.6 which i don't
>> > think it's acceptable for 2.0.x
>>
>> How? a pom in the repo with a depMgt section will only affect it's own
>> dependencies, not the project depending on that pom in that repo.
>> If it didn't already specify a depMgt it will be unpredictable, and if
>> it does,
>> then this change has no effect, since to fix a transitive dep's version
>> the dependency has to be specified in that pom too; so it'll contain both
>> a depMgt _and_ a dependency.
>
> you have to make dependencyManagement transitive, if i publish B
> depending on C saying in the depMng that C must be 2.0, A depending on
> B has to get that C, so you need transitive dependencyManagement

Yup. Each dep is resolved from the scope it's defined in.

>> So we've established that this bugfix is something we want and it
>> should go in
>> 2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
>> I simply cannot understand how we can make 2.0.6 or newer behave in
>> the same
>> unpredictable way (the case where the dependency is NOT specified to
>> override
>> the depMgt section). That's just unsupportable.
>
> I don't think it's unpredictable at all, counter intuitive sure, but
> not unpredictable.

You're only describing the case where you override the version by specifying
a transitive dep directly. If you don't, then it's unpredictable.
If I say in my pom 'i want junit 4 for my modules' and some transitive dep has junit 3
my build can break because i get the wrong dep.

>
> It's not acceptable for 2.0.6 to have a very different behavior than 2.0.5
> my 2 cents
>
>>
>> -- Kenney
>>
>> >
>> >
>> > On 3/16/07, Jason van Zyl <jason@...> wrote:
>> >>
>> >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>> >>
>> >> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>> >> >
>> >>
>> >> Do you fully understand what the current behavior is and what this
>> >> patch fixes? You are essentially condemning users to complete
>> >> unpredictability. I really think that a build should be staged and
>> >> explain to users what the change is and let people build with it. If
>> >> we don't get enough feedback or there is a consensus that they think
>> >> it's not good then we don't put it in. But we already have many users
>> >> who are suffering and asking for this to be the default behavior.
>> >>
>> >> Jason.
>> >>
>> >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to
>> 2.2 and
>> >> > get an earlier 2.1, i though we were going to do it anyway.
>> >> >
>> >> >
>> >> > On 3/16/07, Jochen Wiedmann <jochen.wiedmann@...> wrote:
>> >> >> On 3/16/07, Brett Porter <brett@...> wrote:
>> >> >>
>> >> >> > Our users must be able to trust point releases are safe upgrades.
>> >> >> > Let's start moving on putting out 2.1 milestone releases instead.
>> >> >>
>> >> >> Agreed. On the other hand, most others seem to consider this
>> >> >> change important.
>> >> >>
>> >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> >> >> satisfy all.
>> >> >>
>> >> >> Jochen
>> >> >>
>> >> >> --
>> >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> >> >> whether
>> >> >> these will be used to run Emacs or the other way round.
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> >> For additional commands, e-mail: dev-help@...
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > I could give you my word as a Spaniard.
>> >> > No good. I've known too many Spaniards.
>> >> >                             -- The Princess Bride
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@...
>> >> > For additional commands, e-mail: dev-help@...
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Patrick Schneider-4]

On 3/16/07, Carlos Sanchez <carlos@...> wrote:

>
> On 3/16/07, John Casey <casey.john.d@...> wrote:
> > If the solution to this situation has been to define the dependency
> locally
> > with the version you want, how can having a dependencyManagement section
> > that works transitively possibly be relevant to those builds? Carlos,
> how
> > can this possibly break those builds?
>
> not in that case, but this one
>
> A -> B -> C -> D 1.0
>
> B inherits dependencyManagement from somewhere with D 2.0 but doesn't
> depend on D explicitly
>
> A gets D 1.0 in 2.0.5
> A gets D 2.0 in 2.0.6

Right.  Assuming the depMgmt section is coming from A, the patch will
resolve D to whatever A's depMgmt says.

The workaround pre-patch was to explicitly list D in B.  For existing
projects in which that has been done, this patch will not affect behavior at
all.  The benefit to these projects is that they can *remove* the explicit
listing in B, and get the same behavior.

For existing projects in which the workaround was not used, then I would
question two things:

- Does the project work as expected?
- Do they really care what version of D gets pulled in?

If they are not using the work around, it seems to me that the answer to at
least one of these would have to be 'No'.  And in this case, it doesn't seem
like altering the behavior matters much anyway.


Patrick

[Carlos Sanchez-4]

On 3/16/07, John Casey <casey.john.d@...> wrote:
> First, it's not clear to me that depMgmt is used from a POM that is loaded
> out of the repository...I'll take another look, though. In any case,
> whatever B does to specify its own dependencies, you'll have to override in
> one form or another in A, correct? If B specifies a dependency on D ==
> 2.0directly (to override C's dep on D ==
> 1.0, maybe), then A will also have to depend directly on D == whatever to
> get its desired behavior. How does transitive dependencyManagement change
> that?

i don't follow you here, the problem is when 2.0.5 builds get some
version "by default" (they don't override it). Those builds would get
another version in 2.0.6

>
> Second, are you really saying that we need to support three active branches
> of Maven at once? Or, are you saying that you're fine shutting down the
> 2.0.x branch and moving that stuff (the lower-risk refactorings, etc.) on to
> 2.1, with trunk becoming 2.2?

only two branches 2.0.x and 2.1 or 2.1.x and 2.2 depending on what we
chose to do

>
> -john
>
> On 3/16/07, Carlos Sanchez <carlos@...> wrote:
> >
> > On 3/16/07, John Casey <casey.john.d@...> wrote:
> > > If the solution to this situation has been to define the dependency
> > locally
> > > with the version you want, how can having a dependencyManagement section
> > > that works transitively possibly be relevant to those builds? Carlos,
> > how
> > > can this possibly break those builds?
> >
> > not in that case, but this one
> >
> > A -> B -> C -> D 1.0
> >
> > B inherits dependencyManagement from somewhere with D 2.0 but doesn't
> > depend on D explicitly
> >
> > A gets D 1.0 in 2.0.5
> > A gets D 2.0 in 2.0.6
> >
> >

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...