[m3] ProjectSorter problems (was: Re: [VOTE] Release Apache Maven 3.0)

[Mark Hobson <ma...@gmail.com>]

Branching the m3 vote thread:

On 5 October 2010 16:22, Mark Hobson <ma...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m3] ProjectSorter problems (was: Re: [VOTE] Release Apache Maven 3.0)

[Mark Hobson <ma...@gmail.com>]

On 5 October 2010 22:43, Benjamin Bentmann <be...@udo.edu> wrote:
> To me the situation looks like this: The ProjectSorter serves one purpose,
> that is to figure out the build order of projects within a reactor. Unless I
> misunderstand, you seem to have a different use case and merely use the
> ProjectSorter because its API/signatures matches. If so, then I suggest to
> simply fork the sorter from 2.x into your own code base.

It's not wildly different, and being a Maven shared component I'd
rather not fork 2.x code.  I'll deal with it in maven-runtime, thanks.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m3] ProjectSorter problems (was: Re: [VOTE] Release Apache Maven 3.0)

[Benjamin Bentmann <be...@udo.edu>]

Mark Hobson wrote:

> Is there a way that we could support both behaviours?

To me the situation looks like this: The ProjectSorter serves one 
purpose, that is to figure out the build order of projects within a 
reactor. Unless I misunderstand, you seem to have a different use case 
and merely use the ProjectSorter because its API/signatures matches. If 
so, then I suggest to simply fork the sorter from 2.x into your own code 
base.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m3] ProjectSorter problems (was: Re: [VOTE] Release Apache Maven 3.0)

[Mark Hobson <ma...@gmail.com>]

On 5 October 2010 21:50, Mark Hobson <ma...@gmail.com> wrote:
> I've raised MNG-4854 [1] to demonstrate the problem.

Benjamin, I understand your comment on the issue.  The situation I
have is with maven-runtime where all dependencies have already been
mediated, so project:1.0 is in fact using dependency:1.0 at runtime.

Is there a way that we could support both behaviours?  The alternative
would be for maven-runtime to align all dependency versions to those
that are available at runtime.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [m3] ProjectSorter problems (was: Re: [VOTE] Release Apache Maven 3.0)

[Mark Hobson <ma...@gmail.com>]

On 5 October 2010 18:35, Mark Hobson <ma...@gmail.com> wrote:
> 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.

I've raised MNG-4854 [1] to demonstrate the problem.

Mark

[1] http://jira.codehaus.org/browse/MNG-4854

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org