On 3/16/07, John Casey <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> On 3/16/07, John Casey <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
