On Jan 22, 2008, at 6:49 AM, Mark Hobson wrote:
Hi David,
On 19/01/2008, David Blevins <[EMAIL PROTECTED]> wrote:
Still digging through that code, but hopefully you can answer this
question real quick. The resulting structure is definitely a tree as
opposed to a graph (which could be fine). Does that mean given the A
and B depend on C scenario I described, there'll be two copies of C;
one C below A with A as it's parentNode, and one C below B with B as
it's parent node?
If the answer is yes, then I can easily re-arrange things to a graph
(multi-parent nodes). If no, then can you confirm my suspicion
that I
could achieve what I'm after with a slightly varied version of
DependencyTreeResolutionListener?
maven-dependency-tree does indeed build a tree as opposed to a graph.
You could implement a ResolutionListener that built a graph instead
and ignored all the omit events, but if you ultimately also require
the dependency resolutions from Maven then I'd advise adding optional
graph functionality to maven-dependency-tree, since the resolution
events are rather delicate (see DependencyTreeResolutionListener).
Note that Jason is coordinating a lot of future work in this direction
for 2.1, which will use graphs natively to resolve dependencies rather
than events.
So far the tree seems to have enough data in it that it can be
rewrapped as a graph. I have wrapper similar to DependencyNode that
has multiple parents. Anywhere a child is a "duplicate" or "conflict"
it's replaced by the wrapper of the related artifact and a new parent
added to the list.
Relatively straight forward. I could add it back into the maven-
dependency-tree lib if you think it's particularly useful.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
