AJDT Release Notes for 1.2.0M2

This document contains migration information and known limitations. It will be updated as necessary as any new problems and workarounds are discovered.

Last updated: 17 December 2004.

Migration issues

It is easiest to install 1.2.0M2 with a new, empty workspace, and check-out your projects into that. However when that isn't possible or desirable, you can upgrade an existing workspace, as long as you are aware of the following issues.

Open Editors. The AspectJ Editor has a different Eclipse identifier in the 1.2.0 stream. This means that any files open with the editor from a 1.1.x version of AJDT will not be restored after upgrading to 1.2.0M2, and you will get a "Problem restoring workbench layout" message about this. It is therefore recommended that you close all open editors before performing the upgrade.

PDE Projects. If you have AspectJ-enabled plugin projects from a 1.1.x version of AJDT, you need to change the dependency on the org.aspectj.ajde plugin to be org.aspectj.runtime instead. You can of course do this after performing the upgrade.

Resource filters for .aj files. If you have defined your own custom filter settings in the package explorer before installing 1.2.0M2, you will get a warning dialog about the ".aj resource filter" being disabled. If you see this please follow the instructions listed in the dialog, otherwise any .aj files will appear twice in the package explorer - once as compilation units and again as plain files.

Outline and Cross References views. The default mode in 1.2.0M2 is to use the standard outline view rather than the customized one that was used previously, and use the Cross References view to see crosscutting information. If you have existing projects built with any previous release of AJDT, you will need to rebuild these in order to see the new advice decorator in the outline view and the crosscutting information in the new view.

AspectJ code in ".java" files. Most of the new functionality in 1.2.0M2 requires all AspectJ code to be contained in ".aj" files. Code in ".java" files should be pure Java code. There is a file extension conversion wizard to help with this process, which can be launched by right-clicking on a project or source file and selecting the appropriate option from the context menu.

Known limitations and workarounds

Supported versions of Eclipse. We support Eclipse 3.0 and 3.1M3, but do not support 3.1M1 or 3.1M2 or even 3.1M4 (which came out after this release).

Moving .aj files within the package explorer. Most files can be dragged to new locations within the package explorer, but unfortunately this isn't currently possible with .aj files. You should however be able to copy and paste an .aj file to a new location. You can also drag and drop .aj files from the package explorer to applications outside of Eclipse, and back again.

File conversion wizard with excluded inner aspects. The default mode of this wizard converts source files containing aspects to .aj files. This includes Java classes which contain innner aspects. However inner aspects are currently only detected in classes which are included in the current build configuration. Therefore if you're using this mode of the wizard you are recommended to make sure any classes with inner aspects are first included in the current configuration.

Organise imports with imported aspects. As noted in the new and noteworthy, this operation is possible for aspects contained in .aj files, but it isn't aware of imported aspects. So if your aspect is extending an abstract aspect which is in a different package, you need to import it. But running organise imports will not add it, and if it is there already, it will unhelpfully remove it! You can at least do an undo to get it back. Similiarly, the add import action will not work for imported aspects.

Checking out AspectJ projects from CVS. Previously, if you had Java projects which depend on AspectJ projects, and you checked out all of the projects from CVS, then the dependent Java projects would say that they can't be built until their prerequisite projects have been rebuilt. Rebuilding the AspectJ projects in this case does not fix the problem. This issue has been reported as bug 73435. This release contains a workaround for this problem, which is to detect this situation and then disable the Eclipse preference "Abort build when build path errors occur", which is located under Preferences > Java > Compiler > Build Path. This results in both the AspectJ projects and the Java projects building. Note that if the dependent java projects use project settings rather than workspace settings, then it is these which are updated to not abort a build when there are classpath errors and you are able to revert your workspace settings without seeing the problem marker against your java projects. If you don't want your workbench settings to change, then converting your AspectJ projects to Java projects then back to AspectJ projects also solves this problem.

Cross References view. The cross references view is a new contribution to AJDT and as such you may experience some problems. It is already known that 'declare soft' references are not shown. If you discover a bug please report it, if it has not already been reported, at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AJDT