Before you can use the Jalopy Ant task in your build scripts, you have to define the task. This can be done in several ways, depending on the Ant and Jalopy versions you use.
The most conservative way to define the task that works with all versions, is to utilize
the
<taskdef>
element in your build script and specify the class name of the Jalopy task. In order to
achieve a self-contained build, you should not place the Jalopy libraries
into your Ant /lib folder, but use the classpath
attribute to point to the binaries:
Example 4.1. Task definition with specific class path
<taskdef name="jalopy"
classname="com.triemax.JalopyTask"
classpath="${deps}/jalopy-ant-1.9.3.jar" />
Please note that it’s sufficient to reference the Jalopy Ant task library, if the core engine file sits in the same directory (which should be the norm).
If the Jalopy libraries have been added to the Ant class path (by placing them in the
Ant/lib folder), you can simply bind the task as follows:
Example 4.2. Task definition with global search path
<taskdef name="jalopy" classname="com.triemax.JalopyTask" />
After the task has been defined, you can use it in the same manner like any other task:
Example 4.3. Task usage without namespace
<target name="format"> <jalopy ...> ... </jalopy> </target>
Since Jalopy 1.9.3, you can utilize the library feature available with Ant 1.6 or later. When the library has been added to the Ant class path, you can either bind the task globally for the whole script:
Example 4.4. Task definition via project namespace declaration
<project name="foo" xmlns:triemax="antlib:com.triemax" ...> ... </project>
Or limited to a specific target:
Example 4.5. Task definition via target namespace declaration
<target name="jalopy" xmlns:triemax="antlib:com.triemax" /> ... <target/>
Declaring the namespace will automatically load the task and you can access it using the prefixed name defined in the declaration:
Example 4.6. Task usage with namespace
<target name="format"> <triemax:jalopy ...> ... </triemax:jalopy> </target>
But it is usually more sensible to leave the Ant class path alone and instead explicitly handle the class path in the build script to achieve a self-contained build process:
Example 4.7. Task definition with typedef
<target name="format"> <typedef resource="com/triemax/antlib.xml" classpath="${deps}" /> <jalopy ...> ... </jalopy> </target>
Nested <fileset> elements can and should be used to specify the source files and/or directories:
Example 4.8. Target specification using fileset
<target name="format"> <jalopy ...> <fileset dir="${dir.src.java}"> <include name="**/*.java" /> </fileset> </jalopy> </target>
You can also set user environment variables for a run by using nested <variable> elements.
The task itself can take several parameters to control the runtime behavior of Jalopy. The parameters are optional. When omitted, your current profile settings will be used. But it is recommended that at least a settings file is specified. The valid parameters are listed in the table below.
Table 4.1. Jalopy Ant task parameters
| Attribute | Type | Description | Since | Required |
|---|---|---|---|---|
| backup | Boolean | Sets whether backup copies of all processed source files should be kept. When omitted, the corresponding code convention setting will be used (see the section called “Backup”) | 1.0 | No |
| classpath | Path |
The class path to setup the type repository with. If you want the import optimization or Insert Serial Version UID features to work,
you have to specify the class path you use to compile your sources here.
The referenced path must contain all types that are needed by your project. Specifying the Java runtime classes is optional; if they are omitted, the runtime classes used by Ant will be automatically added | 1.9.3 | No |
| classpathref | String |
The class path to setup the type repository with, given as a
reference to a path defined elsewhere. If you want the import optimization or Insert Serial Version UID features to work,
you have to specify the class path reference you use to compile your sources
here.
The referenced path must contain all types that are needed by your project. Specifying the Java runtime classes is optional; if they are omitted, the runtime classes used by Ant will be automatically added | 1.0 | No |
| convention | String | Sets the location to the code convention settings file to use—given either relative to the project’s base directory or as an absolute local path or internet address (refer to the section called “Export code convention” for information how to export your settings). When omitted, and no profile is specified, the settings of the currently active profile will be used | 1.0 | No |
| destdir | String | Sets the destination directory to create/copy all formatting output into. If the given directory does not exist, it will be created. When omitted, all input files will simply be overridden | 1.0 | No |
| encoding | String | Sets the encoding that controls how Jalopy interprets text files containing characters beyond the ASCII character set. Defaults to the platform default encoding | 1.0 | No |
| failonerror | Boolean | Sets whether a run should be held if errors occurred. Defaults to “true” | 1.0 | No |
| file | String | Specifies a single source file to format. | 1.0 | Yes, if no fileset is specified |
| fileformat | String | Sets the file format of the output files. The file format controls what end of line character is used. Either one of “UNIX”, “DOS”, “DEFAULT” or “AUTO” can be used (case insensitive). Defaults to “AUTO” | 1.0 | No |
| force | Boolean | Sets whether the formatting of files should be forced, even if a file is up-to-date. Defaults to “false” | 1.0 | No |
| fork | Boolean | Sets whether the processing should be performed in a separate VM. Defaults to “false” | 1.0 | No |
| history | String | Sets the history policy to use. Either one of “ADLER32”, “CRC32” or “NONE” can be used (case insensitive). When omitted, the corresponding code convention setting will used (see the section called “History”) | 1.0.3 | No |
| inputEncoding | String | Sets the character encoding that controls how Jalopy interprets input text files containing characters beyond the ASCII character set. Defaults to the platform default encoding. Please note that this setting always overrides encoding | 1.6 | No |
| javadoc | String | Indicates whether Javadoc related messages should be printed. Defaults to “true” | 1.0 | No |
| loglevel | String | Specifies the logging level for message output. Either one of “ERROR”, “WARN”, “INFO” or “DEBUG” can be used (case insensitive). When omitted, the current code convention settings will be used (see the section called “Categories”) | 1.0 | No |
| log | String | Specifies the log file to use for logging output. The format of the logging output is determined by the extension of the given file. Valid extensions are “.log” for a custom plain text format, “.xml” for a plain XML format and “.html” for an hierarchical HTML report. When omitted, the current code convention setting will be used (see the section called “Logging”) | 1.0.3 | No |
| outputEncoding | String | Sets the character encoding Jalopy uses to write files. Defaults to the platform default encoding. Please note that this setting always overrides encoding | 1.6 | No |
| profile | String | Sets the Jalopy profile that should be activated during the formatting run (refer to the section called “Main window” for more information about profiles). The currently active profile will be restored after formatting. Please note that the profile must exist! | 1.5 | No |
| repository | Boolean | Indicates whether the type repository should be used for type lookup. When disabled, this currently means that all dependent features despite the import optimization will be disabled! Only meaningful if classpathref has been set. You may want to use this option if you commonly format a single file or only a sets of files in order to avoid the maintenance overhead of the type repository. Defaults to “true” | 1.6 | No |
| test | Boolean | Sets whether formatting output should actually be written to disk. If set to “true” no output will be written to disk. The default is “false” | 1.0 | No |
| threads | Integer | Specifies the number of processing threads to use. Integer between
1 - 8. When omitted, the current code
convention setting will be used
| 1.0 | No |