AJDT 1.5.3 - New and Noteworthy

Overview

In addition to supporting the
latest AspectJ release
(v1.6.1), the focus of this release has been general bug fixing and
maintenance. Nevertheless, there have been some significant
enhancements. Most importantly, there is now considerable flexibility
in how project in paths
and project aspect paths can be configured.

This will be the last release in the 1.5.x stream other than releases
that contain critical bug fixes. The 1.5.x stream targets Eclipse
3.3.x. All future releases will be part of the 1.6.x stream and target
Eclipse 3.4.x.

Aspect path and In path

The aspect path and the in path for
an AspectJ project can now
contain containers, variables, and projects in addition to class
folders.

As before, adding an element to the aspect path or in path also adds it
to the Java build path., and removing it from the Java build path also
removes it from the aspect path or in path.

Better support for
validation of classpaths

Duplicate or inconsistent classpath
entries in the in path and aspect path are now found immediately after
there is a change to the classpath.

In the above screenshot, the JUNIT_HOME
classpath variable and the
JUnit 3 classpath container both resolve
to the same jar file. This
gives rise to the error message in the status bar above.

Inpath outfolder

It is now possible to set an
outfolder for all entries on the inpath. A new item in the in path
properties page has been added to expose this functionality to the
programmer.

Use the Browse... button to choose a folder or
type the folder name in directly.

Suppressing AspectJ
Autobuilding

For large projects that take
advantage of aspects, it
is sometimes cumbersome to use Eclipse's autobuild feature. But, at the
same time it is not desirable to turn off autobuilding for the entire
workspace.
AJDT 1.5.3 provides an option to suppress autobuilding for AspectJ
projects only.
This option is accessible in the AspectJ Compiler preferences page.

Incremental compilation
and building of broken code

AJDT 1.5.3 includes AspectJ 1.6.1.
This version of AspectJ allows the capability to build and run broken
code.

Following on from the work done to improve compilation under Eclipse in
AspectJ 1.6.0 (Bug
221427)–we now support the building of 'broken code' (Bug
102733). This is something the JDT has always been doing–where
code containing errors continues to build (if recovery is
possible) but should the actual methods containing the errors get
invoked, an exception will be thrown at runtime. A number of users
typically extract large projects from their library systems, knowing
that they will only partially build in their current eclipse setup, but
as long at they do not invoke the code containing the errors then they
expect the rest of the project to run normally. AspectJ now allows this
mode of operation, and it has the additional effect that the state of
the project stays consistent, albeit with known errors, and this means
AspectJ will more frequently do incremental builds rather than falling
back to full builds because there was a compilation error.

As
shown in the screenshot above, if a compilation unit has errors in it,
the compiler will still produce a valid class file for it.
However, the weaver will ignore the file and its aspects will not
be woven.

AJDoc now works on the Mac. It is
necessary to select the correct location of
classes.jar. This is typically found in
/System/Library/Frameworks/JavaVM.Framework/Versions/<VERSION>/Classes/classes.jar.
There is otherwise the same behavior as on Windows.

Bug fixes

As usual this release also contains
a number of bug fixes. The full list is available in Bugzilla.
The more notable ones are: