Branching the m3 vote thread: On 5 October 2010 16:22, Mark Hobson <[email protected]> wrote: > Sorry, I don't think I was clear enough before. It's not the ordering > of elements at the same level that's a problem, it's that the element > order is wrong. I was also meaning deterministic with regard from > m2.2.1 to m3. > > I'm relying on processing dependencies in dependency order, i.e. the > order returned from ProjectSorter. I have a project of 100+ internal > dependencies that is coming back in the wrong order using m3's > ProjectSorter, but it is correct under m2.2.1's version. I have > checked the dependency tree using m3's -X and a dependency of tree > depth 2 is appearing *before* a dependency of tree depth 8 in the > sorted list, which is meant to be in accumulating dependency order.
I've taken a quick look at ProjectSorter in the debugger and it looks like it's skipping vertexes where versions don't match. For example, if A depends on B:1.0 but B is resolved to 1.1 (via resolution or management) then A->B:1.0 is lost. One suspect could be isSpecificVersion which returns true for 1.0, which isn't a specific version like [1.0], so this vertex gets lost as B:1.0 doesn't exist. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
