AjcTask Ant Support for AspectJ 1.1

Description

This task uses the AspectJ^tm 1.1 compiler ajc. The AspectJ compiler can be used like Javac to compile Java sources, but it can also compile AspectJ sources or weave binary aspects with Java bytecode. It can run in normal "batch" mode or in an "incremental" mode, where it only recompiles files it has to revisit. For more information on ajc, see the links from the AspectJ docs home. The main things to remember:

In incremental mode, sources may only be specified using source root directories.
A .class file may only be woven once. That means binaries in injars or aspectjpath must have been compiled with jikes or javac or, if using ajc, with noweave.

This task is named iajc now to avoid conflict with the 1.0 task ajc, but the name may change to ajc in the future.

See below for an introduction to handling compiler messages programmatically.

Parameters

Parameters supported by `ajc`

Specifying source and destination files
Attribute	Description	Required
sourceroots	a list of base directories of the source files. All source files (.java and .aj) in the base directories are compiled. May also be specified as a nested element.	Yes, in incremental mode.
outjar	Path to an output jar to generate with all output classes.	No
destdir	Specify where to place the generated class files.	No
classpath	the classpath required by the source files to compile. May also be specified as a nested element.	No
srcdir	the nested source base directory to compile, specified as a nested element.	No
aspectpath	the aspectpath to use -- like classpath, only for read-only, binary aspect libraries (only accepts jar/zip files, no directories). May also be specified as a nested element.	No
bootclasspath	location of bootstrap class files.	No
classpathref	the classpath to use, given as a reference to a PATH defined elsewhere.	No
bootclasspathref	location of bootstrap class files, given as a reference to a PATH defined elsewhere.	No
Specifying compiler behavior
noweave	If true, produce binaries for the -injars option (only) -- defaults to `false`.	No
incremental	build once, then recompile on demand only required files; defaults to `false`. By default, files are recompiled based on input passed to stdin (see tagfile)	No
tagfile	File that controls when incremental builds are done and when the task completes.	No
X	Set experimental option(s), using comma-separated list of accepted options (unlisted here -- for XLint, use the xlint entries). Options should not contain the leading X.	No
Specifying compiler side-effects and messages
verbose	whether to emit compiler status messages during the compile; defaults to `false`.	No
version	if true, do not compile - just print AspectJ version; defaults to `false`.	No
help	if true, just print help for the command-line compiler; defaults to `false`.	No
Xlintenabled	same as `xlint:all`, whether to emit language usage messages during the compile; defaults to `false`.	No
Xlintfile	specify property file containing name:level associations for any overrides to the default associations for language usage messaged emitted during the compile.	No
failonerror	whether the build continues notwithstanding compile errors; defaults to `true`.	No
messageholderclass	Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the `org.aspectj.bridge.IMessageHolder` interface and having a public no-argument constructor.	No
Eclipse compiler options
nowarn	same as `warn:none`; defaults to `false`.	No
deprecation	same as `warn:deprecation`; defaults to `false`.	No
warn	one or more comma-separated warning specifications: constructorName, packageDefaultMethod, deprecation, maskedCatchBlocks, unusedLocals, unusedArguments, unusedImports, syntheticAccess, or assertIdentifier.	No
debug	same as `debug:lines,vars,source`	No
debuglevel	comma-separated list lines, vars, or source, indicating to add debugging information for lines, variables, or source	No
PreserveAllLocals	code gen preserve all local variables (for debug purposes); defaults to `false`.	No
noimporterror	no errors for unresolved imports; defaults to `false`.	No
referenceinfo	compute reference info; defaults to `false`.	No
log	File to log compiler messages to.	No
encoding	default source encoding format	No
proceedonerror	keep compiling when error, dumping class files with problem methods; defaults to `false`.	No
progress	show progress (requires log); defaults to `false`.	No
time	display speed information; defaults to `false`.	No
noexit	disable System.exit (kills Ant -- use failonerror); defaults to `true`.	No
target	Specify target class file format (must be "1.1" or "1.2"); defaults to 1.1 class file.	No
compliance	Set "1.3" or "1.4" source compliance level (e.g., no import from default package in 1.4); defaults to 1.3 compliance level.	No
source	source assertion mode ("1.3" or "1.4"); default depends on compliance mode.	No

Nested Elements

This taskdef should support nested elements as the old one did; see taskdef-ajc10.html#nestedElements.

Programmatically handling compiler messages

Users may specify a message holder which is passed all messages generated by the compiler synchronously. This overrides all of the normal message printing, but does not prevent the task from failing if failonerror is true and errors or exceptions were encountered. Handling messages programmatically could be useful when using the compiler to inspect code. If aspects consist of declare [error|warning], then the compiler can act to detect invariants in the code being processed. For code to compare expected and actual messages, see the AspectJ testing module (which is not included in the binary distribution).