On Oct 5, 2010, at 10:04 AM, Mark Hobson wrote:
> On 5 October 2010 14:31, Baptiste MATHUS <[email protected]> wrote:
>> +1.
>> It'd confirm what I checked yesterday (see my other mail). I was having
>> problem with XML parser due to a different classpath ordering inside
>> surefire between m2.2.1 and m3.
>>
>> As Olivier said, it's true it's bad to rely on classpath ordering, but I'm
>> wondering if something could be done so that classpath is always calculated
>> the same way (or so is ordered the same) between m2/3. In fact, I fear this
>> difference could cause some compatibility problems between m2&3 that will
>> refrain some users from migrating.
>>
>> I guess this is something inside aether that was done on purpose, maybe to
>> clean things that might have specially been done in m2.
>
> It's not actually the classpath order that I'm relying on, it's the
> order of dependencies on the classpath after they've been sorted by
> ProjectSorter, which should be deterministic.
>
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>
> I've just had a look at the log between 2.2.1 and 3.0 for
> ProjectSorter [1] and there appears to be quite a few changes. I
> thought its testcase was missing until I found it elsewhere [2] - we
> may want to align its package. Is anyone aware of any potentially
> breaking changes that have been made to ProjectSorter? It's
> definitely returning slightly different results than 2.2.1.
>
> Mark
>
> [1]
> http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java
> [2]
> http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/test/java/org/apache/maven/execution/ProjectSorterTest.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
