Creator: Dean Hiller (dean@xsoftware.biz)
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
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.
One pattern I personally like to follow can be seen on the vmaster project on sourceforge. Instructions to check it out and look at are HERE. The interesting files in vmaster to look at our here....
Attribute | Description | Required |
walls | Specifies the external dependency file to use(see example below) | Either this or a nested walls element is required |
intermediaryBuildDir | Specifies scratch area for the compilewithwalls task to do the building and ensure dependencies are not violated | required |
This task can contain one nested javac task and one nested walls task. See the javac task for it's attributes and nested elements.
The nested walls element or the walls attribute must be specified. Only one may be used. 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 |
<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.
These next lines would be in build.xml..... <compilewithwalls walls="dependencies.xml"> <javac></javac> </compilewithwalls>
These lines would be in dependencies.xml..... <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>
Copyright © 2002-2004 Ant-Contrib Project. All rights Reserved.