Code Quality & Java 30 May 2007 11:07 am

Enforcing Package Dependencies (Part 3)

Japan is another open source tool that can be used for enforcing package dependencies. It comes with an IntelliJ plugin as well as an ant task. The ant task makes it trivial to incorporate into an ant build.

The real beauty of Japan is how simple it’s configuration is despite being a dreaded XML file.

<japan-config base-package="com.gigantiq.bedrock" ignore-indicator="// JAPAN:IGNORE">
<dependency-set name="module" package-depth="4" transitive="true">
<dependency from="model" to="ui"/>
<dependency from="ui" to="model,ui"/>
<dependency from="util" to=""/>
</dependency-set>
</japan-config>

The document element, japan-config, defines an attribute called base-package. This allows the base package of the project to be defined. In this case the base-package is com.gigantiq.bedrock.

The dependency-set defines the allowed dependencies at specified depth. It is here that Japan exhibits it’s biggest limitation. Japan assumes that the dependencies you wish to enforce are all at the same level within the package hierarchy.

In the above example, since the dependencies we are enforcing are all below the package com.gigantiq.bedrock, we state that the package-depth for this dependency-set is 4. This can become problematic if you are retrofitting Japan to an existing project whose package structure is not very uniform. Japan’s work-around for this is that it allows multiple dependency-set elements to be defined all with different values for the package-depth attribute. Too many dependency-set elements though, lead to an overly complicated configuration file.

Since Japan comes with a Ant task it can be added to your existing ant build very easily.

<taskdef classname="net.sourceforge.japan.ant.JapanTask" name="japan" classpath="build/lib/ant/japan-0.1.jar:build/lib/ant/jdom.jar"/>
<target name="dependency-check" >
<japan sourcePath="source/java.main;" japanConfigFile="japan-config.xml" />
</target>

The error reporting that results from the ant task is very easy to interpret. Both ends of a violation are clearly highlighted.

So what are the biggest problems with Japan? There two main issues I have with Japan one of which I have already mentioned.

First is the flexibility that is lost with a dependency-set only allowing dependencies to be defined at a single level with in a package. The second is the absence of any tools for analysing an applications package dependencies.

The biggest thing that Japan has going for it, is that it is incredibly simple to use and trivial to include in my build.

Comments are closed.