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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------
--- To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
- To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
