Macker runs reasonably cooperatively as an Ant task. Is is somewhat more cooperative running under Ant 1.5, which resolved a number of difficulties in the handling of classpaths for custom Ant tasks. The rest of this page presumes Ant 1.5; if you are using an earlier version, you're on your own.
To use the Macker Ant task, you first need to declare it in a taskdef:
<taskdef name="macker"
classname="net.innig.macker.ant.MackerAntTask"
classpath="macker.jar and macker libs"/>
Specifying the classpath can be tedious, since Macker requires so many jars. Fortunately, Ant provides a nice trick for this: you can use a pattern to grab all the macker jars at once, and then place a classpathref in the taskdef tag -- like so:
<path id="macker.classpath">
<fileset dir="dir with macker.jar and Macker libs" />
</path>
<taskdef name="macker"
classname="net.innig.macker.ant.MackerAntTask"
classpathref="macker.classpath"/>
Once you've declared the macker task, you can use it in your Ant file with the options below.
These options appear on the <macker> tag itself. They are all optional.
| Attribute | Description | Default |
|---|---|---|
| printThreshold | Severity of errors / messages Macker will print to the console (one of: debug, info, warning, error). | info |
| angerThreshold | Severity of error / message which will cause Macker to get mad, and consider rule checking to have failed (debug, info, warning, error). | error |
| failOnError | Should Macker getting mad cause the Ant build to fail? (An internal error, such as a malformed rules file, will always cause the build to fail; this setting applies only to rule violations.) | yes |
| angerProperty | The name of an Ant property to set to "true" if rules checking fails. Note that this setting is moot if failOnError is true. | none |
| xmlReportFile | Output location of an XML report. You can transform this into whatever form suits you. A future version of Macker will include a standard HTML transform. | none |
| maxMessages | The maximum number of messages and errors Macker should print to the console. | unlimited |
| fork | Should Macker run in its own JVM? (The answer is almost always "no".) | no |
| verbose | Instructs Macker to dump information useful for debugging a rules file, including all references from primary classes, and the primary classes matched by each pattern. | no |
Specifies XML rules files. Macker will apply each rules file in the fileset to the primary classes.
This tag uses the standard Ant fileset mechanisms. An example:
<rules dir="${src.dir}" includes="**/*macker*.xml" />
Specifies the set of primary class files. These are only the classes to which Macker's rules actually apply; you don't need to include libraries on which your classes depend.
Note that this tag specifies compiled class files -- not source files, and not jars.
Like <rules>, this tag is a fileset. It typically won't look too much unlike this:
<classes dir="${build.classes.dir}">
<include name="**/*.class" />
</classes>
You can optionally define variables for your rules files to use. This tag has exactly the same syntax in your Ant file as it does in a rules file -- you specify a name and a value attribute.
The Macker task does not automatically pass Ant properties through as Macker variables; you need to do this manually:
<var name="base.package" value="${base.package}" />
Macker will look here for information about other classes referenced by the primary classes (typically third party libraries).
If fork is false, this tag is optional. However, if you provide no classpath, Macker can infer only the names of external classes, and that's it -- many kinds of rule checking will fail. In a typical build file, you'll simply pass your build classpath here.
If fork is true, this tag is required, and must contain (at the very least) macker.jar and all the third party jars Macker depends on. In a typical build file, you'd pass in both your build classpath and the same Macker classpath you used in the taskdef.
Including the primary classes in this classpath has no effect.
Here, for your copy-and-pasting enjoyment, is a not entirely unreasonable starting point for your own Macker files.
<!-- Declare a catch-all classpath for the project, its libs, and Macker --> <path id="build.classpath"> <pathelement location="${build.classes.dir}" /> </path> <path id="macker.classpath"> <pathelement location="${build.classes.dir}" /> <fileset dir="${lib.dir}" includes="*.jar" /> <fileset dir="${macker.lib.dir}" includes="*.jar" /> </path> <!-- Declare the Macker task --> <taskdef name="macker" classname="net.innig.macker.ant.MackerAntTask" classpathref="macker.classpath" /> <!-- Run the darn thing! --> <macker> <rules dir="${src.dir}" includes="**/*macker*.xml" /> <classes dir="${build.classes.dir}"> <include name="**/*.class" /> </classes> <var name="basepkg" value="com.foobar" /> <classpath refid="build.classpath" /> </macker>
You can also take a look at the example build file.