See Below
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.
I wasn't around for those discussions. However, before I started writing
the patch I searched the archives and never could find where these
decisions were made. Maybe I didn't look hard enough or perhaps there
were conversations off the list.
In any case, dependencyManagement seems to infer to me explicitly
managing dependencies. This patch obviously does that. The behavior
before was more of a suggestion than actual management.
- 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?
I don't think so. I think Maven does the best it can with transitive
dependencies, but with large projects there are bound to be conflicts
that require a person to make a choice.
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.
In my environment (Maven 1) we use jar overrides to explicitly specify
the version of every artifact to use. Our Configuration Management folks
want it that way. With Maven 2 this just becomes a much better way to
accomplish that since the pom containing the managed dependencies can be
shared much easier than a build.properties file.
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?
What you are voting on is allowing it to go into the next release as-is
knowing that it is not 100% backward compatible.
Thanks for getting this done folks - it certainly has been a pest.
You're welcome. It was fun and a great example of how OSS is supposed to
work. I wrote the patch and then Patrick took it into his environment
and corrected a few mistakes, added some more unit tests and then
checked it out on their projects.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
