Hi Oleg, That sounds all good. One of the issues that my proposal didn't cover, which I think is worth exploring, is that of conflict resolver scope. The potential problem I see is that as soon as we allow the conflict resolution strategy to be configurable, we introduce the possibility of having two projects within the dependency graph that specify different strategies.
There are two obvious solutions to this: 1) the dominant strategy takes precedence and resolves the entire graph; 2) the strategies are applied to their respective sub-graphs. Note that the former option also introduces the perverse requirement of conflict resolver conflict resolvers ;) I think that the second option would result in the most correct resolution, although naturally it would be harder to implement. What do you think? Has there been any decision on how to specify conflict resolvers in the pom yet? I covered a few potential syntaxes in my proposal. I assume that custom conflict resolvers can be plugged in via extensions? I'd love to give Mercury a test-drive - is there any code publicly available yet? Any ETA on getting this into trunk? Keep up the good work :) Cheers, Mark 2008/8/6 Oleg Gusakov <[EMAIL PROTECTED]>: > Excellent! > > Mark - regarding you document: I abstracted conflict resolution even more: > one of the inputs to the DependencyBuilder is a List<Comparator> - good old > java comparators that can compare tree nodes. When tree is being created, > all tree nodes are sorted by these comparators and results are added to SAT > equations. > > Two important things: List - order of Comparators is very important - if you > apply newest first, then depth - results might be different from depth > first, then newest. They compare not just GAVs, but real tree nodes, that > gives them insight into tree structure. > > I implemented the two mentioned policies: nearest/farthest and newest/oldest > and we can configure them as you indicated. But we also need an option to > allow users construct their own comparator list. > > What do you think? > > Thanks, > Oleg > > Mark Hobson wrote: >> >> Hi guys, >> >> I'm happy to take a look at the new Mercury code and make sure it >> supersedes my conflict resolvers patch. Any pointers to documentation >> and code would be appreciated. >> >> Cheers, >> >> Mark >> >> 2008/8/6 Jason van Zyl <[EMAIL PROTECTED]>: >> >>> >>> Mark/Oleg, >>> >>> Just wanted to make sure you guys were synced as Mark has written this: >>> >>> http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers >>> >>> And I know the plug points in Mercury provide by SAT4J deal with most of >>> these but just trying to guide things into the same funnel. >>> >>> On 5-Aug-08, at 4:26 PM, Jason van Zyl wrote: >>> >>> >>>> >>>> Oleg, >>>> >>>> Not sure if you've seen this, but could you take a crack at integrating >>>> this, if applicable, into the Mercury write up? >>>> >>>> >>>> >>>> http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder, Apache Maven >>>> jason at sonatype dot com >>>> ---------------------------------------------------------- >>>> >>>> the course of true love never did run smooth ... >>>> >>>> -- Shakespeare >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> jason at sonatype dot com >>> ---------------------------------------------------------- >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
