Kohsuke Kawaguchi's Blog

GlassFish v3 dependency tree

GlassFish v3 builds are heavily dependent on Maven2, so as a result we are spending a lot of efforts into extending Maven to do things we need it to do. One of them is to build a final distribution image, in such a way that all the modules in v3 is placed into the proper place automatically, based on information in POM.

So last Friday I extended that code a little so that it can generate a complete dependency graph of modules and its dependency jars. Click the picture below to get the full size module dependency graph (and beware that it's quite large already!)

Dotted line indicates optional dependency. If the dependency scope is something other than "compile", the edge has a label indicating what the scope is. Nodes and edges in reds represent dependencies inside the so-called web tier.

Initially I was bit skeptical whether this is of any practical use, so I waited until Friday to work on this (in that way, at least I can claim it was a Friday project.) But it turns out that the graph is revealing. For example, you can already see that there are too many dependency edges that are redundant. For example, gf-web-connector (top-most red node) has a dependency to hk2 and glassfish-api, but both are also transitvely included in the dependencies anyway, through kernel. This kind of issues is probably an indication that people are confused as to the existing module layering structure.

Comments

• nice graphics. But , why there is a dependency to the JRuby stuff? i dont use it and i would not want anything exstra in Glassfish V3 (i thought whole purpose of V3 was that!).

  Posted by: ahmetaa on January 07, 2008 at 01:18 PM

• Any chance of releasing your graphing tool as a maven plugin?

  Posted by: stephenconnolly on January 07, 2008 at 01:19 PM

• JRuby dependency is through the glassfish-jruby-connector module, which is about adding jruby into GFv3. So it's only for those who want it.

  Posted by: kohsuke on January 07, 2008 at 03:11 PM

• Stephen, yes, I should be able to. The code to do this in http://maven-antrun-extended-plugin.dev.java.net/ but the project just needs more documentation.

  Also, I'd like to create a separate mojo for this so that we can use it more easily elsewhere.

  Posted by: kohsuke on January 07, 2008 at 03:13 PM

• Very interesting!

  One danger in aggressively removing seemingly redundant dependencies is that over time a module's dependencies can evolve. If A is marked today as depending on B and C, and B itself depends on C, then it's true that A need not be explicitly marked as depending on C - for now. If A loses its dependency on B in the future, then when I remove that dependency I must remember to reinstate the "A depends on C" dependency.

  On the other hand, if I had never removed "A depends on C" initially then all would be well.

  Posted by: tjquinn on January 09, 2008 at 09:20 AM

• tjquinn — Yes, I agree. The way I think of it is that there are two kinds of dependencies --- implementation detail dependency (for example, module X uses commons-lang to implement it), and contract-level dependency (for example JSP depending on servlet.)

  Explicit dependencies on servlet when it also depends on JSP can be a subject of removal, but explicit dependency on commons-lang is not necessarily a subject of removal just because you are getting it transitively.

  Posted by: kohsuke on January 09, 2008 at 02:52 PM

This work is licensed under a Creative Commons License.