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. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
