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