Adding New Packages
Now, let's add a new package called
biz.xsoftware.client2, and add a class called
Client2.java to that package. This class does not need to have any code in it at all. The real "package design" should now look like
Figure 6. Again, note that this is not the defined "package design" in the design file.
 | |
| Figure 6. New Client2 Package: Here's the dependency situation after adding a second client package. |
Now rerun the build using
antf bldfiles/build.xml and you'll see the following error.
Package=biz.xsoftware.client2 is not defined
in the design. All packages with classes must be declared
in the design file. Class found in the offending
package=biz.xsoftware.client2.Client2
Basically, users finds that the "package design" must cover all the code in the module. Verifydesign forces your design to be kept up to date. You can always use the
subpackages attribute as shown earlier to include a named group of subpackages. In fact, you could declare all your source code as one big wad, using the
default package, which is reserved just for this case:
<package name="default" package="default package"
subpackages="include" needdepends="false"/>
But it's better to fix the design. Add the following line to your design file.
<package name="client2" package="biz.xsoftware.client2"/>
After defining the new package, you should be able to run the build again successfully. Notice that the client2 class has no dependencies, so you don't have to declare anybut you do have to define the package.
Let's now add some valid dependencies and change our design to allow those dependencies. First, modify the line of the design file shown earlier to this:
<package name="client2" package="biz.xsoftware.client2">
<depends>phoneApi</depends>
</package>
Next, copy the
Client.java file from the
biz.xsoftware.impl.client folder to the
biz.xsoftware.client2 folder. This class depends on the
PhoneApi package. Now, running the build should pass.
Stale Documentation
Sometimes a developer deletes code from a class that results in a package no longer depending on another package specified in the design. Let's now do the reverse of what we did previously. Delete the
biz.xsoftware.client2.Client.java file, and run the build again. You'll see the following error:
Package name=client2 has a dependency declared
that is not true anymore. Please erase the dependency
<depends>phoneApi</depends> from package=client2
If you follow those instructions and delete the
depends node, and then rebuild, the build passes because the code matches the design. Finally, delete the
Client2.java file and run the build again.
Package name=client2 is unused. Full package=biz.xsoftware.client2
At this point, you've seen how Verifydesign enforces the dependency restrictions to ensure that your design is always up to date. This feature was recently added to Verifydesign and when we first ran it on our project, we had to delete 17 lines from
design.xml, which had around 50 lines at the time. This made reading the "package design" much easier. Just think, you can tell everyone that your design documentation is
guaranteed to always be up-to-date.
Wiring Ant-contrib into Your Build
Now, to make sure the tool can enforce dependencies, you have to wire Verifydesign into the builds. The key lines in the
verifydesign/package/bldfiles/build.xml file are:
<property name="antcontrib.location" location="${tool.dir}/ant-contrib" />
<path id="antcontrib.lib">
<fileset dir="${antcontrib.location}">
<include name="**/*.jar" />
</fileset>
</path>
<taskdef resource="net/sf/antcontrib/antlib.xml"
classpathref="antcontrib.lib" />
Those lines load all the ant-contrib tasks. Subsequently, to use Verifydesign on a single jar, just add the following line.
<verifydesign jar="${jardist}/${jar.name}" design="bldfiles/design.xml" />
You can find more documentation at
ant-contrib's homepage .