On 5 October 2010 15:54, Jason van Zyl <ja...@sonatype.com> wrote:
> a DAG which is toposorted is naturally unordered for elements at the same
> level in a graph. The set is deterministic, the order of that set is not.
> Relying on any ordering for something that is naturally unordered is not
> really a great idea.
>
> For visualization I would agree that from one rendering to another it should
> appear the same and most graphing libraries provide a sorting attribute to
> ensure this. A deterministic ordering across the resolution for a project
> would be tricky. You're fighting against the ordering the user has provided
> in the POMs, and what you want to sort against. How you mix those needs to be
> defined. I don't think this is actually much easier even within the reactor.
> Do you use the module order? Do you build out the list from the first
> element? The last element? Alphabetically? Do you take an element's order
> where the conflict was won? The conflict in one case may be won in one part
> of the tree, and somewhere else under different conditions. If that's the
> element you rely on then it's placement just changed as a result of conflict
> resolution and you're punched again.
>
> You could try and simplify the whole strategy by ordering the resolved set.
> If the order truly shouldn't matter then if you alphabetized, as one example,
> the final output would always be consistent. But this negates any ordering
> the user has made. Slight changes in resolution change the ordering is the
> problem and it will change as the underlying tree changes and the process by
> which it is transformed into a graph.
>
> I would avoid this completely and if you need some fudge factor, then make a
> utility that might do something like:
>
> DependencyList list = new DependencySetAsList( set )
> .move( gav0 ).toFront()
> .move( gav1 ).after( gav0 );
>
> And possibly allow some ordering textually if you want to put it in a POM:
>
> <classpath>${gav0}${gav1}${remainder}</classpath>
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
