You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/03/16 01:33:27 UTC
[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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-1577
Posted by Patrick Schneider <ps...@gmail.com>.
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 <Ra...@dslextreme.com> 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MNG-1577
Posted by Brett Porter <br...@apache.org>.
This doc looks good to me.
On 17/03/2007, at 7:11 PM, Ralph Goers wrote:
> Jason van Zyl wrote:
>>
>> 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.
> I've attached a new patch to mng-1577. It contains a patch to a
> couple of the APT files for the web site. Please feel free to edit
> it if I have gotten something wrong. I've built the site with it
> so I know the formatting is OK.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-1577
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
>
> 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.
I've attached a new patch to mng-1577. It contains a patch to a couple
of the APT files for the web site. Please feel free to edit it if I have
gotten something wrong. I've built the site with it so I know the
formatting is OK.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-1577
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
MNG-1577
Posted by Ralph Goers <Ra...@dslextreme.com>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jorg Heymans <jh...@apache.org>.
Eric Redmond wrote:
> +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.
+1
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Eric Redmond <er...@gmail.com>.
+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 <ca...@apache.org> 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 <jo...@gmail.com> wrote:
> > On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@iona.com]
Sent: Friday, March 16, 2007 2:29 PM
To: dev@maven.apache.org
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 <jo...@gmail.com> wrote:
> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org For
> >>additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > 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@maven.apache.org For
> >additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Daniel Kulp <da...@iona.com>.
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 <jo...@gmail.com> wrote:
> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/16/07, Kenney Westerhof <ke...@apache.org> wrote:
> 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.
>
maybe we understand different things for unpredictable. If you know
that dependencyManagement only affects your children it's completely
predictable.
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Kenney Westerhof <ke...@apache.org>.
Carlos Sanchez wrote:
> On 3/16/07, Kenney Westerhof <ke...@apache.org> 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
>> >> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 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@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/16/07, Kenney Westerhof <ke...@apache.org> 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> >> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Kenney Westerhof <ke...@apache.org>.
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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
>> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by John Casey <ca...@gmail.com>.
That sounds like a great idea, Mike. It's all academic until we put
something out there.
-j
On 3/16/07, Mike Perham <mp...@gmail.com> wrote:
>
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade? I would prefer to see less
> speculation and more bits. Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread. If no one has problems, this discussion becomes a lot
> shorter. If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
On 16 Mar 07, at 4:02 PM 16 Mar 07, Carlos Sanchez wrote:
> On 3/16/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>>
>>
>> >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
>>
>> I think it simply boils down to what Patrick wrote:
>>
>> "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."
>
>
> one of the points of maven is to worry less about the build, so if i
> get the dependency i need why should i care to add it explicitly?
For any numbers of reasons that you might know of for selecting one
version over another. A binary incompatibility, a feature you want,
because you like odd numbered releases, it doesn't matter what the
reason is, the point is that it is done in practice. When someone
selects that version, it should be honored in the scope of the
project you are building.
> they
> may not care about the version until they upgrade to 2.0.6 and it
> breaks
It will not break if you have explicitly set a version in a child
module. Look at the code.
>
> it's not a matter on how it should work, I agree that the patch is
> good, but not for changing behavior between 2.0.x releases.
We will do as Mike suggested and build something for people to use. I
see no effective change in behavior except in the case where someone
is relying on something they expect but are getting something
different. Without the patch if there is no parity between building
on a leaf and from the top-level. Depending on where you build you
might get different versions. That's fundamentally wrong and a total
crap shoot. If that was explained to users I guarantee they wouldn't
take the crap shoot.
>
> Just think how are you going to handle questions from users, I feel
> more natural ask for "are you using 2.0 or 2.1" than "2.0.5 or 2.0.6
> or ..."
That's not the question to be asking. The question posed to a user
would be "looking at the depMan section, where the version of X is
set to 1.0, what version would you expect to be used in a child
module?" Invariably the answer will be "the one I selected", not,
"the one maven thinks it should give me."
If we applied this patch a year ago when at 2.0.3, would we have
jumped to 2.1? No. When we have fixed the behavior of scopes or
anything else regarding dependency resolution which certainly could
break peoples' builds did we jump to a new version range? No. People
have probably been bitten in those cases because 1) We don't have a
spec, and 2) Hardly anything is documented. This change will help a
lot more people then it may harm, and the people it dings will have
revealed for them inconsistencies that would probably do them more harm.
Jason.
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Ralph Goers <Ra...@dslextreme.com>.
See Below
Brett Porter wrote:
> I'm generally in favour now, but there are a couple of things I'd
> still like to explore first, please bear with me.
>
> Having had the chance to review the new behaviour, I can't see any
> problems with applying it to current builds - I would expect it
> extremely rare to see a managed dependency in a build that also comes
> through transitively at present (and if so, it's probably the version
> you want). So I'm happy to make that exception to include it in a
> point release given the 2.1 code is alpha.
>
> Back tracking just a little bit, though - I want to validate that this
> is the correct implementation method.
>
> - is overloading the meaning of dependency management a problem? I'm
> almost certain we considered doing this around about the 2.0-alphas
> and it was ruled out, though personally I've always thought depMgmt
> should have behaved this way.
I wasn't around for those discussions. However, before I started writing
the patch I searched the archives and never could find where these
decisions were made. Maybe I didn't look hard enough or perhaps there
were conversations off the list.
In any case, dependencyManagement seems to infer to me explicitly
managing dependencies. This patch obviously does that. The behavior
before was more of a suggestion than actual management.
> - is this covering up for a lack of something in the dependency
> mechanism itself? eg., if we add proper conflict resolution and
> different selection mechanisms, would this be needed/removed?
I don't think so. I think Maven does the best it can with transitive
dependencies, but with large projects there are bound to be conflicts
that require a person to make a choice.
>
> My impression is that we'd still want this in the future, but
> improvements to the mechanism itself should reduce the need for it in
> projects. I just thought it was worth considering, since I thought
> it'd been ruled out for other reasons in the past. But other than
> that, I'm happy with it going in now.
In my environment (Maven 1) we use jar overrides to explicitly specify
the version of every artifact to use. Our Configuration Management folks
want it that way. With Maven 2 this just becomes a much better way to
accomplish that since the pom containing the managed dependencies can be
shared much easier than a build.properties file.
>
> As a last point, I'm a little confused about what we are actually
> voting on - as far as I can tell this is already the default behaviour
> on the branch? I must be missing something - what needs to be done?
What you are voting on is allowing it to go into the next release as-is
knowing that it is not 100% backward compatible.
>
> Thanks for getting this done folks - it certainly has been a pest.
You're welcome. It was fun and a great example of how OSS is supposed to
work. I wrote the patch and then Patrick took it into his environment
and corrected a few mistakes, added some more unit tests and then
checked it out on their projects.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
>
> The depMan declarations now channels all transitive dependency to what
> the user specifies, but what we still need in the future when ranges
> become common place is the conflict resolution mechanism as we've
> always thought it would work. Because the overwhelming majority of
> people do not use ranges almost everyone would have their dependencies
> aligned by the dependency management section. The user could still be
> wrong because they may choose a version of a dependency that another
> project has deemed unfit to work with theirs. So the conflict
> resolution strategies will come into play when ranges are used and
> when we have a way to automatically detect real problems between
> versions like using CLIRR/JarDiff in a consistent way.
Yes, but here you have some overlap with jsr 277 and OSGi. As a
developer I wouldn't want to have to specify this stuff in multiple places.
It would be great if the build could fail if incompatible versions are
being used. It would be even better if the classloader allowed multiple
versions of an artifact to exist in the JVM. Imagine that you could
specify a version range that this jar supports in the manifest and that
other jars could specify a version range that they require in their
manifest. Then the classloader could namespace these and choose the best
version match.
>
> So in short this would not affect our long-term strategy of using
> conflict resolution strategies, and in the short term this provides a
> very use conflict resolution strategy which is "use what I say, dammit".
>
>> My impression is that we'd still want this in the future, but
>> improvements to the mechanism itself should reduce the need for it in
>> projects. I just thought it was worth considering, since I thought
>> it'd been ruled out for other reasons in the past. But other than
>> that, I'm happy with it going in now.
>
> I definitely think resolution strategies will be necessary once people
> start actively using ranges. I would hope that at some point in the
> future we could deterministically a user has picked something that
> will not work because we know it's binary incompatible or out of range
> with the versions other projects are using.
Yes, that would be a great help.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 8:34 AM 17 Mar 07, Brett Porter wrote:
> I'm generally in favour now, but there are a couple of things I'd
> still like to explore first, please bear with me.
>
> Having had the chance to review the new behaviour, I can't see any
> problems with applying it to current builds - I would expect it
> extremely rare to see a managed dependency in a build that also
> comes through transitively at present (and if so, it's probably the
> version you want). So I'm happy to make that exception to include
> it in a point release given the 2.1 code is alpha.
>
> Back tracking just a little bit, though - I want to validate that
> this is the correct implementation method.
>
> - is overloading the meaning of dependency management a problem?
> I'm almost certain we considered doing this around about the 2.0-
> alphas and it was ruled out, though personally I've always thought
> depMgmt should have behaved this way.
> - is this covering up for a lack of something in the dependency
> mechanism itself? eg., if we add proper conflict resolution and
> different selection mechanisms, would this be needed/removed?
>
The depMan declarations now channels all transitive dependency to
what the user specifies, but what we still need in the future when
ranges become common place is the conflict resolution mechanism as
we've always thought it would work. Because the overwhelming majority
of people do not use ranges almost everyone would have their
dependencies aligned by the dependency management section. The user
could still be wrong because they may choose a version of a
dependency that another project has deemed unfit to work with theirs.
So the conflict resolution strategies will come into play when ranges
are used and when we have a way to automatically detect real problems
between versions like using CLIRR/JarDiff in a consistent way.
So in short this would not affect our long-term strategy of using
conflict resolution strategies, and in the short term this provides a
very use conflict resolution strategy which is "use what I say, dammit".
> My impression is that we'd still want this in the future, but
> improvements to the mechanism itself should reduce the need for it
> in projects. I just thought it was worth considering, since I
> thought it'd been ruled out for other reasons in the past. But
> other than that, I'm happy with it going in now.
I definitely think resolution strategies will be necessary once
people start actively using ranges. I would hope that at some point
in the future we could deterministically a user has picked something
that will not work because we know it's binary incompatible or out of
range with the versions other projects are using.
>
> As a last point, I'm a little confused about what we are actually
> voting on - as far as I can tell this is already the default
> behaviour on the branch? I must be missing something - what needs
> to be done?
Nothing, I was going to roll it back out if there were any -1s at the
end of the discussion.
>
> Thanks for getting this done folks - it certainly has been a pest.
>
If we get it in, I think folks will be very happy even if they don't
know it ever went in.
Jason.
> - Brett
>
> On 17/03/2007, at 10:38 AM, Brett Porter wrote:
>
>> Mike,
>>
>> Good plan. This is exactly what I was getting at - but I thought
>> we could already do this from the branch that the feature was
>> implemented on? That's what I was intending to use.
>>
>> I'm obviously having trouble grokking the actual implications of
>> this - I was getting the clear impression this was going to break
>> builds, but it seems that may not be the case from the ensuing
>> discussion. So all I really want to do is play with it and see for
>> myself at this point. I have some time later today/tomorrow.
>>
>> - Brett
>>
>> On 17/03/2007, at 7:35 AM, Mike Perham wrote:
>>
>>> The key question to me is: are existing 2.0.5 builds going to be
>>> better or worse after this upgrade? I would prefer to see less
>>> speculation and more bits. Put out a Maven 2.0.6 snapshot that
>>> people
>>> can try with their project and get reports from the people in this
>>> thread. If no one has problems, this discussion becomes a lot
>>> shorter. If they do have problems, at least we have specific
>>> examples
>>> to discuss.
>>>
>>> mike
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Brett Porter <br...@apache.org>.
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I would expect it
extremely rare to see a managed dependency in a build that also comes
through transitively at present (and if so, it's probably the version
you want). So I'm happy to make that exception to include it in a
point release given the 2.1 code is alpha.
Back tracking just a little bit, though - I want to validate that
this is the correct implementation method.
- is overloading the meaning of dependency management a problem? I'm
almost certain we considered doing this around about the 2.0-alphas
and it was ruled out, though personally I've always thought depMgmt
should have behaved this way.
- is this covering up for a lack of something in the dependency
mechanism itself? eg., if we add proper conflict resolution and
different selection mechanisms, would this be needed/removed?
My impression is that we'd still want this in the future, but
improvements to the mechanism itself should reduce the need for it in
projects. I just thought it was worth considering, since I thought
it'd been ruled out for other reasons in the past. But other than
that, I'm happy with it going in now.
As a last point, I'm a little confused about what we are actually
voting on - as far as I can tell this is already the default
behaviour on the branch? I must be missing something - what needs to
be done?
Thanks for getting this done folks - it certainly has been a pest.
- Brett
On 17/03/2007, at 10:38 AM, Brett Porter wrote:
> Mike,
>
> Good plan. This is exactly what I was getting at - but I thought we
> could already do this from the branch that the feature was
> implemented on? That's what I was intending to use.
>
> I'm obviously having trouble grokking the actual implications of
> this - I was getting the clear impression this was going to break
> builds, but it seems that may not be the case from the ensuing
> discussion. So all I really want to do is play with it and see for
> myself at this point. I have some time later today/tomorrow.
>
> - Brett
>
> On 17/03/2007, at 7:35 AM, Mike Perham wrote:
>
>> The key question to me is: are existing 2.0.5 builds going to be
>> better or worse after this upgrade? I would prefer to see less
>> speculation and more bits. Put out a Maven 2.0.6 snapshot that
>> people
>> can try with their project and get reports from the people in this
>> thread. If no one has problems, this discussion becomes a lot
>> shorter. If they do have problems, at least we have specific
>> examples
>> to discuss.
>>
>> mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Mojo to test for MNG-1577 was [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Going through my builds, I'm finding a surprising number of mismatches.
Looks like I've got some significant cleanup to do. Here's some sample
output:
[INFO] [dependency:analyze]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO] Dependency: oracle:adf-faces-api:jar
[INFO] DepMgt : 20.5-STCEA
[INFO] Resolved: 10.1.3.0.4
[INFO] Dependency: javax.servlet:servlet-api:jar
[INFO] DepMgt : 2.3
[INFO] Resolved: 2.4
[INFO] Dependency: junit:junit:jar
[INFO] DepMgt : 3.7
[INFO] Resolved: 3.8.1
[INFO] Dependency: oracle:adf-faces-impl:jar
[INFO] DepMgt : 20.5-STCEA
[INFO] Resolved: 10.1.3.0.4
[INFO] Dependency: commons-lang:commons-lang:jar
[INFO] DepMgt : 1.0
[INFO] Resolved: 2.3
[INFO] Dependency: commons-digester:commons-digester:jar
[INFO] DepMgt : 1.5
[INFO] Resolved: 1.7
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Saturday, March 17, 2007 1:14 AM
To: Maven Developers List
Subject: RE: Mojo to test for MNG-1577 was [vote] MNG-1577 as the
default behavior
I meant to say:
It currently skips snapshots but any released artifacts that
don't match will potentially cause a problem with a build with MNG-1577
applied.
I'm hoping that we can get this fixed up, release the analyze test and
make MNG-1577 the default behavior. We can not only describe it clearly
in the release notes, but now we'll have a tool to have people run in
2.0.5 to identify issues BEFORE they upgrade.
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Saturday, March 17, 2007 1:11 AM
To: Maven Developers List
Subject: Mojo to test for MNG-1577 was [vote] MNG-1577 as the default
behavior
I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently skips snapshots but any released artifacts that
don't match will cause a problem.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
Mike,
Good plan. This is exactly what I was getting at - but I thought we
could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of this
- I was getting the clear impression this was going to break builds,
but it seems that may not be the case from the ensuing discussion. So
all I really want to do is play with it and see for myself at this
point. I have some time later today/tomorrow.
- Brett
On 17/03/2007, at 7:35 AM, Mike Perham wrote:
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade? I would prefer to see less
> speculation and more bits. Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread. If no one has problems, this discussion becomes a lot
> shorter. If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Mojo to test for MNG-1577 was [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I meant to say:
It currently skips snapshots but any released artifacts that
don't match will potentially cause a problem with a build with MNG-1577
applied.
I'm hoping that we can get this fixed up, release the analyze test and
make MNG-1577 the default behavior. We can not only describe it clearly
in the release notes, but now we'll have a tool to have people run in
2.0.5 to identify issues BEFORE they upgrade.
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Saturday, March 17, 2007 1:11 AM
To: Maven Developers List
Subject: Mojo to test for MNG-1577 was [vote] MNG-1577 as the default
behavior
I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently skips snapshots but any released artifacts that
don't match will cause a problem.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
Mike,
Good plan. This is exactly what I was getting at - but I thought we
could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of this
- I was getting the clear impression this was going to break builds,
but it seems that may not be the case from the ensuing discussion. So
all I really want to do is play with it and see for myself at this
point. I have some time later today/tomorrow.
- Brett
On 17/03/2007, at 7:35 AM, Mike Perham wrote:
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade? I would prefer to see less
> speculation and more bits. Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread. If no one has problems, this discussion becomes a lot
> shorter. If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Mojo to test for MNG-1577 was [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently skips snapshots but any released artifacts that
don't match will cause a problem.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior
Mike,
Good plan. This is exactly what I was getting at - but I thought we
could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of this
- I was getting the clear impression this was going to break builds,
but it seems that may not be the case from the ensuing discussion. So
all I really want to do is play with it and see for myself at this
point. I have some time later today/tomorrow.
- Brett
On 17/03/2007, at 7:35 AM, Mike Perham wrote:
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade? I would prefer to see less
> speculation and more bits. Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread. If no one has problems, this discussion becomes a lot
> shorter. If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Brett Porter <br...@apache.org>.
Mike,
Good plan. This is exactly what I was getting at - but I thought we
could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of this
- I was getting the clear impression this was going to break builds,
but it seems that may not be the case from the ensuing discussion. So
all I really want to do is play with it and see for myself at this
point. I have some time later today/tomorrow.
- Brett
On 17/03/2007, at 7:35 AM, Mike Perham wrote:
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade? I would prefer to see less
> speculation and more bits. Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread. If no one has problems, this discussion becomes a lot
> shorter. If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Mike Perham <mp...@gmail.com>.
The key question to me is: are existing 2.0.5 builds going to be
better or worse after this upgrade? I would prefer to see less
speculation and more bits. Put out a Maven 2.0.6 snapshot that people
can try with their project and get reports from the people in this
thread. If no one has problems, this discussion becomes a lot
shorter. If they do have problems, at least we have specific examples
to discuss.
mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/16/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
>
> >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
>
> I think it simply boils down to what Patrick wrote:
>
> "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."
one of the points of maven is to worry less about the build, so if i
get the dependency i need why should i care to add it explicitly? they
may not care about the version until they upgrade to 2.0.6 and it
breaks
it's not a matter on how it should work, I agree that the patch is
good, but not for changing behavior between 2.0.x releases.
Just think how are you going to handle questions from users, I feel
more natural ask for "are you using 2.0 or 2.1" than "2.0.5 or 2.0.6
or ..."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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
I think it simply boils down to what Patrick wrote:
"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."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/16/07, John Casey <ca...@gmail.com> 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 <ca...@apache.org> wrote:
> >
> > On 3/16/07, John Casey <ca...@gmail.com> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by John Casey <ca...@gmail.com>.
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 <ca...@apache.org> wrote:
>
> On 3/16/07, John Casey <ca...@gmail.com> 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 <ja...@maven.org> 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> > > >> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > 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@maven.apache.org
> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > 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@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] MNG-1577 as the default behavior
Posted by Patrick Schneider <ps...@gmail.com>.
On 3/16/07, Carlos Sanchez <ca...@apache.org> wrote:
>
> On 3/16/07, John Casey <ca...@gmail.com> 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
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/16/07, John Casey <ca...@gmail.com> 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 <ja...@maven.org> 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> > >> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > 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@maven.apache.org
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by John Casey <ca...@gmail.com>.
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 <ja...@maven.org> 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> >> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
>> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Mar 07, at 12:31 AM 17 Mar 07, Ralph Goers wrote:
> Jason van Zyl wrote:
>>
>> 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.
>>
> Jason,
>
> I would take the override option off the table.
>
I am still hoping this will go in as the default behavior and I would
honestly be surprised if anyone disagrees after looking at the old
versus new behavior. That said, if it gets vetoed then I was thinking
a property in the POM that could get picked up.
> When I wrote the patch for MNG-1577 I added an override element to
> the dependencyManagement element in the pom so backward
> compatibility could be preserved. However, I realized later that
> that change itself would cause problems. This is because adding
> anything to the pom really requires the xsd to be updated. In turn,
> this should require the version in the pom to be changed since it
> would be confusing to make a modification without updating the xsd
> version. So in addition to having to add <override>true</override>
> you would also have to change your pom version to something like
> 4.0.1 and reference a different xsd.
> Next in 2.1 presumably this element would be removed, so all the
> poms where this was specified might not work any longer. But with
> so many poms in a maven repository you can't really do that. 2.1
> would be forced to at least tolerate the element so that the builds
> would work. Of course, what would you do in 2.1 if you encountered
> a pom with <override>false</override> explicitly specified?
>
> Frankly, this seems worse than breaking compatibility in 2.0.x.
I agree. It would probably not be worth putting it in if it's not the
default because no one will read anything and most likely will not
enable the behavior.
>
> Given that, the only other alternatives seem to be system
> properties or adding it to the settings. Neither of these is
> particularly attractive because if someone tries to run the build
> and doesn't know to have the option set then they will get
> different build results.
Indeed. I'll make a build this weekend and let people try it out and
hope that we'll put it into 2.0.6 and give it the proper label of a
corrective of a fundamental defect.
Jason.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Ralph Goers <Ra...@dslextreme.com>.
Jason van Zyl wrote:
>
> 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.
>
Jason,
I would take the override option off the table.
When I wrote the patch for MNG-1577 I added an override element to the
dependencyManagement element in the pom so backward compatibility could
be preserved. However, I realized later that that change itself would
cause problems. This is because adding anything to the pom really
requires the xsd to be updated. In turn, this should require the version
in the pom to be changed since it would be confusing to make a
modification without updating the xsd version. So in addition to having
to add <override>true</override> you would also have to change your pom
version to something like 4.0.1 and reference a different xsd.
Next in 2.1 presumably this element would be removed, so all the poms
where this was specified might not work any longer. But with so many
poms in a maven repository you can't really do that. 2.1 would be forced
to at least tolerate the element so that the builds would work. Of
course, what would you do in 2.1 if you encountered a pom with
<override>false</override> explicitly specified?
Frankly, this seems worse than breaking compatibility in 2.0.x.
Given that, the only other alternatives seem to be system properties or
adding it to the settings. Neither of these is particularly attractive
because if someone tries to run the build and doesn't know to have the
option set then they will get different build results.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
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@gmail.com [mailto:carlossg@gmail.com] 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
>>>> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> 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@maven.apache.org For
>>> additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>> additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> 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@maven.apache.org For
> additional
> commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@gmail.com [mailto:carlossg@gmail.com] 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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org For
> >> additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > 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@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ja...@maven.org> 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 <jo...@gmail.com> wrote:
> >> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
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 <jo...@gmail.com> wrote:
>> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
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 <jo...@gmail.com> wrote:
> On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 3/16/07, Brett Porter <br...@apache.org> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Andrew Williams <an...@handyande.co.uk>.
+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@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
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@gmail.com]
> 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 <ps...@gmail.com> 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 <ke...@apache.org> 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@maven.apache.org For
>
>>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> ------------------------------------------------------------------
>>>> --- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>>> additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
>>> additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@gmail.com]
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 <ps...@gmail.com> 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 <ke...@apache.org> 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@maven.apache.org For
> > >> additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > additional commands, e-mail: dev-help@maven.apache.org
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by John Casey <ca...@gmail.com>.
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 <ps...@gmail.com> 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 <ke...@apache.org> 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@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [vote] MNG-1577 as the default behavior
Posted by Patrick Schneider <ps...@gmail.com>.
+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 <ke...@apache.org> 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@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] MNG-1577 as the default behavior
Posted by Kenney Westerhof <ke...@apache.org>.
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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Brett Porter <br...@apache.org>.
On 17/03/2007, at 1:37 AM, Jason van Zyl wrote:
>> 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.
Poor choice of words perhaps, but I wanted to be clear that this is a
behaviour change, not a bugfix. I think we can possibly make an
exception in this case, but we generally shouldn't be doing that in a
point release.
>>
>> 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.
Ok, I think I can accept that it's bad that we make people choke down
alpha code to get this. But I think it's bad that we got into that
scenario too, and it's probably time to start mapping out an actual
2.1 release instead of more point releases beyond 2.0.6.
I'll address the issue itself in another mail.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Ralph Goers <Ra...@dslextreme.com>.
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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Brett Porter <br...@apache.org>.
-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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Nathan Beyer <nd...@apache.org>.
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 <mp...@gmail.com> 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 <ca...@apache.org> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Mike Perham <mp...@gmail.com>.
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 <ca...@apache.org> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ja...@maven.org> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@maven.org]
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default
behavior
Posted by Trygve Laugstøl <tr...@apache.org>.
Jason van Zyl wrote:
>
> On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
>
>> 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.
>>
>> It seems that this discussion has settled down by now and I'm fine
>> with the conclusion you guys have come up with.
>>
>> However, I would like to make one point. I see that the discussion has
>> been confused with
>>
>> silly/dump/whatever dependency resolution
>>
>> vs
>>
>> silly/dump/whatever, but *predictable*, dependency resolution.
>>
>> If this patch would in any way change dumb, silly, retarded, awkward
>> *predictable* dependency resolution I would have voted -1 to it.
>
> It's entirely not predictable. Anyone asked how they thought depMan
> works would answer in accordance with the work in MNG-1577. They do not
> expect the behavior that is there before it.
>
>> We cannot change the behavior in a bugfix release, no matter how
>> trivial and "sane" it will be. We just can't do it. Adding an option
>> to enable the good method would be a way around, and it *might* be
>> done in a 2.1 release as it would make life better for everyone, but
>> even then we're violating the rules of never changing behavior.
>>
>> I would like comments on this *philosophy*, not the issue in question.
>
> In theory I would agree. But we've gone against this several times.
When?
In this case there was talk about changing behavior that would
potentially break existing builds as it wasn't determined if it was
predictable or not.
>>
>> A workaround for this would be to change the XSD and say that the XSD
>> specifies the behavior which is the only thing that makes sense to me.
>> The model version should imply behavior.
>
> The problem here is that a static model cannot imply the behavior of a
> dynamic system.
>
> In this case the XSD would be exactly the same would describe nothing
> regarding how one dependency is selected over another. The static model
> cannot reflect dynamic nature of artifact resolution.
>
> Unless you are referring to something in the model which said what it
> was going to do and as we discussed (Ralph brought it up) that it would
> be a maintenance nightmare. What we would ultimately have to express in
> this case is that we were wrong and not providing the behavior that
> anyone expects and that we had corrected it. Cumbersome instead of
> providing a default mechanism that does the right thing. In this case
> we're fortunate that it will bring far more benefit then harm. I think
> we've done the right thing in this case and the result will be users
> will be better off.
Ok, using the model version is quite possibly wrong but there
could/should be a field indicating the expected behavior making room for
these kind of changes. An alternative is to take a look at the required
Maven version to use that as pointer to which behavior to use.
Leaving the specifics of this issue, imagine what will happen if the
plan of very frequent (<1 month) release intervals will be implemented
and within the next two years there will be 20 Maven releases (all most
likely with 2 as it's major version). If the behavior suddenly changes
randomly between point releases people will suffer way more as everyone
in a team has to standardize on a certain Maven version and then we've
suddenly lost a lot of the things we wanted to gain by putting a version
field on everything. By having such a high number of releases you can be
sure people will use the different versions all the time.
I cannot stress the need to keep the behavior *very* stable. A dump (but
not wrong) choice made by a developer should not be allowed to suddenly
break (clumsy) but working builds.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
Posted by Jason van Zyl <ja...@maven.org>.
On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
> 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.
>
> It seems that this discussion has settled down by now and I'm fine
> with the conclusion you guys have come up with.
>
> However, I would like to make one point. I see that the discussion
> has been confused with
>
> silly/dump/whatever dependency resolution
>
> vs
>
> silly/dump/whatever, but *predictable*, dependency resolution.
>
> If this patch would in any way change dumb, silly, retarded,
> awkward *predictable* dependency resolution I would have voted -1
> to it.
It's entirely not predictable. Anyone asked how they thought depMan
works would answer in accordance with the work in MNG-1577. They do
not expect the behavior that is there before it.
> We cannot change the behavior in a bugfix release, no matter how
> trivial and "sane" it will be. We just can't do it. Adding an
> option to enable the good method would be a way around, and it
> *might* be done in a 2.1 release as it would make life better for
> everyone, but even then we're violating the rules of never changing
> behavior.
>
> I would like comments on this *philosophy*, not the issue in question.
In theory I would agree. But we've gone against this several times.
>
> A workaround for this would be to change the XSD and say that the
> XSD specifies the behavior which is the only thing that makes sense
> to me. The model version should imply behavior.
The problem here is that a static model cannot imply the behavior of
a dynamic system.
In this case the XSD would be exactly the same would describe nothing
regarding how one dependency is selected over another. The static
model cannot reflect dynamic nature of artifact resolution.
Unless you are referring to something in the model which said what it
was going to do and as we discussed (Ralph brought it up) that it
would be a maintenance nightmare. What we would ultimately have to
express in this case is that we were wrong and not providing the
behavior that anyone expects and that we had corrected it. Cumbersome
instead of providing a default mechanism that does the right thing.
In this case we're fortunate that it will bring far more benefit then
harm. I think we've done the right thing in this case and the result
will be users will be better off.
Jason.
>
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Behavior philosophy. Was: Re: [vote] MNG-1577 as the default behavior
Posted by Trygve Laugstøl <tr...@apache.org>.
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.
It seems that this discussion has settled down by now and I'm fine with
the conclusion you guys have come up with.
However, I would like to make one point. I see that the discussion has
been confused with
silly/dump/whatever dependency resolution
vs
silly/dump/whatever, but *predictable*, dependency resolution.
If this patch would in any way change dumb, silly, retarded, awkward
*predictable* dependency resolution I would have voted -1 to it. We
cannot change the behavior in a bugfix release, no matter how trivial
and "sane" it will be. We just can't do it. Adding an option to enable
the good method would be a way around, and it *might* be done in a 2.1
release as it would make life better for everyone, but even then we're
violating the rules of never changing behavior.
I would like comments on this *philosophy*, not the issue in question.
A workaround for this would be to change the XSD and say that the XSD
specifies the behavior which is the only thing that makes sense to me.
The model version should imply behavior.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Ralph Goers <Ra...@dslextreme.com>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [vote] MNG-1577 as the default behavior
Posted by Cabasson Denis <de...@insee.fr>.
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@venisse.net]
> 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@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Emmanuel Venisse <em...@venisse.net>.
+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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Kenney Westerhof <ke...@apache.org>.
Fabrizio Giustina wrote:
> A big +1 for making it a default
>
> I am also +1 on adding this to 2.0.6: for me this would just mean
> removing tons of unneeded/workaround dependency from tons of poms. I
> agree that, although consistent for some time, this behavior
> introduces so much problems that should be considered a bug and not a
> behavior.
>
> Since anyway this is a important change and so many people are worried
> about it, I would just propose to label 2.0.6 as 2.1 (trunk will
> become 2.2). That should the reason for version numbers, right? We
> shouldn't wait for trunk to be ready to name a release 2.1 and if we
> introduce a change we should label it appropriately...
-1, because with this next release as 2.1, the 2.0 branch will no longer
be supported. What you're saying is basically 'we name the next release of
'2.0.x' '2.1''. What's the point of that? That's just the type of thing
that happens in commercial environments to satisfy PR and management.
So dropping 2.0.x and making 2.0.6 the next 2.1 is not an option.
Second option would be to keep 2.0.x in place and make 2.0.5 the starting
point of 2.1, with this patch in place. That would mean we still
have to support 2.0.x, and 2.1, which is no different from 2.0.x
except for MNG-1577, and the 2.1, what is now 2.1.
That's not an option either, since this little issue, although higly debated,
does not warrant a minor version update. yes, it changes behaviour. But fixing
a bug also changes behaviour.
Third option: keep 2.0.x buggy and only apply to 2.1.
Fourth option: apply to both 2.0.x and 2.1.
My vote goes to 4, after ofcourse we've tested a release candidate of 2.0.6.
-- Kenney
>
> fabrizio
>
>
>
> On 3/16/07, Jason van Zyl <ja...@maven.org> 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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] MNG-1577 as the default behavior
Posted by Fabrizio Giustina <fg...@apache.org>.
A big +1 for making it a default
I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should be considered a bug and not a
behavior.
Since anyway this is a important change and so many people are worried
about it, I would just propose to label 2.0.6 as 2.1 (trunk will
become 2.2). That should the reason for version numbers, right? We
shouldn't wait for trunk to be ready to name a release 2.1 and if we
introduce a change we should label it appropriately...
fabrizio
On 3/16/07, Jason van Zyl <ja...@maven.org> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org