Compile With Walls Task

Creator: Dean Hiller (dean@xsoftware.biz)

Description

Puts up walls in a the same source tree to ensure that designs are not violated

This task helps someone separate out packages and prevent dependencies from occurring on accident. For example, if there are three packages in one source tree

and modB and modA should be able to compiled independently, you can put a wall up in between the two so that if anyone adds a dependency between modA and modB, the build will break. This is particularly good if the builds are automated.

This task is for low level design. For architectural walls like client and server, I would suggest using multiple source trees and compiling those source trees independently as two different ant compile targets.

Parameters

Attribute Description Required
None at this time None at this time None at this time

Parameters specified as nested elements

This task can contain one nested javac task and one nested walls task. See the javac task for it's attributes and nested elements.

Walls element

The walls element contains nested package elements. These nested package elements have the following attributes. If any package depends on another, it must be listed after the package it depends on in the walls element.

Attribute Description Required
name A smaller nickname for the package to reference in depends Required
package The package to compile such as biz.xsoftware.* to include the immediate package only or biz.xsoftware.** to include biz.xsoftware and all subpackages. Required
depends If a package need one of the previously specified packages to compile, it's name would be added here in a comma separated list. For example depends="modA,modB" Optional

Examples

In the examples, I will show the javac as a null element, because it's use is documented in the javac task documentation.
  <compilewithwalls>
     <walls>
        <package name="modA" package="biz.xsoftware.mod.modA"/>
        <package name="modB" package="biz.xsoftware.mod.modB"/>
        <package name="mod" package="biz.xsoftware.mod.modA" depends="modA,modB"/>
     </walls>
     <javac></javac>
  </compilewithwalls>

Notice that the package named mod had to come after the packages it depended on. Now if anybody puts code in modA that uses classes in modB, the build will break telling them they are violating a design constraint. I personally have had many a devoloper accidentally put dependencies in that we agreed in the design should not be there. This includes myself. This prevents this from happening as long as someone doesn't change the ant build file....If someone does though, at least you can view the package dependencies and now what they are.


Copyright © 2002-2003 Ant-Contrib Project. All rights Reserved.