On 17 Mar 07, at 8:34 AM 17 Mar 07, Brett Porter wrote:
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I would expect it
extremely rare to see a managed dependency in a build that also
comes through transitively at present (and if so, it's probably the
version you want). So I'm happy to make that exception to include
it in a point release given the 2.1 code is alpha.
Back tracking just a little bit, though - I want to validate that
this is the correct implementation method.
- is overloading the meaning of dependency management a problem?
I'm almost certain we considered doing this around about the 2.0-
alphas and it was ruled out, though personally I've always thought
depMgmt should have behaved this way.
- is this covering up for a lack of something in the dependency
mechanism itself? eg., if we add proper conflict resolution and
different selection mechanisms, would this be needed/removed?
The depMan declarations now channels all transitive dependency to
what the user specifies, but what we still need in the future when
ranges become common place is the conflict resolution mechanism as
we've always thought it would work. Because the overwhelming majority
of people do not use ranges almost everyone would have their
dependencies aligned by the dependency management section. The user
could still be wrong because they may choose a version of a
dependency that another project has deemed unfit to work with theirs.
So the conflict resolution strategies will come into play when ranges
are used and when we have a way to automatically detect real problems
between versions like using CLIRR/JarDiff in a consistent way.
So in short this would not affect our long-term strategy of using
conflict resolution strategies, and in the short term this provides a
very use conflict resolution strategy which is "use what I say, dammit".
My impression is that we'd still want this in the future, but
improvements to the mechanism itself should reduce the need for it
in projects. I just thought it was worth considering, since I
thought it'd been ruled out for other reasons in the past. But
other than that, I'm happy with it going in now.
I definitely think resolution strategies will be necessary once
people start actively using ranges. I would hope that at some point
in the future we could deterministically a user has picked something
that will not work because we know it's binary incompatible or out of
range with the versions other projects are using.
As a last point, I'm a little confused about what we are actually
voting on - as far as I can tell this is already the default
behaviour on the branch? I must be missing something - what needs
to be done?
Nothing, I was going to roll it back out if there were any -1s at the
end of the discussion.
Thanks for getting this done folks - it certainly has been a pest.
If we get it in, I think folks will be very happy even if they don't
know it ever went in.
Jason.
- Brett
On 17/03/2007, at 10:38 AM, Brett Porter wrote:
Mike,
Good plan. This is exactly what I was getting at - but I thought
we could already do this from the branch that the feature was
implemented on? That's what I was intending to use.
I'm obviously having trouble grokking the actual implications of
this - I was getting the clear impression this was going to break
builds, but it seems that may not be the case from the ensuing
discussion. So all I really want to do is play with it and see for
myself at this point. I have some time later today/tomorrow.
- Brett
On 17/03/2007, at 7:35 AM, Mike Perham wrote:
The key question to me is: are existing 2.0.5 builds going to be
better or worse after this upgrade? I would prefer to see less
speculation and more bits. Put out a Maven 2.0.6 snapshot that
people
can try with their project and get reports from the people in this
thread. If no one has problems, this discussion becomes a lot
shorter. If they do have problems, at least we have specific
examples
to discuss.
mike
--------------------------------------------------------------------
-
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]
