This is an awesome question!
I have tons of ideas in the area, but decided to first make Mercury
compliant with Maven2 scoping and make it works in Maven3, then we can
move forward - see below.
Gilles Scokart wrote:
Cool,
One more question : how do you handle scopes?
In ivy, we have something called 'configuration' mapping in which you
can configure that when you ask for runtime dependency, you have to
take the compile+runtime transitive dependencies. In maven, this
mapping is hard-coded.
I find an idea of "configuration" very cool, so I tried to make Mercury
as indifferent to the scope impl. as possible and plan to implement
similar concept as soon as Maven3 is stabilized. Developers should be
free to define their scopes and scoping rules, and it's half-way there.
Also, in maven when you are resolving dependencies, you resolve all
scopes at once. In ivy, we download each meta-file file once, but we
make one resolution per configuration (equivalent to scope).
How is it handled in Mercury?
Same idea: the call is made to resolve dependencies in a particular
scope, so what I call "dirty tree" is in essence "scoped dirty tree". As
a result of that - client wind up with a solution per each scope it asks
for.
Each metadata is downloaded only once and cached for subsequent
accesses. Maven is different as it has a concept of a SNAPSHOT, LATEST
and RELEASE versions, these concepts clash with the idea of a cache and
result is so called "repository update policy" which in it's default
implementation, defines cached metadata TTL per remote repository.
Thanks,
Oleg
Gilles Scokart
2008/12/22 Oleg Gusakov <oleg.subscripti...@gmail.com>:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
