This document contains migration information and known limitations. It will be updated as necessary as any new problems and workarounds are discovered.
Last updated: 26 October 2004.
It is easiest to install 1.2.0M1 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. This means that any files open with the editor from a previous version of AJDT will not be restored after upgrading to 1.2.0M1, 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, 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.0M1, 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.
Supported versions of Eclipse. This release does not work well with any Eclipse 3.1 milestone builds. For the most stable environment please use Eclipse 3.0.0 or Eclipse 3.0.1.
Generating ajdoc. This capability is not working due to restructuring of the AJDE plugin. See bug 76903. This problem has been fixed in the latest development build.
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.