maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: [VOTE] Release Apache Maven 3.0
Date Tue, 05 Oct 2010 14:54:22 GMT

On Oct 5, 2010, at 10:04 AM, Mark Hobson wrote:

> On 5 October 2010 14:31, Baptiste MATHUS <> 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:


> 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]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

To do two things at once is to do neither.
 -—Publilius Syrus, Roman slave, first century B.C.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message