Sunday, June 19, 2011

CDK Module dependencies #3

Jonathan is here with me to work on his fingerprint project. He asked about CDK modules, which we use to control dependencies, within the CDK, as well as from the CDK on top of third-party libraries. I wrote up previously this about it:
Using this modularization we can control the cleanness of our code, and keep it small and extensible. For example, the full CDK jar without third-party libraries is already 16 MB large. With this modularization we can limit the number of dependencies, and allowing people to pick what parts they need. The modular building ensures no unwanted dependencies sneak in.

The last overview of CDK module dependencies is a bit outdated. It is easy to recreate from the source code repository, using BeanShell and Graphviz with something like:

$ export CLASSPATH=jar/jgrapht-0.6.0.jar
$ bsh tools/deptodot.bsh --cdkLibs >
$ dot -Tpng -O

The current master gives this diagram:

(The sinchi module no longer exists, but clearly is still picked up from somewhere :)

It is also worth noting how this modularization is defined. We use JavaDoc for this, and in particular by adding a @cdk.module tag to the class JavaDoc, which is explained in this CDK News paper.


  1. Well:
    java bsh.Interpreter tools/deptodot.bsh --cdkLibs >

    (the important bit being the angle bracket :)

    I'm wondering now if I can get dot to give me a tree with a more rigid depth order, so that you can see more easily which modules require lots of deps.

  2. Ah, thanx for catching that glitch! I fixed the post.