You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/09/24 11:33:59 UTC
ArtifactResolution and some visuals as food for thought
Hi,
I've been working with Oleg Gusakov to make the necessary alterations
for graph-first based dependency resolution and here are some
pictures we've come up with so far.
This is of the completely unadulterated tree with no scope
transitioning, conflict resolution, or transformation:
http://people.apache.org/~jvanzyl/g1.png (root at the centre with an
organic layout)
Another view:
http://people.apache.org/~jvanzyl/g2.png (node with most deps at
centre, using a circular layout)
What you see in green are nodes with the same groupId, and artifactId
so it gives you some idea of how conflict resolution may need to
occur. In this tree we have all the depth information, source
information and anything else to make an informed decision because we
still have all the information at this point.
Next we have the transformation of the tree into a graph and we've
not done much here yet, we're just doing a simple collapsing into a
single node for each groupId, artifactId:
http://people.apache.org/~jvanzyl/g3.png (circular layout with test
scope edges in light blue)
and
http://people.apache.org/~jvanzyl/g4.png (hierachic layout or moen
where the test scope edges are easier to see)
This is just some food for thought, but what we are planning to do is
show the difference (visually) between what is currently happening
and what should happen. Depth information is being lost and without
the original tree up front I'm seeing it being very hard to get
accurate information. That picture is of maven-core BTW.
We're using yFiles from yWorks to do the rendering and it is simply
the best graph tool their is. Oleg's son is actually trying to make
something equivalent in Eclipse using Zest. So I'm going to integrate
this graphing into IDEA and we'll be making a little stand-alone tool
for people to play around with. We just need to figure out
obfuscating the yFiles JAR before deploying it. What I intend instead
of rambling on ad nauseam about why I think the current mechanism
doesn't work I'll just show you. We're currently trying to figure out
how to display the mechanism of the old/new in side by side windows
as the resolution is happening to demonstrate the differences
visually. We are dealing with 1000+ projects here, where we have to
make 150 different deliverables and things must be unequivocally
accurate including snapshots. Anyone some pictures to think about.
More to come this week.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ArtifactResolution and some visuals as food for thought
Posted by Jason van Zyl <ja...@maven.org>.
Well, you can soon just make your own. The only hold back with
releasing the tool we're making is an agreement with yWork to
obfuscate the JAR before distributing. So we should have the source
out shortly.
On 24 Sep 07, at 3:21 AM 24 Sep 07, Mark Hobson wrote:
> Good work! Glad to see some progress being made in visualising and
> debugging dependency problems - it certainly saps a lot of developer
> time where I work.
>
> Looking forward to more screenshots.
>
> Cheers,
>
> Mark
>
> On 24/09/2007, Jason van Zyl <ja...@maven.org> wrote:
>> Hi,
>>
>> I've been working with Oleg Gusakov to make the necessary alterations
>> for graph-first based dependency resolution and here are some
>> pictures we've come up with so far.
>>
>> This is of the completely unadulterated tree with no scope
>> transitioning, conflict resolution, or transformation:
>>
>> http://people.apache.org/~jvanzyl/g1.png (root at the centre with an
>> organic layout)
>>
>> Another view:
>>
>> http://people.apache.org/~jvanzyl/g2.png (node with most deps at
>> centre, using a circular layout)
>>
>> What you see in green are nodes with the same groupId, and artifactId
>> so it gives you some idea of how conflict resolution may need to
>> occur. In this tree we have all the depth information, source
>> information and anything else to make an informed decision because we
>> still have all the information at this point.
>>
>> Next we have the transformation of the tree into a graph and we've
>> not done much here yet, we're just doing a simple collapsing into a
>> single node for each groupId, artifactId:
>>
>> http://people.apache.org/~jvanzyl/g3.png (circular layout with test
>> scope edges in light blue)
>>
>> and
>>
>> http://people.apache.org/~jvanzyl/g4.png (hierachic layout or moen
>> where the test scope edges are easier to see)
>>
>> This is just some food for thought, but what we are planning to do is
>> show the difference (visually) between what is currently happening
>> and what should happen. Depth information is being lost and without
>> the original tree up front I'm seeing it being very hard to get
>> accurate information. That picture is of maven-core BTW.
>>
>> We're using yFiles from yWorks to do the rendering and it is simply
>> the best graph tool their is. Oleg's son is actually trying to make
>> something equivalent in Eclipse using Zest. So I'm going to integrate
>> this graphing into IDEA and we'll be making a little stand-alone tool
>> for people to play around with. We just need to figure out
>> obfuscating the yFiles JAR before deploying it. What I intend instead
>> of rambling on ad nauseam about why I think the current mechanism
>> doesn't work I'll just show you. We're currently trying to figure out
>> how to display the mechanism of the old/new in side by side windows
>> as the resolution is happening to demonstrate the differences
>> visually. We are dealing with 1000+ projects here, where we have to
>> make 150 different deliverables and things must be unequivocally
>> accurate including snapshots. Anyone some pictures to think about.
>> More to come this week.
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: ArtifactResolution and some visuals as food for thought
Posted by Mark Hobson <ma...@gmail.com>.
Good work! Glad to see some progress being made in visualising and
debugging dependency problems - it certainly saps a lot of developer
time where I work.
Looking forward to more screenshots.
Cheers,
Mark
On 24/09/2007, Jason van Zyl <ja...@maven.org> wrote:
> Hi,
>
> I've been working with Oleg Gusakov to make the necessary alterations
> for graph-first based dependency resolution and here are some
> pictures we've come up with so far.
>
> This is of the completely unadulterated tree with no scope
> transitioning, conflict resolution, or transformation:
>
> http://people.apache.org/~jvanzyl/g1.png (root at the centre with an
> organic layout)
>
> Another view:
>
> http://people.apache.org/~jvanzyl/g2.png (node with most deps at
> centre, using a circular layout)
>
> What you see in green are nodes with the same groupId, and artifactId
> so it gives you some idea of how conflict resolution may need to
> occur. In this tree we have all the depth information, source
> information and anything else to make an informed decision because we
> still have all the information at this point.
>
> Next we have the transformation of the tree into a graph and we've
> not done much here yet, we're just doing a simple collapsing into a
> single node for each groupId, artifactId:
>
> http://people.apache.org/~jvanzyl/g3.png (circular layout with test
> scope edges in light blue)
>
> and
>
> http://people.apache.org/~jvanzyl/g4.png (hierachic layout or moen
> where the test scope edges are easier to see)
>
> This is just some food for thought, but what we are planning to do is
> show the difference (visually) between what is currently happening
> and what should happen. Depth information is being lost and without
> the original tree up front I'm seeing it being very hard to get
> accurate information. That picture is of maven-core BTW.
>
> We're using yFiles from yWorks to do the rendering and it is simply
> the best graph tool their is. Oleg's son is actually trying to make
> something equivalent in Eclipse using Zest. So I'm going to integrate
> this graphing into IDEA and we'll be making a little stand-alone tool
> for people to play around with. We just need to figure out
> obfuscating the yFiles JAR before deploying it. What I intend instead
> of rambling on ad nauseam about why I think the current mechanism
> doesn't work I'll just show you. We're currently trying to figure out
> how to display the mechanism of the old/new in side by side windows
> as the resolution is happening to demonstrate the differences
> visually. We are dealing with 1000+ projects here, where we have to
> make 150 different deliverables and things must be unequivocally
> accurate including snapshots. Anyone some pictures to think about.
> More to come this week.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org