2008/12/20 Oleg Gusakov <oleg.subscripti...@gmail.com>: >>> >>> Also, how do you solve the problem that different version might have >>> dependency different tree? Did you build the complete "dirty tree" >>> (meanings that you look up for transitive dependencies of all old >>> versions that will probably not be selected, an then resolve big the >>> equations globaly), or did you proceeds somehow iteratively (resolving >>> some equations to know which part of the tree to "dirty tree" to >>> extends, update the dirty tree with dependencies of only resolved >>> revisions, update the equations, solve equations again, ...). >>> > > I create a full "dirty tree" for every version, then use them all in the > generated system of inequavions. I tried to do some iterative optimizations > in the process, but SAT does better job and it is also defined to work on > the huge problems - ours is a toy for it. >
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. > Manual intervention also proved turned sour because Mercury is flexible to > allow different selection policies: default is "shallowest", then "newest", > but it's all configurable with a set of comparators, passed to the solver. > And if the need comes - we can cover a lot of exotic variations, the first > one coming to mind - "maven2 compatibility mode" comparator. Maven2 selects > the first version on the same level, Mercury - the newest. An Ivy like function might be nice as well.;-) But there is a piece that I miss. How did you handle conlicts? I means not multiple possible solution, but real conflicts. This seems to be incompatible with a strtict system of constraints. If I take the example : A depends on B:1 and C:1 B:1 depends on C:2. I think maven will take C:1 (first levle in the dependency tree), Ivy would by default take C:2 (because it resolve conflicts by taking the 'latest' version). What will mercury do? My understanding is that the SAT resolution will say there is no solution. What practical solution do you propose for Mercury users? Do you ask them to fill a DependencyManagment section for the the module that are in conflicts ? Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
