Gilles Scokart wrote:
I have no doubt that SAT can resolve huge system of constraints, but I
fear that building the dirty tree migh be very heavy. You may have to
download and parse plenty of pom (or other meta-data files).
BTW, when you download a pom, did you also download the jar, or did
you only download the jar whan you know you select the right version.
Mercury dependency resolver operates purely on the "light" metadata.
Light in a sense that is does not require full blown POM to do it's job.
It only needs:
1). complete content of the <dependency/> element: GAV, classifier,
type, scope, optionality, inclusions/exclusions.
2). for each GAV it needs a list of dependencies in the format #1
This has been externalized into an interface, and the only
implementation (for now :) is Maven3 project builder that reads and
interprets POMs, returning back the processed dependencies.
This - btw - also opens a road towards separating dependency
declarations out of POM to any other storage mechanism - I remember
there was a discussion about it. So - this possibility exists.
Back to the question: Mercury calculates all the metadata (and also
fills in the metadata cache, so that on next invocation all metadata is
readily available). And returns back the resolved classpath as a list of
metadata objects. There is another call, that takes that list and
actually reads the binaries from the repositories.
mercury-plexus component combines the two calls into one:
resolveConflicts(). It first resolves the conflicts on the metadata
level, them reads actual binaries, so that returned metadata always
points to local file system for binary.
An Ivy like function might be nice as well.;-)
Several aspects to this remark :)
* default Mercury behaves like that - see "optimization policy" in my
previous post.
* it is possible to implement a different dependency reader, so that we
change completely how dependencies are stored
* it is possible to access any other repository (GEM, CPAN), as soon as
there is a Mercury-compliant implementation. Mercury changed the way
repository behaves in order to allow this - it accepts GAV-only calls,
makes all the mappings inside, and returns metadata objects. Also see
http://docs.codehaus.org/display/MAVEN/Mercury
Thanks,
Oleg
