Jason van Zyl wrote:
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.
Yes, but here you have some overlap with jsr 277 and OSGi. As a
developer I wouldn't want to have to specify this stuff in multiple places.
It would be great if the build could fail if incompatible versions are
being used. It would be even better if the classloader allowed multiple
versions of an artifact to exist in the JVM. Imagine that you could
specify a version range that this jar supports in the manifest and that
other jars could specify a version range that they require in their
manifest. Then the classloader could namespace these and choose the best
version match.
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.
Yes, that would be a great help.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
