On Wed, Dec 14, 2011 at 1:52 PM, Daz DeBoer
<[email protected]> wrote:
> Thanks for the input.

Marvelous discussion by itself, how 2 (almost 3) build systems are
incapable of recognizing that the whole 'dependency resolution' things
is bogus, almost from the beginning to the end. With non-trivial
systems, where most of 'real' developers live, it is purely
coincidental whether the build system make an "accurate enough" guess
of what you have in mind.

Simplified Example (in real world a magnitude more complex);
A dependsOn B[1.1]
A dependsOn C[1.0]
B[1.1] dependsOn C[1.1]

Now, is the correct resolution of C 1.0 or 1.1 ?
You could on one hand argue that 1.1 is newer, and should be
compatible with 1.0, and hence be chosen. But you could also argue
that A have an explicit dependency on 1.0, and "Why is That?". That
could either be that something in 1.1 works incorrectly for A, OR that
something in B didn't work and an upgrade to a newer B was done
without realizing that it also had a newer version of C coming along.

This is not contrived, even for a 3 "deployment container" (Jars for
those of you who doesn't realize that classes are not versioned)
setup. Now sit back and think what happens when this is 100 jars and
then for 1000. Answer; complexity is not linear but exponential or
worse. In our company, they have swapped out the default Ivy conflict
resolver to look at "distance to declaration", and the 'nearest'
always wins. Is that right? No, just for us it wins 'correctly' a few
more times than the default.

The focus should not lie in giving us a better dependency resolution
system, BUT better tools to "evaluate", "select" and "compare" the
many choices, preferably at class level (walk the call trees and have
all versions available). That is non-trivial, and I don't expect
anyone to really solve it, but it is eventually the only way in our
current state of the world.

I was a long time ago a strong proponent of transitive dependency
resolution, at the long dead Apache Avalon project. I have since then
smartened up, and gotten away from my addiction. Zero resolution takes
me more time to manage and a lot less to debug. I am better off.


Hope I have not ruined your fun...

Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to