One of the benefits (to me) is that it makes mismatches in dependency versions stand out.
I've been able to figure out how to rotate the graph yet keep it relatively (cough) narrow. There's still a few unwanted empty boxes but it now has nested groupIds. If you look carefully at the com.faster.jackson you'll notice that there's one subgroup that has a single version but two other subgroups with multiple versions. Earlier I could see that these dependencies were pulled in from two locations and that's why there was a difference. Even if couldn't see the exact reason I know that this larger group of dependencies usually have the same version and if not I should take a closer look. At other places I've had to spend some time tracking down unnecessary transitive dependencies and fix them with a combination of "optional" and exclusions. Something like this would probably be easier to examine than a text listing of several hundred lines. (BTW the scope and 'optional' will be encoded as color and italics, respectively.) The latest version is attached. It's clear that it make sense to move "common-*" under the "org.apache.commons" group. I'm not sure about the org.google group - doing this kept some dependencies in the same subgraph but it also brought in some one-offs. [image: tree2.png] On Mon, Mar 24, 2025 at 7:37 PM Tomo Suzuki <suzt...@google.com.invalid> wrote: > That’s a beautiful diagram. Would you share the background you wanted to > visualize it in that way? Did it get some tasks done? > > Regards, > Tomo > > On Mon, Mar 24, 2025 at 19:02 Bear Giles <bgi...@coyotesong.com> wrote: > > > I should be clear - the glitch is the column of empty boxes above the > root > > dependency. They should not appear. > > > > The grayed areas, with one exception, have the same groupId. If they also > > have the same version then the artifacts will be listed in a single > stack. > > The 'type' is omitted if it's "jar", otherwise it will be included on > that > > line. > > > > If there are multiple versions in the cluster then there will be > > multiple "records" with same structure as the standalone dependencies. > The > > only difference is that they''ll drop the groupId. > > > > The one exception is the "Database Drivers" in the bottom left - that's > an > > experiment specific to this pom - sometimes you might have a group > > independent dependencies that serve the same role, e.g., database JDBC > > drivers. Does it make sense to put them into their own cluster? > > > > Bear > > > > On Mon, Mar 24, 2025 at 4:52 PM Bear Giles <bgi...@coyotesong.com> > wrote: > > > >> The maven-dependency-plugin has a '.dot' option but because of the > layout > >> it's useless for anything other than the most trivial dependency > trees. I > >> know we can't replace existing functionality but this could be added as > >> "dot2", or a 'variant" property could be added to the mojo. > >> > >> There are some few obvious tweaks but some of them hit the limitations > of > >> the graphviz > >> library, or at least my understand of it. However I think I have > >> something very close to a good alternative to the standard layout - I > just > >> need to ask the graphviz people as question first. > >> > >> I've attached a sample pom and the generated png file. This is the pom I > >> use for an application that creates a document listing the database > >> metadata for multiple databases. > >> > >> Bear Giles > >> [image: tree2.png] > >> > > >
