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. 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?
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
