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