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 <[EMAIL PROTECTED]> 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]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
