[vote] MNG-1577 as the default behavior

[Jason van Zyl-2]

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@...

[Brian E Fox]

I can think of some cases where it might break a build, but most of them
are where a transitive dependency creeps into a build because the user
assumes that MNG-1577 is how it's always worked. That being said, these
issues would be easily remedied since you now have more control, and
anyone using depMgt put those things there for a reason.

We should just include a big notice in the release notes about this
change so people are at least aware of it.

+1 for making this the default.

-----Original Message-----
From: Jason van Zyl [mailto:jason@...]
Sent: Thursday, March 15, 2007 8:33 PM
To: Maven Developers List
Subject: [vote] MNG-1577 as the default behavior

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@...

[Carlos Sanchez-4]

i'm fine for 2.1, for 2.0.6 may be too risky

What about this use case for transitive dependencyManagement? has been tested?

A -> B -> C -> D

C depends on D 1.0
B has D 2.0 in dependencyManagement, no D in dependencies

A should get D 2.0



On 3/15/07, Jason van Zyl <jason@...> 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@...
>
>

--
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@...

[mperham]

A will get D 2.0.  Yes, our build depends heavily on this behavior.

I'm ok with it going into 2.0.6 as long as it is noted in the release
notes.  Based on the number of votes the issue has, this is a major
problem for a lot of people.  I can't imagine any reasonably sized
build which has not encountered it already.

mike

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

> i'm fine for 2.1, for 2.0.6 may be too risky
>
> What about this use case for transitive dependencyManagement? has been tested?
>
> A -> B -> C -> D
>
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
>
> A should get D 2.0
>
>

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

[Nathan Beyer-3]

I can attest to this being a major issue for complex builds. Without
this behavior, it's nearly impossible to manage the build of complex
projects.

-Nathan

On 3/15/07, Mike Perham <mperham@...> wrote:

> A will get D 2.0.  Yes, our build depends heavily on this behavior.
>
> I'm ok with it going into 2.0.6 as long as it is noted in the release
> notes.  Based on the number of votes the issue has, this is a major
> problem for a lot of people.  I can't imagine any reasonably sized
> build which has not encountered it already.
>
> mike
>
> On 3/15/07, Carlos Sanchez <carlos@...> wrote:
> > i'm fine for 2.1, for 2.0.6 may be too risky
> >
> > What about this use case for transitive dependencyManagement? has been tested?
> >
> > A -> B -> C -> D
> >
> > C depends on D 1.0
> > B has D 2.0 in dependencyManagement, no D in dependencies
> >
> > A should get D 2.0
> >
> >
>
> ---------------------------------------------------------------------
> 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@...

[Ralph Goers]

Well, obviously I would have no objection. ;-)

+1

Ralph

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@...

[Ralph Goers]

Question.  Has Mike or Patrick updated the documentation yet?  I started
to update the wiki a couple of months ago but put it off as I didn't
want the wiki to reflect something that you couldn't yet use.  Plus the
behavior changed slightly since then.

If they haven't beaten me to it, I'd be happy to do this as I promised
(hoping they will review it of course).

Ralph

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@...

[Patrick Schneider-4]

We haven't done any documentation yet, no.  I'll certainly be happy to write
some up, help you out, review what you have, etc.

Where is the wiki page you were editing?  Is it open to anyone, or do I need
to submit changes to it through you or Mike?

On 3/15/07, Ralph Goers <Ralph.Goers@...> wrote:

>
> Question.  Has Mike or Patrick updated the documentation yet?  I started
> to update the wiki a couple of months ago but put it off as I didn't
> want the wiki to reflect something that you couldn't yet use.  Plus the
> behavior changed slightly since then.
>
> If they haven't beaten me to it, I'd be happy to do this as I promised
> (hoping they will review it of course).
>
> Ralph
>
> 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@...
>
>

[brettporter]

-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@...

[Emmanuel Venisse]

+1

Emmanuel

Jason van Zyl a écrit :

> 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@...

[Jason van Zyl-2]

On 16 Mar 07, at 12:10 AM 16 Mar 07, Ralph Goers wrote:

> Question.  Has Mike or Patrick updated the documentation yet?  I  
> started to update the wiki a couple of months ago but put it off as  
> I didn't want the wiki to reflect something that you couldn't yet  
> use.  Plus the behavior changed slightly since then.
>
> If they haven't beaten me to it, I'd be happy to do this as I  
> promised (hoping they will review it of course).
>

I will also help because we need a spec that people can read to  
understand what exactly happens. There is a fundamental level of  
confusion as to how snapshots work, how versions work where, and how  
you accurately control what versions get pulled in. Ralph, I would  
certainly work with you to make an APT or Confluence document.  
Wherever is fine with me.

jason.

> Ralph
>
> 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@...

[Denis Cabasson]

Just a user here, but definitly a +1.

Dependency version resolution should always stay tuned to the POM of the current project being built.

Denis.

> -----Message d'origine-----
> De : Emmanuel Venisse [mailto:emmanuel@...]
> Envoyé : vendredi 16 mars 2007 08:12
> À : Maven Developers List
> Objet : Re: [vote] MNG-1577 as the default behavior
>
> +1
>
> Emmanuel
>
> Jason van Zyl a écrit :
> > 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@...

[Kenney Westerhof-3]

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@...

[Jörg Schaible]

Jason van Zyl wrote on Friday, March 16, 2007 1:33 AM:

> 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.

Since I am the original reporter of MNG-1577 (for M2.0.2 at that time) a very big +1. It is as Kenny said, we have a lot workarounds for it and the current behaviour casues us *a lot* of maintenance regarding our POMs. And it is quite tedious.

- Jörg

BTW: A very big thank you to all people working on this, especially Ralph, Jason, Patrick and Mike.

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

[Ralph Goers]

Brett,

As others have pointed out, most people have gotten around this by
explicitly specifying the dependencies in their pom, even though they
aren't direct dependencies.  This change won't affect them.  It only
affects folks who let Maven handle transitive dependencies and it will
also only affect them if they were using dependency management. At a
guess, I'd venture that number is pretty small, simply because the
behavior is totally unpredictable with a decent sized project.

FWIW, the way we "got around" this was to simply stick with Maven 1. We
had planned to migrate to Maven 2 last year but this was a showstopper
for us.

Ralph

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@...

[Patrick Schneider-4]

+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@...
>
>

[John Casey]

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@...
> >
> >
>

[Jason van Zyl-2]

On 16 Mar 07, at 2:55 AM 16 Mar 07, 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.

It's not consistent at all. It is totally erratic behavior,  
completely defective and counter intuitive. All people are forced to  
do is is continually override dependencies in child project to get  
the right version.

> 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.

All it will do is allow people to align all the versions from the  
parent POM. With MNG-1577 they can stop doing this. Mike has seen  
this in action in his builds, and I just corrected a build in what  
seemed a hopeless situation with the new behavior. There's nothing  
consistent about the current behavior, it's actually harmful.

>
> Our users must be able to trust point releases are safe upgrades.  
> Let's start moving on putting out 2.1 milestone releases instead.

I think this is a mistake and doesn't help our users. We have not  
only the ITs (which are still not good enough but ...) Patrick made  
an extensive set of tests plus we have users who have been watching  
this issue for a year and can attest in the field to this being a  
miserable situation. This is a solution to their problem.

Jason.

>
> - 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@...

[Jochen Wiedmann]

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@...

[Brian E Fox]

I agree (already voted) but which is easier to defend? A user who gets
upset that giving them more control broke their build (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?

-----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@...