Fix some AsciiDoc links (WIP)

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

77 files changed, 585 insertions, 6563 deletions

diff --git a/docs/adk15ProgGuideDB/covariance.adoc b/docs/adk15ProgGuideDB/covariance.adoc
index 121f1b8bb..fa1a2ddcc 100644
--- a/docs/adk15ProgGuideDB/covariance.adoc
+++ b/docs/adk15ProgGuideDB/covariance.adoc
@@ -46,7 +46,7 @@ A A.whoAreYou()
 B B.whoAreYou()
 ....
 
-Following the join point matching rules given in xref:#jpsigs[???],
+Following the join point matching rules given in xref:joinpointsignatures.adoc#jpsigs[Join Point Signatures].
 
 call(* whoAreYou())::
   Matches both calls, (since each call join point has at least one
diff --git a/docs/adk15ProgGuideDB/varargs.adoc b/docs/adk15ProgGuideDB/varargs.adoc
index dce7b8030..fe1500c1f 100644
--- a/docs/adk15ProgGuideDB/varargs.adoc
+++ b/docs/adk15ProgGuideDB/varargs.adoc
@@ -59,7 +59,7 @@ pointcut expressions and bound as formals in advice.
 ==== Matching signatures based on variable length argument types
 
 Recall from the definition of signature patterns given in the chapter on
-annotations (xref:#signaturePatterns[???]), that `MethodPattern` and
+annotations (xref:annotations.adoc#signaturePatterns[Signature Patterns]), that `MethodPattern` and
 `ConstructorPattern` are extended to allow a `varargs` pattern in the
 last argument position of a method or constructor signature.
 
diff --git a/docs/devGuideDB/aj.adoc b/docs/devGuideDB/aj.adoc
index 6eb84b8cc..28b50e976 100644
--- a/docs/devGuideDB/aj.adoc
+++ b/docs/devGuideDB/aj.adoc
@@ -21,7 +21,7 @@ Users should define the environment variables `CLASSPATH` and
 `ASPECTPATH`.
 
 For more information and alternatives for load-time weaving, see
-xref:#ltw[???].
+xref:ltw.adoc#ltw[Load-Time Weaving].
 
 === Examples
 
diff --git a/docs/devGuideDB/ajbrowser.adoc b/docs/devGuideDB/ajbrowser.adoc
index d0124bd01..26c762e57 100644
--- a/docs/devGuideDB/ajbrowser.adoc
+++ b/docs/devGuideDB/ajbrowser.adoc
@@ -10,7 +10,7 @@ crosscutting structure.
 The AspectJ Browser can edit program source files, compile using the
 AspectJ compiler `ajc` run a program, and graphically navigate the
 program's crosscutting structure. For more information on `ajc`, see
-xref:#ajc-ref[???].
+xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver].
 
 Launch the browser from the command line either by typing "ajbrowser" to
 invoke the script in `{aspectj}/bin` (if AspectJ is installed correctly)
@@ -32,7 +32,7 @@ optionally some additional compile arguments). Because `ajc` requires
 all sources to be specified (at least using the `-sourceroots` option),
 most users create `.lst` files that list the files to compile (one
 argument per line, globbing permitted - for more details, see
-xref:#ajc-ref[???]).
+xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver]).
 
 To work with a particular program, select the corresponding ".lst" build
 configuration file from the GUI using the File menu, "open" item, or by
diff --git a/docs/devGuideDB/ajc.adoc b/docs/devGuideDB/ajc.adoc
index 026eeb79a..02d49b788 100644
--- a/docs/devGuideDB/ajc.adoc
+++ b/docs/devGuideDB/ajc.adoc
@@ -15,7 +15,7 @@
 The `ajc` command compiles and weaves AspectJ and Java source and .class
 files, producing .class files compliant with any Java VM (1.1 or later).
 It combines compilation and bytecode weaving and supports incremental
-builds; you can also weave bytecode at run-time using xref:#ltw[???].
+builds; you can also weave bytecode at run-time using xref:ltw.adoc#ltw[Load-Time Weaving].
 
 The arguments after the options specify the source file(s) to compile.
 To specify source classes, use `-inpath` (below). Files may be listed
@@ -255,7 +255,7 @@ http://java.sun.com/docs/books/vmspec/index.html[The Java Virtual
 Machine Specification, Second Edition] and runs on any Java 2 compatible
 platform. The code it generates runs on any Java 1.1 or later compatible
 platform. For more information on compatibility with Java and with
-previous releases of AspectJ, see xref:#versionCompatibility[???].
+previous releases of AspectJ, see xref:compatibility.adoc#versionCompatibility[Version Compatibility].
 
 ==== Examples
 
diff --git a/docs/devGuideDB/ajdejbuilder.adoc b/docs/devGuideDB/ajdejbuilder.adoc
index 0bf794693..445a61a89 100644
--- a/docs/devGuideDB/ajdejbuilder.adoc
+++ b/docs/devGuideDB/ajdejbuilder.adoc
@@ -74,7 +74,7 @@ debugging the project.
 
 == Navigating the Program Structure
 
-Navigation of program structure is provided by the xref:#ajbrowser[???],
+Navigation of program structure is provided by the xref:ajbrowser.adoc#ajbrowser[AspectJ Browser],
 so apart from a JBuilder look and feel, the extra navigation AspectJ
 allows work as described there. In particular, you can use views with
 labels 1, 2 and 4 of the second screenshot to navigate structure using
@@ -84,9 +84,9 @@ toolbar shown by label 3 of the second screenshot.
 == Manipulating Build Configurations
 
 Build configurations can be manipulated adding, removing, and editing
-build configuration files. The xref:#ajbrowser[???] is used to select
+build configuration files. The xref:ajbrowser.adoc#ajbrowser[AspectJ Browser] is used to select
 the current build configuration. Configurations are represented by
-".lst" files which are described in the xref:#ajc[???] documentation.
+".lst" files which are described in the xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver] documentation.
 
 === Adding and Removing Build Configurations
 
diff --git a/docs/devGuideDB/ajdoc.adoc b/docs/devGuideDB/ajdoc.adoc
index 0ea3b7032..2a929e3db 100644
--- a/docs/devGuideDB/ajdoc.adoc
+++ b/docs/devGuideDB/ajdoc.adoc
@@ -38,10 +38,10 @@ sending the output to the `docDir` output directory.
 ajdoc -d docDir @argfile.lst
 ....
 
-See the xref:#ajc[ajc documentation] for details on the text file
+See xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver] for details on the text file
 format.
 
-`ajdoc` honours `ajc` options. See the xref:#ajc_options[ajc
+`ajdoc` honours `ajc` options. See the xref:ajc.adoc#ajc_options[ajc
 documentation] for details on these options.
 
 `ajdoc` currently requires the `tools.jar` from J2SE 1.3 to be on the
diff --git a/docs/devGuideDB/antsupport.adoc b/docs/devGuideDB/antsupport.adoc
index f98b6e5be..12de6f296 100644
--- a/docs/devGuideDB/antsupport.adoc
+++ b/docs/devGuideDB/antsupport.adoc
@@ -76,7 +76,7 @@ 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
-xref:#ajc-ref[???]. Unlike Javac or the Javac Ant task, this task always
+xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver]. Unlike Javac or the Javac Ant task, this task always
 compiles the specified files since aspects can apply to other (updated)
 files. For a workaround, see xref:#antTasks-iajc-uptodate[Avoiding clean
 compiles].
diff --git a/docs/devGuideDB/ltw.adoc b/docs/devGuideDB/ltw.adoc
index 3000715a7..ac58dfca7 100644
--- a/docs/devGuideDB/ltw.adoc
+++ b/docs/devGuideDB/ltw.adoc
@@ -98,18 +98,18 @@ Agents::
 Command-line wrapper scripts `aj`::
   The `aj` command runs Java programs in Java 1.4 or later by setting up
   `WeavingURLClassLoader` as the system class loader. For more
-  information, see xref:#aj[???].
+  information, see xref:#aj[`aj`, the AspectJ load-time weaving launcher].
   +
   The `aj5` command runs Java programs in Java 5 by using the
   `-javaagent:pathto/aspectjweaver.jar` option described above. For more
-  information, see xref:#aj[???].
+  information, see xref:#aj[`aj`, the AspectJ load-time weaving launcher].
 Custom class loader::
   A public interface is provided to allow a user written class loader to
   instantiate a weaver and weave classes after loading and before
   defining them in the JVM. This enables load-time weaving to be
   supported in environments where no weaving agent is available. It also
   allows the user to explicitly restrict by class loader which classes
-  can be woven. For more information, see xref:#aj[???] and the API
+  can be woven. For more information, see xref:#aj[`aj`, the AspectJ load-time weaving launcher] and the API
   documentation and source for `WeavingURLClassLoader` and
   `WeavingAdapter`.
 
diff --git a/docs/devGuideDB/tools-intro.adoc b/docs/devGuideDB/tools-intro.adoc
index 73c022899..92508cbed 100644
--- a/docs/devGuideDB/tools-intro.adoc
+++ b/docs/devGuideDB/tools-intro.adoc
@@ -77,8 +77,8 @@ AspectJ program.)
 ==== Classpath, inpath, and aspectpath
 
 AspectJ introduces two new paths for the binary input to the weaver
-which you'll find referenced in xref:#ajc-ref[???],
-xref:#ajbrowser[???], xref:#antTasks[???], and xref:#ltw[???].
+which you'll find referenced in xref:ajc.adoc[`ajc`, the AspectJ compiler/weaver],
+xref:ajbrowser.adoc#ajbrowser[AspectJ Browser], xref:antsupport.adoc[AspectJ Ant Tasks], and xref:ltw.adoc#ltw[Load-Time Weaving].
 
 As in Java, the `classpath` is where the AspectJ tools resolve types
 specified in the program. When running an AspectJ program, the classpath
diff --git a/docs/developer/ajdt/ajdt.core.workitems.adoc b/docs/developer/ajdt/ajdt.core.workitems.adoc
index a6250d7b4..8d08e23f1 100644
--- a/docs/developer/ajdt/ajdt.core.workitems.adoc
+++ b/docs/developer/ajdt/ajdt.core.workitems.adoc
@@ -114,7 +114,7 @@ etc. depend.
 
 This work package enables the source code of an aspectJ program to be
 modelled as a structured document. Which user-interface actions will be
-broken without this??? (refactoring?)
+broken without this? (Refactoring?)
 
 . In the package org.aspectj.jdt.core.dom, add counterparts to the AspectJ nodes
   already defined in org.aspectj.internal.compiler.ast (not needed first time round?)
diff --git a/docs/dist/README-AspectJ.adoc b/docs/dist/README-AspectJ.adoc
index ecceb0a3e..893a67114 100644
--- a/docs/dist/README-AspectJ.adoc
+++ b/docs/dist/README-AspectJ.adoc
@@ -104,7 +104,8 @@ ____
 
 '''''
 
-=== [#configInstructions]#4. Configuration Instructions#
+[[configInstructions]]
+=== 4. Configuration Instructions
 
 ==== 4.1 Adding `<aspectj install dir>/lib/aspectjrt.jar` to your classpath
 
diff --git a/docs/dist/doc/README-11.adoc b/docs/dist/doc/README-11.adoc
index 0464ba88b..377d18588 100644
--- a/docs/dist/doc/README-11.adoc
+++ b/docs/dist/doc/README-11.adoc
@@ -1,8 +1,9 @@
+[[readme-1_1]]
+== AspectJ 1.1 Readme
+
 [.small]#© Copyright 2002 Palo Alto Research Center, Incorporated, 2003
 Contributors. All rights reserved.#
 
-== AspectJ 1.1 Readme
-
 This is the initial release of AspectJ 1.1. It includes a small number
 of new language features as well as major improvements to the
 functionality of the tools.
@@ -30,7 +31,8 @@ xref:#knownLimitations[known limitations].
 
 '''''
 
-=== [#language]#The Language#
+[[language]]
+=== The Language
 
 AspectJ 1.1 is a slightly different language than AspectJ 1.0. In all
 but a few cases, programs written in AspectJ 1.0 should compile
@@ -116,7 +118,8 @@ specifier] in this release, but it may well be in a future release.
 
 '''''
 
-=== [#compiler]#The Compiler#
+[[compiler]]
+=== The Compiler
 
 The compiler for AspectJ 1.1 is different than the compiler for AspectJ
 1.0. While this document describes the differences in the compiler, it's
@@ -169,7 +172,7 @@ compiler:
 -nocomment and -workingdir
 * xref:#NO_STRICT_LENIENT[The -strict and -lenient options]
 * xref:#NO_PORTING[The -porting option]
-* xref:#13_REQUIRED[J2SE 1.2 is not supported; J2SE 1.3 or later is
+* xref:#_13_REQUIRED[J2SE 1.2 is not supported; J2SE 1.3 or later is
 required.]
 
 A short description of the options ajc accepts is available with
@@ -190,7 +193,8 @@ xref:#ONE_FOUR_METHOD_SIGNATURES[the -1.4 flag].
 
 '''''
 
-=== [#tools]#Support Tools#
+[[tools]]
+=== Support Tools
 
 This release includes an Ant task for old-style 1.0 build scripts, a new
 task for all the new compiler options, and a CompilerAdapter to support
@@ -219,7 +223,8 @@ support is available.
 
 '''''
 
-=== [#runtime]#The Runtime Library#
+[[runtime]]
+=== The Runtime Library
 
 This release has minor additions to the runtime library classes. As with
 any release, you should compile and run with the runtime library that
@@ -234,7 +239,8 @@ and will always return 0.
 
 '''''
 
-=== [#devenv]#The AJDE Tools#
+[[devenv]]
+=== The AJDE Tools
 
 The AspectJ Browser supports incremental compilation and running
 programs. AJDE for JBuilder, AJDE for NetBeans, and AJDE for Emacs are
@@ -243,7 +249,8 @@ the batch-build mode of the new compiler.
 
 '''''
 
-=== [#sources]#The Sources and the Licenses#
+[[sources]]
+=== The Sources and the Licenses
 
 The AspectJ tools sources are available under the
 https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt[Eclipse Public
@@ -253,7 +260,8 @@ faq.html#q:buildingsource[building sources].
 
 '''''
 
-=== [#distribution]#The AspectJ distribution#
+[[distribution]]
+=== The AspectJ distribution
 
 AspectJ 1.0 had many distributions - for the tools, the documentation,
 each IDE support package, their respective sources, and the Ant tasks -
@@ -270,9 +278,11 @@ SourceForge projects.
 
 '''''
 
-=== [#details]#Details# of some language and compiler changes
+[[details]]
+=== Details of some language and compiler changes
 
-==== [#ASPECT_INSTANTIATION_AND_ADVICE]#Aspect Instantiation and Advice#
+[[ASPECT_INSTANTIATION_AND_ADVICE]]
+==== Aspect Instantiation and Advice
 
 In AspectJ 1.0.6, we made an effort to hide some complications with
 Aspect instantiation from the user. In particular, the following code
@@ -339,7 +349,8 @@ exception than a NullPointerException for this case. In AspectJ 1.1,
 both of the above programs will throw
 org.aspectj.lang.NoAspectBoundException.
 
-==== [#THROWS_PATTERN]#Matching based on throws#
+[[THROWS_PATTERN]]
+==== Matching based on throws
 
 Type patterns may now be used to pick out methods and constructors based
 on their throws clauses. This allows the following two kinds of
@@ -400,7 +411,8 @@ declares that it throws IOException. [2] WILL match the method m(),
 because method m's throws clause declares the it throws some exception
 which does not match IOException, i.e. RuntimeException.
 
-==== [#NEW_PCDS]#New kinded pointcut designators#
+[[NEW_PCDS]]
+==== New kinded pointcut designators
 
 AspectJ 1.0 does not provide kinded pointcut designators for two (rarely
 used) join points: preinitialization (the code that runs before a super
@@ -417,7 +429,8 @@ aspect. +
 join points where the initialization process is entered through
 `ConstructorPattern`.
 
-==== [#PER_TYPE]#New pertype aspect specifier# (not in 1.1)
+[[PER_TYPE]]
+==== New pertype aspect specifier (not in 1.1)
 
 We strongly considered adding a pertype aspect kind to 1.1. This is
 somewhat motivated by the new
@@ -460,7 +473,8 @@ the most common uses of this idiom.
 
 In any case, this feature will not be in AspectJ 1.1.
 
-==== [#SINGLE_INTERCLASS_TARGET]#One target for intertype declarations#
+[[SINGLE_INTERCLASS_TARGET]]
+==== One target for intertype declarations
 
 Intertype declarations (once called "introductions") in AspectJ 1.1 can
 only have one target type. So the following code intended to declare
@@ -494,7 +508,8 @@ ability to add static fields to many classes. We believe that the
 xref:#PER_TYPE[pertype proposal] provides this functionality in a much
 more usable form.
 
-==== [#UNAVAILABLE_JOIN_POINTS]#No initializer execution join points#
+[[UNAVAILABLE_JOIN_POINTS]]
+==== No initializer execution join points
 
 AspectJ 1.1 does not consider initializer execution a principled join
 point. The collection of initializer code (the code that sets fields
@@ -502,13 +517,15 @@ with initializers and the code in non-static initializer blocks) is
 something that makes sense only in Java source code, not in Java
 bytecode.
 
-==== [#AFTER_HANDLER]####No after or around advice on handler join points
+[[AFTER_HANDLER]]
+==== No after or around advice on handler join points
 
 The end of an exception handler is underdetermined in bytecode, so ajc
 will not implement after or around advice on handler join points,
 instead signaling a compile-time error.
 
-==== [#CONSTRUCTOR_EXECUTION_IS_BIGGER]#Initializers run inside constructor execution join points#
+[[CONSTRUCTOR_EXECUTION_IS_BIGGER]]
+==== Initializers run inside constructor execution join points
 
 The code generated by the initializers in Java source code now runs
 inside of constructor execution join points. This changes how before
@@ -544,7 +561,8 @@ programmers using before advice on constructor execution must always
 assume incomplete object initialization, since the constructor has not
 yet run.
 
-==== [#INTER_TYPE_FIELD_INITIALIZERS]#Inter-type field initializers#
+[[INTER_TYPE_FIELD_INITIALIZERS]]
+==== Inter-type field initializers
 
 The initializer, if any, of an inter-type field definition runs before
 the class-local initializers of its target class.
@@ -571,7 +589,8 @@ We felt there would be too much surprise if a constructor called a
 method (thus incrementing the method count) and then the field was reset
 to zero after the constructor was done.
 
-==== [#WITHIN_MEMBER_TYPES]#Small limitations of the within pointcut#
+[[WITHIN_MEMBER_TYPES]]
+==== Small limitations of the within pointcut
 
 Because of the guarantees made (and not made) by the Java classfile
 format, there are cases where AspectJ 1.1 cannot guarantee that the
@@ -609,12 +628,14 @@ example:
 We believe the non-guarantee is small, and we haven't verified that it
 is a problem in practice.
 
-==== [#WITHIN_CODE]#Small limitations of the withincode pointcut#
+[[WITHIN_CODE]]
+==== Small limitations of the withincode pointcut
 
 The withincode pointcut has similar issues to those described above for
 within.
 
-==== [#INSTANCEOF_ON_WILD]#Can't do instanceof matching on type patterns with wildcard#
+[[INSTANCEOF_ON_WILD]]
+==== Can't do instanceof matching on type patterns with wildcard
 
 The pointcut designators this, target and args specify a dynamic test on
 their argument. These tests can not be performed on type patterns with
@@ -660,7 +681,8 @@ based on static types. So, you can use 'within(com.bigboxco..*+)' to
 match any code lexically within one of your classes or a subtype
 thereof. This is often a good choice.
 
-==== [#NO_SOURCE_COLUMN]#SourceLocation.getColumn()#
+[[NO_SOURCE_COLUMN]]
+==== SourceLocation.getColumn()
 
 The Java .class file format contains information about the source file
 and line numbers of its contents; however, it has no information about
@@ -669,7 +691,8 @@ of column information in the reflection API. So, any calls to
 thisJoinPoint.getSourceLocation().getColumn() will be marked as
 deprecated by the compiler, and will always return 0.
 
-==== [#ASPECT_PRECEDENCE]#Aspect precedence#
+[[ASPECT_PRECEDENCE]]
+==== Aspect precedence
 
 AspectJ 1.1 has a new declare form:
 
@@ -791,7 +814,8 @@ This no longer works in AspectJ 1.1, since declare precedence only
 matters for concrete aspects. Thus, if you want to regain this kind of
 precedence change, you will need to refactor your aspects.
 
-==== [#SOURCEROOT]#The -sourceroots option#
+[[SOURCEROOT]]
+==== The -sourceroots option
 
 The AspectJ 1.1 compiler now accepts a -sourceroots option used to pass
 all .java files in particular directories to the compiler. It takes
@@ -812,7 +836,8 @@ of
 This option may be used in conjunction with lst files, listing .java
 files on the command line, and the -injars option.
 
-==== [#BYTECODE_WEAVING]#The -injars option#
+[[BYTECODE_WEAVING]]
+==== The -injars option
 
 The AspectJ 1.1 compiler now accepts an -injars option used to pass all
 .class files in a particular jar file to the compiler. It takes either a
@@ -838,7 +863,8 @@ compiler), they should not be compiled with any non-abstract aspects.
 This option may be used in conjunction with lst files, listing .java
 files on the command line, and the -sourceroots option.
 
-==== [#OUTJAR]#The -outjar option#
+[[OUTJAR]]
+==== The -outjar option
 
 The -outjar option takes the name of a jar file into which the results
 of the compilation should be put. For example:
@@ -850,7 +876,8 @@ of the compilation should be put. For example:
 
 No meta information is placed in the output jar file.
 
-==== [#INCREMENTAL]#Incremental compilation#
+[[INCREMENTAL]]
+==== Incremental compilation
 
 The AspectJ 1.1 compiler now supports incremental compilation. When ajc
 is called with the -incremental option, it must also be passed a
@@ -863,7 +890,8 @@ recompiles those input files that need recompiling.
 
 This new functionality is still only lightly tested.
 
-==== [#XNOWEAVE]#-XnoWeave, a compiler option to suppress weaving#
+[[XNOWEAVE]]
+==== -XnoWeave, a compiler option to suppress weaving
 
 The -XnoWeave option suppresses weaving, and generates classfiles and
 that can be passed to ajc again (through the -injars option) to generate
@@ -876,7 +904,8 @@ the `-aspectpath` option is a much better option. There may still be use
 cases for unwoven classfiles, but we've moved the flag to experimental
 status.
 
-==== [#BINARY_ASPECTS]#-aspectpath, working with aspects in .class/.jar form#
+[[BINARY_ASPECTS]]
+==== -aspectpath, working with aspects in .class/.jar form
 
 When aspects are compiled into classfiles, they include all information
 necessary for the ajc compiler to weave their advice and deal with their
@@ -886,7 +915,8 @@ a compilation process, they must be passed to the compiler on the
 and any aspects that are found will be enabled during the compilation.
 The binary forms of this aspects will be untouched.
 
-==== [#NO_CALLEE_SIDE_CALL]#Callee-side call join points#
+[[NO_CALLEE_SIDE_CALL]]
+==== Callee-side call join points
 
 The 1.0 implementation of AspectJ, when given:
 
@@ -994,7 +1024,8 @@ How will this affect developers?
 * When using the call PCD but only supplying the callee code, supply the
 calling code or use the execution PCD instead.
 
-==== [#OTHER_X_OPTIONS]#Various -X options#
+[[OTHER_X_OPTIONS]]
+==== Various -X options
 
 The AspectJ 1.0 compiler supported a number of options that started with
 X, for "experimental". Some of them will not be supported in 1.1, either
@@ -1012,7 +1043,8 @@ xref:#XNOINLINE[`-XnoInline`].
 because we're now always using (what we believe to be) safe prefixes.
 * -Xlint: Still supported, with xref:#XLINT[various options].
 
-==== [#ERROR_MESSAGES]#Some confusing error messages#
+[[ERROR_MESSAGES]]
+==== Some confusing error messages
 
 Building on the eclipse compiler has given us access to a very
 sophisticated problem reporting system as well as highly optimized error
@@ -1022,7 +1054,8 @@ correctly this can sometimes lead to cascading error messages where a
 single small syntax error will produce dozens of other messages. Please
 report any very confusing error messages as bugs.
 
-==== [#MESSAGE_CONTEXT]#Source code context is not shown for errors and warnings detected during bytecode weaving#
+[[MESSAGE_CONTEXT]]
+==== Source code context is not shown for errors and warnings detected during bytecode weaving
 
 For compiler errors and warnings detected during bytecode weaving,
 source code context will not be displayed. In particular, for declare
@@ -1032,7 +1065,8 @@ the source code is available; in cases where source code is not
 available, we might specify the signature of the offending code. For
 more information, see bug 31724.
 
-==== [#XLINT]#The -Xlint option#
+[[XLINT]]
+==== The -Xlint option
 
 `-Xlint:ignore,error,warning` will set the level for all Xlint warnings.
 `-Xlint`, alone, is an abbreviation for `-Xlint:warning`.
@@ -1048,23 +1082,27 @@ warn about more potentially dangerous situations, such as the
 potentially unsafe casts used by very polymorphic uses of proceed in
 around advice.
 
-==== [#NO_SOURCE]#Source-specific options#
+[[NO_SOURCE]]
+==== Source-specific options
 
 Because AspectJ 1.1 does not generate source code after weaving, the
 source-code-specific options -preprocess, -usejavac, -nocomment and
 -workingdir options are meaningless and so not supported.
 
-==== [#NO_STRICT_LENIENT]#The -strict and -lenient options#
+[[NO_STRICT_LENIENT]]
+==== The -strict and -lenient options
 
 Because AspectJ 1.1 uses the Eclipse compiler, which has its own
 mechanism for changing strictness, we no longer support the -strict and
 -lenient options.
 
-==== [#NO_PORTING]#The -porting option#
+[[NO_PORTING]]
+==== The -porting option
 
 AspectJ 1.1 does not have a -porting option.
 
-==== [#13_REQUIRED]#J2SE 1.3 required#
+[[_13_REQUIRED]]
+==== J2SE 1.3 required
 
 Because we build on Eclipse, the compiler will no longer run under J2SE
 1.2. You must run the compiler (and all tools based on the compiler)
@@ -1072,7 +1110,8 @@ using J2SE 1.3 or later. The code generated by the compiler can still
 run on Java 1.1 or later VM's if compiled against the correct runtime
 libraries.
 
-==== [#DEFAULT_CONSTRUCTOR_CONFLICT]#Default constructors#
+[[DEFAULT_CONSTRUCTOR_CONFLICT]]
+==== Default constructors
 
 AspectJ 1.1 does not allow the inter-type definition of a zero-argument
 constructor on a class with a visible default constructor. So this is no
@@ -1097,7 +1136,8 @@ and can be referenced by other classes, and has code generated for it in
 classfiles. Therefore, it was an oversight that AspectJ 1.0.6 allowed
 such an "overriding" inter-type constructor definition.
 
-==== [#SUPER_IFACE_INITS]#Initialization join points for super-interfaces#
+[[SUPER_IFACE_INITS]]
+==== Initialization join points for super-interfaces
 
 In AspectJ, interfaces may have non-static members due to inter-type
 declarations. Because of this, the semantics of AspectJ defines the
@@ -1143,7 +1183,8 @@ the initializers for a type's superclass are run before the initializers
 for its superinterfaces.
 ____
 
-==== [#VOID_FIELD_SET]#Field Set Join Points#
+[[VOID_FIELD_SET]]
+==== Field Set Join Points
 
 In AspectJ 1.0.6, the join point for setting a field F had, as a return
 type, F's type. This was "java compatible" because field assignment in
@@ -1193,14 +1234,16 @@ So, because it's easier to implement, and because we believe that this
 is the last possibility to make the semantics more useful, we have made
 set join points have a void return type in 1.1.
 
-==== [#XNOINLINE]#The -XnoInline Option#
+[[XNOINLINE]]
+==== The -XnoInline Option
 
 The `-XnoInline` option to indicate that no inlining of any kind should
 be done. This is purely a compiler pragma: No program semantics (apart
 from stack traces) will be changed by the presence or absence of this
 option.
 
-==== [#TARGET_TYPES_MADE_PUBLIC]#Target types made public#
+[[TARGET_TYPES_MADE_PUBLIC]]
+==== Target types made public
 
 Even in 1.0.6, the AspectJ compiler has occasionally needed to convert
 the visibility of a package-level class to a public one. This was
@@ -1218,7 +1261,8 @@ various implementation tricks if they become a serious concern, but did
 not encounter them as such a concern when they were done in the 1.0.6
 implementation.
 
-==== [#STRINGBUFFER]#String + now advised#
+[[STRINGBUFFER]]
+==== String + now advised
 
 In Java, the + operator sometimes results in StringBuffer objects being
 created, appended to, and used to generate a new String. Thus,
@@ -1271,7 +1315,8 @@ call(* *(int)) && args(i) && !within(A)
 call(* *(int)) && args(i) && !target(StringBuffer)
 ....
 
-==== [#ONE_FOUR_METHOD_SIGNATURES]#The -1.4 flag and method signatures#
+[[ONE_FOUR_METHOD_SIGNATURES]]
+==== The -1.4 flag and method signatures
 
 Consider the following aspect
 
@@ -1307,7 +1352,8 @@ OO programmers don't want to care about the static type of an object at
 a call site, but only want to know the dynamic instanceof behavior which
 is what the target matching will handle.
 
-=== [#knownLimitations]#Known limitations#
+[[knownLimitations]]
+=== Known limitations
 
 The AspectJ 1.1.0 release contains a small number of known limitations
 relative to the AspectJ 1.1 language. For the most up-to-date
diff --git a/docs/dist/doc/README-11.html b/docs/dist/doc/README-11.html
deleted file mode 100644
index 27e5e7e41..000000000
--- a/docs/dist/doc/README-11.html
+++ /dev/null
@@ -1,1539 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2002 Palo Alto Research Center, Incorporated,
-2003 Contributors.
-All rights reserved.
-</small></div>
-
-
-<h1>AspectJ 1.1 Readme</h1>
-
-<p> This is the initial release of AspectJ 1.1.  It includes a small
-number of new language features as well as major improvements to the
-functionality of the tools.   </p>
-
-<p>
-This document describes the differences between
-AspectJ versions 1.1 and 1.0.6.
-Users new to AspectJ need only read
-the <a href="progguide/index.html">AspectJ Programming Guide</a>
-since it describes the 1.1 language.
-Users familiar with AspectJ 1.0 may find this document
-a quicker way to learn what changed in the language
-and tools, and should use it as a guide for porting
-programs from 1.0 to 1.1.
-</p>
-
-<p>This document first summarizes changes from the 1.0 release in
-</p>
-
-<ul>
-  <li><a href="#language">the language</a>,</li>
-  <li><a href="#compiler">the compiler</a>,</li>
-  <li><a href="#tools">the support tools</a>,</li>
-  <li><a href="#runtime">the runtime</a>,</li>
-  <li><a href="#devenv">the development environment support</a>,</li>
-  <li><a href="#sources">the sources</a>, and</li> 
-  <li><a href="#distribution">the distribution</a>,</li>
-</ul>
-
-<p> then <a href="#details">details</a> some of the language 
-    and compiler changes,
-    and finally points readers to the bug database for any
-    <a href="#knownLimitations">known limitations</a>.
-</p>
-
-<!-- ============================== -->
-<hr>
-<h2><a name="language">The Language</a></h2>
-
-  <p> AspectJ 1.1 is a slightly different language than AspectJ 1.0.
-  In all but a few cases, programs written in AspectJ 1.0 should
-  compile correctly in AspectJ 1.1.  In many cases, there are
-  new or preferred forms in AspectJ 1.1.  However, some AspectJ 1.0
-  features have changed in 1.1, so some 1.0 programs
-  will not compile or will run differently in 1.1.
-  The corresponding features are marked below as compile-time 
-  or run-time incompatible (<em>CTI</em> or <em>RTI</em>, respectively).
-  When the language change involves a move in the static shadow effective
-  at run-time but also apparent at compile-time (e.g., in declare
-  error or warning statements), it is marked <em>CRTI</em>.
-  Programs using run-time incompatible forms should be verified that 
-  they are behaving as expected in 1.1.
-  </p>
-
-  <p>
-  Most changes to the language are additions to expressibility
-  requested by our users:
-  </p>
-
-  <ul>
-    <li><a href="#THROWS_PATTERN">Matching based on throws</a>: You can
-    now make finer discriminations between methods based on declared
-    exceptions. </li>
-
-    <li><a href="#NEW_PCDS">New kinded pointcut designators</a>: Now
-    every kind of join point has a corresponding kinded pointcut
-    designator. </li>
-  </ul>
-
-  <p> Some are have different behavior in edge cases but offer
-  improved power and clarity: </p>
-
-  <ul>
-    <li><a href="#ASPECT_PRECEDENCE">New aspect precedence form</a>:
-    AspectJ 1.1 has a new declare form, <code>declare
-    precedence</code>, that replaces the "dominates"
-    clause on aspects.  (<em>CTI</em>) </li>
-
-    <li>The order of <a href="#SUPER_IFACE_INITS">initialization join
-    points for super-interfaces</a> has been clarified. (<em>RTI</em>) </li>
-  </ul>
-
-  <p> But in order to support weaving into bytecode effectively,
-  several incompatible changes had to be made to the language: </p>
-
-  <ul>
-    <li>A class's default constructor may
-    <a href="#DEFAULT_CONSTRUCTOR_CONFLICT">conflict</a> with an
-    inter-type constructor. (<em>CTI</em>) </li>
-
-    <li><a href="#NO_CALLEE_SIDE_CALL">No callee-side call join
-    points</a>: The AspectJ 1.1 compiler does not expose call join
-    points unless it is given the calling code. (<em>CRTI</em>) </li>
-         
-    <li><a href="#SINGLE_INTERCLASS_TARGET">One target for intertype
-    declarations</a>. (<em>CTI</em>) </li>
-
-    <li><a href="#UNAVAILABLE_JOIN_POINTS">No initializer execution join
-    points</a>. (<em>RTI</em>)</li>
-
-    <li><a href="#AFTER_HANDLER">No after or around advice on handler 
-	join points</a>. (<em>CTI</em>) </li>
-
-    <li><a href="#CONSTRUCTOR_EXECUTION_IS_BIGGER">Initializers run
-    inside constructor execution join points</a>.  (<em>RTI</em>)</li>
-
-    <li><a href="#INTER_TYPE_FIELD_INITIALIZERS">inter-type field
-    initializers</a> run before class-local field initializers. (<em>RTI</em>) </li>
-
-    <li><a href="#WITHIN_MEMBER_TYPES">Small limitations of the within
-    pointcut.</a> (<em>CRTI</em>)</li>
-
-    <li><a href="#WITHIN_CODE">Small limitations of the withincode
-    pointcut.</a> (<em>CRTI</em>)</li>
-
-    <li><a href="#INSTANCEOF_ON_WILD">Can't do instanceof matching on
-        type patterns with wildcards</a>. (<em>CTI</em>) </li>
-
-    <li><a href="#NO_SOURCE_COLUMN">SourceLocation.getColumn() is
-        deprecated and will always return 0</a>. (<em>RTI</em>) </li>
-
-    <li>The interaction between aspect instantiation and advice has been
-        <a href="#ASPECT_INSTANTIATION_AND_ADVICE">clarified</a>.  (<em>RTI</em>) </li>
-
-    <li><a href="#STRINGBUFFER">The String + operator is now correctly advised</a>.
-        (<em>CRTI</em>) </li>
-  </ul>
-
-  <p><a name="NEW_LIMITATIONS">There</a> are a couple of language
-  limitations for things that are rarely used that make the
-  implementation simpler, so we have restricted the language accordingly.
-  </p>
-
-  <ul>
-    <li><a href="#VOID_FIELD_SET">Field set join points now have a
-    <code>void</code> return type.</a>  This will require 
-    porting of code that uses the <code>set</code> PCD in conjunction
-    with after-returning or around advice.  (<em>CTI</em>) <p></p></li>
-
-    <li>'declare soft: TYPE: POINTCUT;' - AspectJ 1.1 only 
-    accepts TYPE rather than a TYPE_PATTERN.  
-    This limitation makes declare soft
-    much easier to implement efficiently.  (<em>CTI</em>) <p></p></li>
-
-    <li>Inter-type field declarations only allow a single field per
-    line, i.e. this is now illegal 'int C.field1, D.field2;' This must
-    instead be, 'int C.field1; int D.field2;' (<em>CTI</em>) <p></p></li>
-    
-    <li>We did not implement the handling of more than one
-    <code>..</code> wildcard in args PCD's (rarely encountered in the
-    wild) because we didn't have the time.  This might be available
-    in later releases if there is significant outcry. (<em>CTI</em>) </li>
-    
-  </ul>
-
-  <p>We did not implement the long-awaited <a href="#PER_TYPE">new
-  pertype aspect specifier</a> in this release, but it may well
-  be in a future release.</p>
-  
-
-<!-- ============================== -->
-<hr>
-<h2><a name="compiler">The Compiler</a></h2>
-
-  <p> The compiler for AspectJ 1.1 is different than the compiler for
-  AspectJ 1.0.  While this document describes the differences in the
-  compiler, it's worthwhile noting that much effort has been made to
-  make sure that the interface to ajc 1.1 is, as much as possible, the
-  same as the interface to ajc 1.0.  There are two important changes
-  under the hood, however. </p>
-
-  <p> First, the 1.1 compiler is implemented on top of the
-  open-source Eclipse compiler.  This has two benefits: It allows us
-  to concentrate on the AspectJ extensions to Java and let the Eclipse
-  team worry about making sure the Java edge cases work, and it allows
-  us to piggyback on Eclipse's already mature incremental compilation
-  facilities.  </p>
-
-  <p> Second, ajc now cleanly delineates compilation of source code
-  from assembly (or "weaving") of bytecode.  The compiler still
-  accepts source code, but internally it transforms it into bytecode
-  format before weaving. </p>
-
-  <p> This new architecture, and other changes to the compiler, allows
-  us to implement some features that were defined in the AspectJ 1.0
-  language but not implementable in the 1.1 compiler.  It also makes
-  some new features available: </p>
-
-  <ul>
-    <li><a href="#SOURCEROOT">The -sourceroots option</a> 
-    takes one or more directories, and indicates that all the source
-    files in those directories should be passed to the compiler. </li>
-
-    <li><a href="#BYTECODE_WEAVING">The -injars option</a>
-    takes one or more jar files, and indicates that all the classfiles
-    in the jar files should be woven into.  </li>
-
-    <li><a href="#BINARY_ASPECTS">The -aspectpath option</a>
-     takes one or more jar files, and weaves any aspects in .class form
-     into the sources.</li>
-
-    <li><a href="#OUTJAR">The -outjar option</a> indicates
-    that the result classfiles of compiling and weaving should be placed
-    in the specified jar file. </li>
-
-    <li><a href="#XLINT">The -Xlint option</a> allows control over
-    warnings.</li>
-
-    <li><a href="#OTHER_X_OPTIONS">Various -X options</a> changed.</li>
-
-    <li><a href="#INCREMENTAL">The -incremental option</a> tells the
-    AspectJ 1.1 compiler to recompile only as necessary. </li>
-  </ul>
-
-  <p> Some other features we wanted to support for 1.1, but did not make
-  it into this release: </p>
-
-  <ul>
-    <li><a href="#ERROR_MESSAGES">Error messages will sometimes be scary</a></li>
-    <li><a href="#MESSAGE_CONTEXT">Source code context is not shown
-                for errors and warnings detected during bytecode weaving</a></li>
-  </ul>
-  
-  <p> But some features of the 1.0 compiler are not supported in the
-  1.1 compiler: </p>
-
-  <ul>
-    <li><a href="#NO_SOURCE">The source-related options</a> -preprocess,
-    -usejavac, -nocomment and -workingdir</li>
-
-    <li><a href="#NO_STRICT_LENIENT">The -strict and -lenient options</a>
-    </li>
-
-    <li><a href="#NO_PORTING">The -porting option</a></li>
-
-    <li><a href="#13_REQUIRED">J2SE 1.2 is not supported;
-    J2SE 1.3 or later is required.</a></li>
-  </ul>
-  
-  <p> A short description of the options ajc accepts is available with
-  "<code>ajc -help</code>". 
-  Longer descriptions are available in the 
-  <a href="devguide/ajc-ref.html">Development Environment Guide
-  section on ajc</a>. </p>
-  <p> </p>
-
-
-  <p> Some changes to the implementation are almost entirely
-  internal:
-  </p>
-  
-  <ul>
-    <li>The behavior of the compiler in
-    <a href="#TARGET_TYPES_MADE_PUBLIC">lifting the visibility</a> of
-    the target types of some declares and pointcuts to public has been
-    clarified. </li>
-  </ul>
-
-  <p> Also, it is worth noting that because AspectJ now works on bytecode,
-  it is somewhat sensitive to how different compilers generate
-  bytecode, especially when compiling with and without <a
-  href="#ONE_FOUR_METHOD_SIGNATURES">the -1.4 flag</a>. </p>
-
-  
-
-<!-- ============================== -->
-<hr>
-<h2><a name="tools">Support Tools</a></h2>
-
-  <p>This release includes an Ant task for old-style 1.0 build
-  scripts, a new task for all the new compiler options, and a
-  CompilerAdapter to support running <code>ajc</code> with the Javac
-  task by setting the <code>build.compiler</code> property.  
-  The new task can automatically copy input resources to output
-  and work in incremental mode using a "tag" file.
-  </p>
-
-  <p>This release does not include <code>ajdoc</code>, the
-  documentation tool for AspectJ sources.
-  Ajdoc is deeply dependent on the
-  abstract syntax tree classes from the old compiler, so it needs a
-  bottom-up rewrite. We think it best to use this opportunity to
-  implement more general API's for publishing and rendering static
-  structure. Because those API's are last to settle in the new
-  architecture, and because the compiler itself is a higher priority,
-  we are delaying work on ajdoc until after the 1.1 release.</p>
-
-  <p>AspectJ 1.1 will not include <tt>ajdb</tt>, the AspectJ
-  stand-alone debugger.  It is no longer necessary for two reasons.
-  First, the -XnoInline flag will tell the compiler to generate
-  code without inlining that should work correctly with any Java
-  debugger.  For code generated with inlining enabled, more
-  third-party debuggers are starting to work according to JSR 45,
-  "Debugging support for other languages," which is supported by
-  AspectJ 1.0.  We aim to support JSR-45 in AspectJ 1.1, but 
-  support will not be in the initial release.  Consider using 
-  the -XnoInline flag until support is available.</p>
-
-<!-- ============================== -->
-<hr>
-<h2><a name="runtime">The Runtime Library</a></h2>
-
-  <p>This release has minor additions to the runtime library classes.
-     As with any release, you should compile and run with the runtime
-     library that came with your compiler, and you may run with
-     a later version of the library without recompiling your code.</p>
-
-  <p> In one instance, however, runtime classes behave differently this release.
-  Because the AspectJ 1.1 compiler does its weaving through
-  bytecode, column numbers of source locations are not available.
-  Therefore, <code>thisJoinPoint.getSourceLocation().getColumn()</code>
-  is deprecated and will always return 0. </p>
-
-<!-- ============================== -->
-<hr>
-<h2><a name="devenv">The AJDE Tools</a></h2>
-
-  <p> The AspectJ Browser supports incremental compilation and running
-  programs.  AJDE for JBuilder, AJDE for NetBeans, and AJDE for Emacs 
-are now independent SourceForge projects (to keep their licenses).
-  They use the batch-build mode of the new compiler.  
-  </p>
-
-<!-- ============================== -->
-<hr>
-<h2><a name="sources">The Sources and the Licenses</a></h2>
-
-  <p>The AspectJ tools sources are available under the
-  <a href="https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt">Eclipse Public License v 2.0</a>
-    in the Git repository at
-    <a href="http://eclipse.org/aspectj">http://eclipse.org/aspectj</a>.
-  For more information, see the FAQ entry on
-    <a href="faq.html#q:buildingsource">building sources</a>.
-  </p>
-
-
-<!-- ============================== -->
-<hr>
-<h2><a name="distribution">The AspectJ distribution</a></h2>
-
-  <p> AspectJ 1.0 had many distributions - for the tools,
-      the documentation, each IDE support package,
-      their respective sources, and the Ant tasks -
-      because they came under different licenses.
-      All of AspectJ 1.1 is licensed under the CPL 1.0,
-	  so the tools, Ant tasks, and documentation are all
-      in one distribution available from
-      <a href="http://eclipse.org/aspectj">
-               http://eclipse.org/aspectj</a>.
-To retain their MPL 1.1 license,
-Ajde for
-<a href="http://aspectj4emacs.sourceforge.net/">Emacs</a>,
-<a href="http://aspectj4netbean.sourceforge.net/">NetBeans</a> and
-<a href="http://aspectj4jbuildr.sourceforge.net/">JBuilder</a> 
-are now independent SourceForge projects. </p>
-
-  </p>
-
-
-<!-- ============================== -->
-<hr>
-<hr>
-<h2><a name="details">Details</a> of some language and compiler changes</h2>
-
-  <h3><a name="ASPECT_INSTANTIATION_AND_ADVICE">Aspect Instantiation
-  and Advice</a></h3>
-
-    <p> In AspectJ 1.0.6, we made an effort to hide some complications
-    with Aspect instantiation from the user.  In particular, the
-    following code compiled and ran:
-    </p>
-
-      <PRE>
-      public class Client
-      {
-          public static void main(String[] args) {
-              Client c = new Client();
-          }
-      }
-
-      aspect Watchcall {
-          pointcut myConstructor(): execution(new(..));
-
-          before(): myConstructor() {
-              System.err.println("Entering Constructor");
-          }
-      }
-      </PRE>
-
-    <p> But there's a conceptual problem with this code: The before
-    advice should run before the execution of all constructors in the
-    system.  It must run in the context of an instance of the
-    Watchcall aspect.  The only way to get such an instance is to have
-    Watchcall's default constructor execute.  But before that
-    executes, we need to run the before advice...</p>
-
-    <p> AspectJ 1.0.6 hid this circularity through the ad-hoc
-    mechanism of preventing an aspect's advice from matching join
-    points that were within the aspect's definition, and occurred
-    before the aspect was initialized.  But even in AspectJ 1.0.6,
-    this circularity could be exposed:
-    </p>
-
-      <PRE>
-      public class Client
-      {
-          public static int foo() { return 3; }
-          public static void main(String[] args) {
-              Client c = new Client();
-          }
-      }
-
-      aspect Watchcall {
-          int i = Client.foo();
-          pointcut myConstructor():
-              execution(new(..)) || execution(int foo());
-
-          before(): myConstructor() {
-              System.err.println("Entering Constructor");
-          }
-      }
-      </PRE>
-
-    <p>This program would throw a NullPointerException when run, since
-    Client.foo() was called before the Watchcall instance could be
-    instantiated.  </p>
-
-    <p> In AspectJ 1.1, we have decided that half-hiding the problem
-    just leads to trouble, and so we are no longer silently hiding
-    some join points before aspect initialization.  However, we have
-    provided a better exception than a NullPointerException for this
-    case.  In AspectJ 1.1, both of the above programs will throw
-    org.aspectj.lang.NoAspectBoundException. 
-    </p>
-
-  <h3><a name="THROWS_PATTERN">Matching based on throws</a></h3>
-
-    <p> Type patterns may now be used to pick out methods and
-    constructors based on their throws clauses.  This allows the
-    following two kinds of extremely wildcarded pointcuts: </p>
-
-    <pre>    pointcut throwsMathlike():
-      // each call to a method with a throws clause containing at least
-      // one exception with "Math" in its name.
-      call(* *(..) throws *..*Math*);
-
-    pointcut doesNotThrowMathlike():
-      // each call to a method with a throws clause containing no
-      // exceptions with "Math" in its name.
-      call(* *(..) throws !*..*Math*);
-    </pre>
-
-    <p> The longwinded rules are that a method or constructor pattern
-    can have a "throws clause pattern".  Throws clause patterns look
-    like: </p>
-
-    <pre>    ThrowsClausePattern:
-        ThrowsClausePatternItem ("," ThrowsClausePatternItem)*
-
-    ThrowsClausePatternItem:
-        ["!"] TypeNamePattern
-    </pre>
-
-    <p> A ThrowsClausePattern matches the ThrowsClause of any code
-    member signature. To match, each ThrowsClausePatternItem must
-    match the throws clause of the member in question. If any item
-    doesn't match, then the whole pattern doesn't match. This rule is
-    unchanged from AspectJ 1.0.  </p>
-
-    <p> If a ThrowsClausePatternItem begins with "!", then it matches
-    a particular throws clause if and only if <em>none</em> of the
-    types named in the throws clause is matched by the
-    TypeNamePattern. </p>
-
-    <p> If a ThrowsClausePatternItem does not begin with "!", then it
-    matches a throws clause if and only if <em>any</em> of the types
-    named in the throws clause is matched by the TypeNamePattern.</p>
-
-    <p> These rules are completely backwards compatible with
-    AspectJ 1.0. The rule for "!" matching has one potentially
-    surprising property, in that the two PCD's shown below will have
-    different matching rules. </p>
-
-    <pre>    [1] call(* *(..) throws !IOException)
-    [2] call(* *(..) throws (!IOException))
-
-    void m() throws RuntimeException, IOException {}
-    </pre>
-
-    <p> [1] will NOT match the method m(), because method m's throws
-    clause declares that it throws IOException. [2] WILL match the
-    method m(), because method m's throws clause declares the it
-    throws some exception which does not match IOException,
-    i.e. RuntimeException. </p>
-
-  <h3><a name="NEW_PCDS">New kinded pointcut designators</a></h3>
-
-    <p> AspectJ 1.0 does not provide kinded pointcut designators for
-    two (rarely used) join points: preinitialization (the code that
-    runs before a super constructor call is made) and advice
-    execution.  AspectJ 1.1 does not change the meaning of the join
-    points, but provides two new pointcut designators to pick out
-    these join points, thus making join points and pointcut
-    designators more parallel.  </p>
-
-    <p> <code>adviceexectuion()</code> will pick out advice execution
-    join points.  You will usually want to use <code>adviceexecution()
-    && within(Aspect)</code> to restrict it to only those pieces of
-    advice defined in a particular aspect. <br>
-    <code>preinitialization(<var>ConstructorPattern</var>)</code> will
-    pick out pre-initialization join points where the initialization
-    process is entered through
-    <code><var>ConstructorPattern</var></code>. </p>
-
-  <h3><a name="PER_TYPE">New pertype aspect specifier</a> (not in 1.1)</h3>
-
-    <p>We strongly considered adding a pertype aspect kind to 1.1.
-    This is somewhat motivated by the new
-    <a href="#SINGLE_INTERCLASS_TARGET">restrictions on inter-type
-    declarations<a>.  This is also motivated by many previous request
-    to support a common logging idiom.  Here's what pertype would look
-    like:</p>
-
-    <pre>    /** One instance of this aspect will be created for each class,
-     * interface or aspect in the com.bigboxco packages.
-     */
-    aspect Logger pertype(com.bigboxco..*) {
-        /* This field holds a logger for the class. */
-        Log log;
-
-        /* This advice will run for every public execution defined by
-         * a type for which a Logger aspect has been created, i.e.
-         * any type in com.bigboxco..*
-         */
-        before(): execution(public * *(..)) {
-            log.enterMethod(thisJoinPoint.getSignature().getName());
-        }
-
-        /* We can use a special constructor to initialize the log field */
-        public Logger(Class myType) {
-            this.log = new Log(myType);
-        }
-    }
-
-        /** External code could use aspectOf to get at the log, i.e. */
-        Log l = Logger.aspectOf(com.bigboxco.Foo.class).log;
-    </pre>
-
-    <p>The one open question that we see is how this should interact
-    with inner types.  If a pertype aspect is created for an outer
-    type should advice in that aspect run for join points in inner
-    types?  That is the behavior of the most common uses of this
-    idiom.  </p>
-
-    <p> In any case, this feature will not be in AspectJ 1.1.
-    </p>
-
-  <h3><a name="SINGLE_INTERCLASS_TARGET">One target for intertype
-  declarations</a></h3>
-
-    <p> Intertype declarations (once called "introductions") in
-    AspectJ 1.1 can only have one target type.  So the following code
-    intended to declare that there is a void doStuff() method on all
-    subtypes of Target is not legal AspectJ 1.1 code.
-    </p>
-
-    <pre>    aspect A {
-        public void Target+.doStuff() { ... }
-    }
-    </pre>
-
-    <p> The functionality of "multi-intertype declarations" can be
-    recovered by using a helper interface.
-    </p>
-
-    <pre>    aspect A {
-        private interface MyTarget {}
-        declare parents:  Target+ implements MyTarget;
-        public void MyTarget.doStuff() { ... }
-    }
-    </pre>
-
-    <p> We believe this is better style in AspectJ 1.0 as well, as it
-    makes clear the static type of "this" inside the method body.
-    </p>
-
-    <p> The one piece of functionality that can not be easily
-    recovered is the ability to add static fields to many classes.  We
-    believe that the <a href="#PER_TYPE">pertype proposal</a> provides
-    this functionality in a much more usable form.</p>
-
-  <h3><a name="UNAVAILABLE_JOIN_POINTS">No initializer execution join
-    points</a></h3>
-
-    <p> AspectJ 1.1 does not consider initializer execution a
-    principled join point.  The collection of initializer code (the
-    code that sets fields with initializers and the code in non-static
-    initializer blocks) is something that makes sense only in Java
-    source code, not in Java bytecode.  </p>
-
-  <h3><a name="AFTER_HANDLER"></a>No after or around advice on handler 
-	join points</h3>
-
-    <p> The end of an exception handler is underdetermined in bytecode,
-  	so ajc will not implement after or around advice on handler join 
-    points, instead signaling a compile-time error.</p>
-
-  <h3><a name="CONSTRUCTOR_EXECUTION_IS_BIGGER">Initializers run
-    inside constructor execution join points</a></h3>
-
-    <p> The code generated by the initializers in Java source code now
-    runs inside of constructor execution join points.  This changes
-    how before advice runs on constructor execution join points.
-    Consider: </p>
-
-    <pre>    class C {
-        C() { }
-        String id = "identifier"; // this assignment
-                                  // has to happen sometime
-    }
-    aspect A {
-        before(C c) this(c) && execution(C.new()) {
-            System.out.println(c.id.length());
-        }
-    }
-    </pre>
-
-    <p> In AspectJ 1.0, this will print "10", since id is assigned its
-    initial value prior to the before advice's execution.  However, in
-    AspectJ 1.1, this will throw a NullPointerExcception, since "id"
-    does not have a value prior to the before advice's execution.
-    </p>
-
-    <p> Note that the various flavors of after returning advice are
-    unchanged in this respect in AspectJ 1.1.  Also note that this
-    only matters for the execution of constructors that call a
-    super-constructor.  Execution of constructors that call a
-    this-constructor are the same in AspectJ 1.1 as in AspectJ 1.0.
-    </p>
-
-    <p> We believe this difference should be minimal to real programs,
-    since programmers using before advice on constructor execution
-    must always assume incomplete object initialization, since the
-    constructor has not yet run.  </p>
-
-  <h3><a name="INTER_TYPE_FIELD_INITIALIZERS">Inter-type field initializers</a></h3>
-
-    <p> The initializer, if any, of an inter-type field definition runs
-    before the class-local initializers of its target class.  </p>
-
-    <p> In AspectJ 1.0.6, such an initializer would run after the
-    initializers of a class but before the execution of any of its
-    constructor bodies.  As already discussed in the sections about
-    <a href="#UNAVAILABLE_JOIN_POINTS">initializer execution join
-    points</a> and <a href="#CONSTRUCTOR_EXECUTION_IS_BIGGER">constructor
-    execution</a>, the point in code between the initializers of a class
-    and its constructor body is not principled in bytecode.  So we had a
-    choice of running the initializer of an inter-type field definition at
-    the beginning of initialization (i.e., before initializers from
-    the target class) or at the end (i.e., just before its called
-    constructor exits).  We chose the former, having this pattern in mind:
-    </p>
-
-    <PRE>
-    int C.methodCount = 0;
-    before(C c): this(c) &amp;&amp; execution(* *(..)) { c.methodCount++; }
-    </PRE>
-
-    <p> We felt there would be too much surprise if a constructor called a
-    method (thus incrementing the method count) and then the field was
-    reset to zero after the constructor was done. 
-    </p>
-
-  <h3><a name="WITHIN_MEMBER_TYPES">Small limitations of the within
-    pointcut</a></h3>
-
-   <p>Because of the guarantees made (and not made) by the Java
-    classfile format, there are cases where AspectJ 1.1 cannot
-    guarantee that the within pointcut designator will pick out all
-    code that was originally within the source code of a certain
-    type.
-    </p>
-
-    <p> The non-guarantee applies to code inside of anonymous and
-    local types inside member types.  While the within pointcut
-    designator behaves exactly as it did in AspectJ 1.0 when given a
-    package-level type (like C, below), if given a member-type (like
-    C.InsideC, below), it is not guaranteed to capture code in
-    contained local and anonymous types.  For example: </p>
-
-    <pre>    class C {
-        Thread t;
-        class InsideC {
-            void setupOuterThread() {
-                t = new Thread(
-                        new Runnable() {
-                            public void run() {
-                                // join points with code here
-                                // might not be captured by
-                                // within(C.InsideC), but are
-                                // captured by within(C)
-                                System.out.println("hi");
-                            }
-                        });
-            }
-        }
-    }
-    </pre>
-
-    <p> We believe the non-guarantee is small, and we haven't verified
-    that it is a problem in practice.  </p>
-
-  <h3><a name="WITHIN_CODE">Small limitations of the withincode
-    pointcut</a></h3>
-
-    <p>The withincode pointcut has similar issues to those described
-    above for within.  
-    </p>
-
-  <h3><a name="INSTANCEOF_ON_WILD">Can't do instanceof matching on
-        type patterns with wildcard</a></h3>
-
-    <p>The pointcut designators this, target and args specify a
-    dynamic test on their argument.  These tests can not be performed
-    on type patterns with wildcards in them.  The following code that
-    compiled under 1.0 will be an error in AspectJ-1.1:</p>
-
-    <pre>    pointcut oneOfMine(): this(com.bigboxco..*);
-    </pre>
-
-    <p>The only way to implement this kind of matching in a modular
-    way would be to use the reflection API at runtime on the Class of
-    the object.  This would have a very high performance cost and
-    possible security issues.  There are two good work-arounds.  If
-    you control the source or bytecode to the type you want to match
-    then you can use declare parents, i.e.:</p>
-
-    <pre>    private interface OneOfMine {}
-    declare parents: com.bigboxco..* implements OneOfMine;
-    pointcut oneOfMine(): this(OneOfMine);
-    </pre>
-
-    <p>If you want the more dynamic matching and are willing to pay
-    for the performance, then you should use the Java reflection API
-    combined with if.  That would look something like:</p>
-
-    <pre>    pointcut oneOfMine(): this(Object) &&
-        if(classMatches("com.bigboxco..*",
-                        thisJoinPoint.getTarget().getClass()));
-
-    static boolean classMatches(String pattern, Class _class) {
-        if (patternMatches(pattern, _class.getName())) return true;
-        ...
-    }
-    </pre>
-
-    <p>Note: wildcard type matching still works in all other PCD's that
-    match based on static types.  So, you can use
-    'within(com.bigboxco..*+)' to match any code lexically within one
-    of your classes or a subtype thereof.  This is often a good
-    choice.</p>
-    </p>
-
-
-  <h3><a name="NO_SOURCE_COLUMN">SourceLocation.getColumn()</a></h3>
-
-    <p>The Java .class file format contains information about the
-    source file and line numbers of its contents; however, it has no
-    information about source columns.  As a result, we can not
-    effectively support the access of column information in the
-    reflection API.  So, any calls to
-    thisJoinPoint.getSourceLocation().getColumn() will be marked as
-    deprecated by the compiler, and will always return 0.</p>
-
-  <h3><a name="ASPECT_PRECEDENCE">Aspect precedence</a></h3>
-
-    <p> AspectJ 1.1 has a new declare form:
-    </p>
-
-    <pre>    declare precedence ":"  TypePatternList ";"
-    </pre>
-
-    <p> This is used to declare advice ordering constraints on join
-    points.  For example, the constraints that (1) aspects that have
-    Security as part of their name should dominate all other aspects, and
-    (2) the Logging aspect (and any aspect that extends it) should
-    dominate all non-security aspects, can be expressed by: </p>
-
-    <pre>    declare precedence: *..*Security*, Logging+, *;
-    </pre>
-
-    <p> In the TypePatternList, the wildcard * means "any type not matched
-    by another type in the declare precedence".  </p>
-
-    <h4>Various cycles</h4>
-
-      <p> It is an error for any aspect to be matched by more than one
-      TypePattern in a single declare precedence, so: </p>
-
-      <pre>      declare precedence:  A, B, A ;  // error
-      </pre>
-
-      <p> However, multiple declare precedence forms may legally have this
-      kind of circularity.  For example, each of these declare precedence is
-      perfectly legal:
-      </p>
-
-      <pre>      declare precedence: B, A;
-      declare precedence: A, B;
-      </pre>
-
-      <p> And a system in which both constraints are active may also be
-      legal, so long as advice from A and B don't share a join point.  So
-      this is an idiom that can be used to enforce that A and B are strongly
-      independent.  </p>
-
-    <h4>Applies to concrete aspects</h4>
-
-      <p> Consider the following library aspects:
-      </p>
-
-      <pre>      abstract aspect Logging {
-          abstract pointcut logged();
-
-          before(): logged() {
-              System.err.println("thisJoinPoint: " + thisJoinPoint);
-          }
-      }
-
-      aspect MyProfiling {
-          abstract pointcut profiled();
-
-          Object around(): profiled() {
-              long beforeTime = System.currentTimeMillis();
-              try {
-                  return proceed();
-              } finally {
-                  long afterTime = System.currentTimeMillis();
-                  addToProfile(thisJoinPointStaticPart,
-                               afterTime - beforeTime);
-              }
-          }
-          abstract void addToProfile(
-              org.aspectj.JoinPoint.StaticPart jp,
-              long elapsed);
-      }
-      </pre>
-
-      <p> In order to use either aspect, they must be extended with
-      concrete aspects, say, MyLogging and MyProfiling.  In AspectJ
-      1.0, it was not possible to express that Logging's advice (when
-      concerned with the concrete aspect MyLogging) dominated
-      Profiling's advice (when concerned with the concrete aspect
-      MyProfiling) without adding a dominates clause to Logging
-      itself.  In AspectJ 1.1, we can express that constraint with a
-      simple: </p>
-
-      <pre>      declare precedence: MyLogging, MyProfiling;
-      </pre>
-
-    <h4>Changing order of advice for sub-aspects</h4>
-
-      <p> By default, advice in a sub-aspect has more precedence than
-      advice in a super-aspect.  One use of the AspectJ 1.0 dominates
-      form was to change this precedence:
-      </p>
-
-      <pre>      abstract aspect SuperA dominates SubA {
-          pointcut foo(): ... ;
-
-          before(): foo() {
-              // in AspectJ 1.0, runs before the advice in SubA
-              // because of the dominates clause
-          }
-      }
-
-      aspect SubA extends SuperA {
-          before(): foo() {
-              // in AspectJ 1.0, runs after the advice in SuperA
-              // because of the dominates clause
-          }
-      }
-      </pre>
-
-      <p> This no longer works in AspectJ 1.1, since declare precedence only
-      matters for concrete aspects.  Thus, if you want to regain this kind
-      of precedence change, you will need to refactor your aspects.
-      </p>
-
-  <h3><a name="SOURCEROOT">The -sourceroots option</a></h3>
-
-    <p> The AspectJ 1.1 compiler now accepts a -sourceroots option used to
-    pass all .java files in particular directories to the compiler.  It
-    takes either a single directory name, or a list of directory names
-    separated with the CLASSPATH separator character (":" for various
-    Unices, ";" for various Windows). </p>
-
-    <p> So, if you have your project separated into a gui module and a
-    base module, each of which is stored in a directory tree, you might
-    use one of
-    </p>
-
-    <pre>    ajc -sourceroots /myProject/gui:/myProject/base
-    ajc -sourceroots d:\myProject\gui;d:\myProject\base
-    </pre>
-
-    <p> This option may be used in conjunction with lst files, listing
-    .java files on the command line, and the -injars option.
-    </p>
-
-  <h3><a name="BYTECODE_WEAVING">The -injars option</a></h3>
-
-    <p> The AspectJ 1.1 compiler now accepts an -injars option used to
-    pass all .class files in a particular jar file to the compiler.  It
-    takes either a single directory name, or a list of directory names
-    separated with the CLASSPATH separator character (":" for various
-    Unices, ";" for various Windows). </p>
-
-    <p> So, if MyTracing.java defines a trace aspect that you want to
-    apply to all the classes in myBase.jar and myGui.jar, you would use
-    one of: </p>
-
-    <pre>    ajc -injars /bin/myBase.jar:/bin/myGui.jar MyTracing.java
-    ajc -injars d:\bin\myBase.jar;d:\bin\myGui.jar MyTracing.java
-    </pre>
-
-    <p> The class files in the input jars must not have had advice woven
-    into them, since AspectJ enforces the requirement that advice is woven
-    into a particular classfile only once.  So if the classfiles in the
-    jar file are to be created with the ajc compiler (as opposed to a pure
-    Java compiler), they should not be compiled with any non-abstract
-    aspects.  </p>
-
-    <p> This option may be used in conjunction with lst files, listing
-    .java files on the command line, and the -sourceroots option.
-    </p>
-
-  <h3><a name="OUTJAR">The -outjar option</a></h3>
-
-    <p> The -outjar option takes the name of a jar file into which the
-    results of the compilation should be put.  For example:
-
-    <pre>    ajc -injars myBase.jar MyTracing.java -outjar myTracedBase.jar
-    </pre>
-
-    <p> No meta information is placed in the output jar file. </p>
-
-  <h3><a name="INCREMENTAL">Incremental compilation</a></h3>
-
-    <p> The AspectJ 1.1 compiler now supports incremental compilation.
-    When ajc is called with the -incremental option, it must also be
-    passed a -sourceroots option specifying a directory to incrementally
-    compile.  Once the initial compile is done, ajc waits for console
-    input.  Every time it reads a new line (i.e., every time the user
-    hits return) ajc recompiles those input files that need recompiling.
-    </p>
-
-    <h4>Limitations</h4>
-
-    <p> This new functionality is still only lightly tested. </p>
-
-  <h3><a name="XNOWEAVE">-XnoWeave, a compiler option to suppress
-  weaving</a></h3>
-
-    <p> The -XnoWeave option suppresses weaving, and generates
-    classfiles and that can be passed to ajc again (through the
-    -injars option) to generate final, woven classfiles. </p>
-
-    <p> This option was originally envisioned to be the primary way to
-    generate binary aspects that could be linked with other code, and
-    so it was previously (in AspectJ 1.1beta1) named
-    <code>-noweave</code>.  We feel that using the
-    <code><a href="#BINARY_ASPECTS">-aspectpath</a></code> option is a
-    much better option.  There may still be use cases for unwoven
-    classfiles, but we've moved the flag to experimental status.
-    </p>
-
-  <h3><a name="BINARY_ASPECTS">-aspectpath, working with aspects in .class/.jar
-  form</a> </h3>
-
-    <p> When aspects are compiled into classfiles, they include all
-    information necessary for the ajc compiler to weave their advice
-    and deal with their inter-type declarations.  In order for these
-    aspects to have an effect on a compilation process, they must be
-    passed to the compiler on the -aspectpath.  Every .jar file on
-    this path will be searched for aspects and any aspects that are
-    found will be enabled during the compilation.  The binary forms of
-    this aspects will be untouched. </p>
-
-  <h3><a name="NO_CALLEE_SIDE_CALL">Callee-side call join
-  points</a></h3>
-
-    <p> The 1.0 implementation of AspectJ, when given:
-    </p>
-
-    <pre>    class MyRunnable implements Runnable {
-        public void run() { ... }
-    }
-
-    aspect A {
-        call(): (void run()) && target(MyRunnable) {
-            // do something here
-        }
-    }
-    </pre>
-
-    <p> would cause A's advice to execute even when, say, java.lang.Thread
-    called run() on a MyRunnable instance.
-    </p>
-
-    <p> With the new compiler, two things have happened in regard to
-    callee-side calls:
-    </p>
-
-    <ol>
-      <li>because the programmer has access to more code (i.e.,
-       bytecode, not just source code), callee-side calls are much
-       less important to have.</li>
-
-       <li>because compilation is more modular, allowing and
-       encouraging separate compilation, callee-side calls are much
-       more difficult to implement</li>
-    </ol>
-
-    <p> With these two points in mind, advice in an aspect will not be
-    applied to call join points whose call site is completely
-    unavailable to the aspect.  </p>
-
-    <ol>
-      <li>One reason (though not the only reason) we worked so hard in
-       the <em>implementation</em> of 1.0.6 to expose call join
-       points, even if we only had access to the callee's code, was
-       that otherwise users couldn't get access to call join points
-       where the call was made from bytecode.  This is no longer the
-       case.  In short, the implementation controls much more code (or
-       has the capability to) than ever before.</li>
-
-      <li>The implementation model for the AspectJ 1.1 compiler is to
-       separate the compilation of aspects/advice from their
-       weaving/linking.  A property of the model is that the
-       compilation requires no access to "target" code, only the
-       weaving/linking does, and weaving/linking is inherently
-       per-class local: No action at weaving/linking time depends on
-       the coordinated mangling of multiple classfiles.  Rather, all
-       weaving is done on a per classfile basis.  This is an essential
-       property for the current separate compilation model. <br>
-
-       However, allowing implementation of call advice on either
-       side requires simultaneous knowledge of both sides.  If we first
-       have access to a call, we can't decide to simply put the advice
-       on the call site, since later we may decide to implement on the
-       callee.</li>
-    </ol>
-
-    <p>This implementation decision is completely in the letter and
-    the spirit of the AspectJ language.  From the semantics guide
-    describing code the implementation controls:</p>
-
-    <blockquote>
-      But AspectJ implementations are permitted to deviate from this
-      in a well-defined way -- they are permitted to advise only
-      accesses in <em>code the implementation
-      controls</em>.  Each implementation is free within certain
-      bounds to provide its own definition of what it means to control
-      code.
-    </blockquote>
-
-    <p>And about a particular decision about the 1.0.6
-    implementation:</p>
-
-    <blockquote>
-       Different join points have different requirements.  Method call
-       join points can be advised only if ajc controls
-       <em>either</em> the code for the caller or the code
-       for the receiver, and some call pointcut designators may
-       require caller context (what the static type of the receiver
-       is, for example) to pick out join points.
-    </blockquote>
-
-    <p> The 1.1 implementation makes a different design decision:
-    Method call join points can be advised only if ajc (in compiler or
-    linker form) controls the code for the caller. </p>
-    
-    <p>What does 1.1 gain from this?</p>
-
-    <ul>
-      <li>a clear (and implemented) separate compilation model (see
-      point 2, above)</li>
-
-      <li>a less confusing interaction between call join points and
-      the thisJoinPoint reflective object: We still get bug reports
-      about source information sometimes existing and sometimes not
-      existing at call join points.</li>
-    </ul>
-
-    <p> What does 1.1 lose from this?</p>
-
-    <ul>
-      <li>The ability to capture all calls to Runnable.run() from
-      anywhere to code ajc has access too, even from Thread, even if
-      you don't compile java.lang with ajc.</li>
-
-      <li>The ability to, without access to the caller, capture entry to
-      a particular method, but not super calls.</li>
-
-      <li>A code-size-improvement performance optimization.</li>
-    </ul>
-
-    <p> What are the possibilities for the future?</p>
-
-    <ul>
-      <li>AspectJ 1.1.1 could expand its capture of call join points,
-      possibly at the expense of separate compilation clarity,
-      possibly not. </li>
-
-      <li>AspectJ 1.1.1 could re-introduce reception join points from
-      AspectJ 0.7 (what callee-side call join points actually are):
-      though they would never ever be taught in a tutorial or
-      entry-level description of the model, they may have specialized
-      uses.</li>
-    </ul>
-
-    <p> How will this affect developers?</p>
-    <ul>
-		<li>When using the call PCD but only supplying the callee
-            code, supply the calling code or use the execution PCD instead.
-		</li>
-    </ul>
-
-  <h3><a name="OTHER_X_OPTIONS">Various -X options</a></h3>
-
-    <p> The AspectJ 1.0 compiler supported a number of options that
-    started with X, for "experimental".  Some of them will not be
-    supported in 1.1, either because the "experiment" succeeded (in
-    which case it's part of the normal functionality) or failed.
-    Others will be supported as is (or nearly so) in 1.1:
-    </p>
-
-    <ul>
-      <li>-XOcodeSize: This is no longer necessary because inlining
-      of around advice is on by default.  We support its inverse,
-      <a href="#XNOINLINE"><code>-XnoInline</code></a>.
-      </li>
-
-      <li><a href="#XNOWEAVE">-XnoWeave, a compiler option to suppress
-           weaving</a></li>
-
-      <li>-XtargetNearSource: Not supported in this release. </li>
-
-      <li>-XserializableAspects: Supported. </li>
-
-      <li>-XaddSafePrefix: This option will not be supported in 1.1 at
-      all because we're now always using (what we believe to be) safe
-      prefixes. </li>
-
-      <li>-Xlint: Still supported, with <a href="#XLINT">various
-      options</a>. </li>
-    </ul>
-
-  <h3><a name="ERROR_MESSAGES">Some confusing error messages</a></h3>
-
-    <p>Building on the eclipse compiler has given us access to a very
-    sophisticated problem reporting system as well as highly optimized
-    error messages for pure Java code.  Often this leads to noticeably
-    better error messages than from ajc-1.0.6.  However, when we don't
-    handle errors correctly this can sometimes lead to cascading error
-    messages where a single small syntax error will produce dozens of
-    other messages.  Please report any very confusing error messages as
-    bugs.</p>
-
-
-  <h3><a name="MESSAGE_CONTEXT">Source code context is not shown
-                for errors and warnings detected during bytecode weaving</a></h3>
-
-	<p>For compiler errors and warnings detected during bytecode weaving,
-	source code context will not be displayed.  In particular, for declare
-	error and declare warning statements, the compiler now only emits the 
-	file and line.  We are investigating ways to overcome this in cases
-	where the source code is available; in cases where source code is 
-	not available, we might specify the signature of the offending code.
-	For more information, see bug 31724.</p>
-
-
-  <h3><a name="XLINT">The -Xlint option</a></h3>
-
-    <p><code>-Xlint:ignore,error,warning</code> will set the level for
-    all Xlint warnings.  <code>-Xlint</code>, alone, is an
-    abbreviation for <code>-Xlint:warning</code>.</p>
-
-    <p>The <code>-Xlintfile:lint.properties</code> allows fine-grained
-    control.  In tools.jar, see
-    <code>org/aspectj/weaver/XlintDefault.properties</code> for the
-    default behavior and a template to copy. </p>
-
-    <p> More <code>-Xlint</code> warnings are supported now, and
-    we may add disabled warnings in subsequent bug-fix releases of 1.1.    
-    Because the configurability allows users to turn off
-    warnings, we will be able to warn about more potentially
-    dangerous situations, such as the potentially unsafe casts used by
-    very polymorphic uses of proceed in around advice.  </p>
-
-  <h3><a name="NO_SOURCE">Source-specific options</a></h3>
-
-    <p> Because AspectJ 1.1 does not generate source code after
-    weaving, the source-code-specific options -preprocess, -usejavac,
-    -nocomment and -workingdir options are meaningless and so not
-    supported.  </p>
-
-  <h3><a name="NO_STRICT_LENIENT">The -strict and -lenient
-  options</a></h3>
-
-    <p> Because AspectJ 1.1 uses the Eclipse compiler, which has its
-    own mechanism for changing strictness, we no longer support the
-    -strict and -lenient options. </p>
-
-  <h3><a name="NO_PORTING">The -porting option</a></h3>
-
-    <p> AspectJ 1.1 does not have a -porting option.</p>
-
-  <h3><a name="13_REQUIRED">J2SE 1.3 required</a></h3>
-
-    <p>Because we build on Eclipse, the compiler will no longer run
-    under J2SE 1.2.  You must run the compiler (and all tools based on
-    the compiler) using J2SE 1.3 or later. The code generated by the
-    compiler can still run on Java 1.1 or later VM's if compiled against
-    the correct runtime libraries.</p>
-
-  <h3><a name="DEFAULT_CONSTRUCTOR_CONFLICT">Default
-  constructors</a></h3>
-
-    <p> AspectJ 1.1 does not allow the inter-type definition of a
-    zero-argument constructor on a class with a visible default
-    constructor.  So this is no longer allowed: </p>
-
-    <PRE>
-    class C {}
-
-    aspect A {
-        C.new() {}  // was allowed in 1.0.6
-                    // is a "multiple definitions" conflict in 1.1
-    }
-    </PRE>
-
-    <p> In the Java Programming Language, a class defined without a
-    constructor actually has a "default" constructor that takes no
-    arguments and just calls <code>super()</code>.  </p>
-
-    <p> This default constructor is a member of the class like any other
-    member, and can be referenced by other classes, and has code generated
-    for it in classfiles.  Therefore, it was an oversight that AspectJ
-    1.0.6 allowed such an "overriding" inter-type constructor definition.
-    </p>
-
-  <h3><a name="SUPER_IFACE_INITS">Initialization join points for
-    super-interfaces</a></h3>
-
-    <p> In AspectJ, interfaces may have non-static members due to
-    inter-type declarations.  Because of this, the semantics of AspectJ
-    defines the order that initializer code for interfaces is run.  
-    </p>
-
-    <p> In the semantics document for AspectJ 1.0.6, the following
-    promises were made about the order of this initialization:
-    </p>
-
-    <ol>
-      <li>a supertype is initialized before a subtype</li>
-      <li>initialized code runs only once</li>
-      <li>initializers for supertypes run in left-to-right order</li>
-    </ol>
-
-    <p> The first two properties are important and are preserved in
-    AspectJ 1.1, but the third property is and was ludicrous, and was
-    never properly implemented (and never could be) in AspectJ 1.0.6.
-    Consider: </p>
-
-    <PRE>
-    interface Top0 {}
-    interface Top1 {}
-    interface I extends Top0, Top1 {} 
-    interface J extends Top1, Top0 {}
-
-    class C implements I, J {}
-    // I says Top0's inits must run before Top1's
-    // J says Top1's inits must run before Top0's
-
-    aspect A {
-        int Top0.i = foo("I'm in Top0");
-        int Top1.i = foo("I'm in Top1");
-        static int foo(String s) {
-            System.out.println(s);
-            return 37;
-        }
-    }
-    </PRE>
-
-    <p> This was simply a bug in the AspectJ specification.  The correct
-    third rule is:
-    </p>
-
-    <blockquote>the initializers for a type's superclass are run before the
-    initializers for its superinterfaces.
-    </blockquote>
-
-
-  <h3><a name="VOID_FIELD_SET">Field Set Join Points</a></h3>
-
-    <p> In AspectJ 1.0.6, the join point for setting a field F had, as a
-    return type, F's type.  This was "java compatible" because
-    field assignment in java, such as "Foo.i = 37", is in fact an
-    expression, and does in fact return a value, the value that the
-    field is assigned to.
-    </p>
-
-    <p> This was never "java programmer compatible", however, largely
-    because programmers have absorbed the good style of rarely using an
-    assignment statement in a value context.  Programmers typically expect
-    "Foo.i = 37" not to return a value, but to simply assign a value. </p>
-
-    <p> Thus, programmers typically wanted to write something like:
-    </p>
-
-    <PRE>
-    void around(): set(int Foo.i) {
-        if (theSetIsAllowed()) {
-            proceed();
-        }
-    }
-    </PRE>
-
-    <p> And were confused by it being a compile-time error.  They weren't
-    confused for long, and soon adapted to writing:
-    </p>    
-
-    <PRE>
-    int around(): set(int Foo.i) {
-        if (theSetIsAllowed()) {
-            return proceed();
-        } else {
-            return Foo.i;
-        }
-    }
-    </PRE>
-
-    <p> But there was definitely a short disconnect.  </p>
-
-    <p> On top of that, we were never shown a convincing use-case for
-    returning an interesting value from a set join point.  When we
-    revisited this issue, in fact, we realized we had a long-standing bug
-    in 1.0.6 dealing with the return value of pre-increment expressions
-    (such as ++Foo.i) that nobody had found because nobody cares about the
-    return value of such join points. 
-    </p>
-
-    <p> So, because it's easier to implement, and because we believe that
-    this is the last possibility to make the semantics more useful, we
-    have made set join points have a void return type in 1.1. </p>
-
-  <h3><a name="XNOINLINE">The -XnoInline Option</a></h3>
-
-    <p> The <code>-XnoInline</code>
-    option to indicate that no inlining of any kind should be done.  This
-    is purely a compiler pragma:  No program semantics (apart from stack
-    traces) will be changed by the presence or absence of this option. 
-    </p>
-
-  <h3><a name="TARGET_TYPES_MADE_PUBLIC">Target types made
-  public</a></h3>
-
-    <p> Even in 1.0.6, the AspectJ compiler has occasionally needed to
-    convert the visibility of a package-level class to a public one.  This
-    was previously done in an ad-hoc basis that took whole-program
-    analysis into account.  With the incremental compilation model of
-    AspectJ 1.1, we can now specify the occasions when the compiler makes
-    these visibility changes.
-    </p>
-
-    <p> In particular, the types used in the <code>this</code>,
-    <code>target</code>, and <code>args</code> pointcuts are made public,
-    as are the super-types from <code>declare parents</code> and the
-    exception type from <code>declare soft</code>. 
-    </p> 
-
-    <p> We believe the visibility changes could be avoided in the future
-    with various implementation tricks if they become a serious
-    concern, but did not encounter them as such a concern when they were
-    done in the 1.0.6 implementation.  </p>
-
-<h3><a name="STRINGBUFFER">String + now advised</a></h3>
-
-<p> In Java, the + operator sometimes results in StringBuffer objects
-being created, appended to, and used to generate a new String.  Thus, 
-</p>
-
-<PRE>
-class Foo {
-    String makeEmphatic(String s) {
-        return s + "!";
-    }
-}
-</PRE>
-
-<p> is approximately the same at runtime as
-</p>
-
-<PRE>
-class Foo {
-    String makeEmphatic(String s) {
-        return new StringBuffer(s).append("!").toString();
-    }
-}
-</PRE>
-
-
-<p> In the design process of AspectJ 1.0.6 we didn't expose those
-StringBuffer methods and constructors as join points (though we did
-discuss it), but in 1.1 we do.  </p>
-
-<p> This change is likely to affect highly wildcarded aspects, and can
-do so in surprising ways.  In particular:
-</p>
-
-<PRE>
-class A {
-    before(int i): call(* *(int)) &amp;&amp; args(i) {
-        System.err.println("entering with " + i);
-    }
-}
-</PRE>
-
-<p> may result in a stack overflow error, since the argument to
-println is really </p>
-
-<PRE>
-new StringBuffer("entering with ").append(i).toString()
-</PRE>
-
-<p> which has a call to StringBuffer.append(int).  In such cases, it's
-worth restricting your pointcut, with something like one of:
-</p>
-
-<PRE>
-call(* *(int)) &amp;&amp; args(i) &amp;&amp; !within(A)
-call(* *(int)) &amp;&amp; args(i) &amp;&amp; !target(StringBuffer)
-</PRE>
-
-<h3><a name="ONE_FOUR_METHOD_SIGNATURES">The -1.4 flag and method signatures</a></h3>
-
-<p> Consider the following aspect
-</p>
-
-<PRE>
-public aspect SwingCalls {
-    
-    pointcut callingAnySwing(): call(* javax.swing..*+.*(..));
-
-    before(): callingAnySwing() {
-        System.out.println("Calling any Swing");
-    }
-}
-</PRE>
-
-<p> And then consider the two statements
-</p>
-
-<PRE>
-  JFrame frame = new JFrame();
-  frame.setTitle("Title");
-</PRE>
-
-<p> According to the Java Language Specification version 2, the call
-to <code>frame.setTitle("Title")</code> should always produce the
-bytecode for a call to <code>javax.swing.JFrame.setTitle</code>.
-However, older compilers (and eclipse when run without the
-<code>-1.4</code> flag) will generate the bytecode for a call to
-<code>java.awt.Frame.setTitle</code> instead since this method is not
-overriden by JFrame.  The AspectJ weaver depends on the correctly
-generated bytecode in order to match patterns like the one you show
-correctly.  </p>
-
-<p> This is a good example of why the pattern <code>call(* *(..)) &&
-target(JFrame)</code> is the recommended style.  In general, OO
-programmers don't want to care about the static type of an object at a
-call site, but only want to know the dynamic instanceof behavior which
-is what the target matching will handle.  </p>
-
-
-<h2><a name="knownLimitations">Known limitations</a></h2>
-
-<p>The AspectJ 1.1.0 release contains a small number of known limitations
-relative to the AspectJ 1.1 language.  
-For the most up-to-date information about known limitations in an
-AspectJ 1.1 release, see the bug database at 
-  <a href="http://bugs.eclipse.org/bugs">http://bugs.eclipse.org/bugs</a>,
-especially the open bugs for the 
-<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
-  compiler</a>, 
-<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=IDE&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
-  IDE support</a>,
-<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Doc&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
-  documentation</a>, and 
-<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Ant&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
-  Ant tasks</a>.
-Developers should know about bugs marked with the "info" keyword
-because those bugs reflect failures to implement the 1.1 language perfectly.
-These might be fixed during the 1.1 release cycle; find them using the query
-  <a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info">
-	       http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info</a>
-
-For ajc's 1.1 implementation limitations, see 
-  <a href="progguide/implementation.html">
-   Programming Guide Appendix: "Implementation Notes"</a>.
-  
-</p>
-</body> </html>
diff --git a/docs/dist/doc/README-12.adoc b/docs/dist/doc/README-12.adoc
index 3aec6a919..95775b45a 100644
--- a/docs/dist/doc/README-12.adoc
+++ b/docs/dist/doc/README-12.adoc
@@ -24,7 +24,8 @@ readers to the bug database for xref:#allchanges[all the changes].
 
 '''''
 
-=== [#compiler]#The Compiler#
+[[compiler]]
+=== The Compiler
 
 Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler...
 
@@ -54,7 +55,8 @@ ajc].
 
 '''''
 
-=== [#tools]#Support Tools#
+[[tools]]
+=== Support Tools
 
 AspectJ 1.2 contains two important changes to the supporting tools:
 
@@ -64,7 +66,8 @@ command-line.
 
 '''''
 
-=== [#runtime]#The Runtime Library#
+[[runtime]]
+=== The Runtime Library
 
 This release has minor updates to the runtime library classes. As with
 any release, you should compile and run with the runtime library that
@@ -82,7 +85,8 @@ heap usage for multi-threaded applications that use cflow.
 
 '''''
 
-=== [#devenv]#The AJDE Tools#
+[[devenv]]
+=== The AJDE Tools
 
 The AJDE based tools for JBuilder, NetBeans and Emacs continue to be
 independent SourceForge projects. The AspectJ 1.2 distribution includes
@@ -99,9 +103,11 @@ http://www.eclipse.org/ajdt[AJDT project website].
 
 '''''
 
-=== [#details]#Details# of some compiler changes
+[[details]]
+=== Details of some compiler changes
 
-==== [#WEAVE_TIME]#Compilation (weave) times reduced.#
+[[WEAVE_TIME]]
+==== Compilation (weave) times reduced.
 
 Our benchmark suite shows that AspectJ 1.2 is at least twice as fast in
 the weaving phase as AspectJ 1.1.1 for matches based on a variety of
@@ -116,7 +122,8 @@ recoverable data structures, allowing the JVM to optimise between
 performance and memory usage. Experiments forcing GC showed that we can
 achieve about a 20% memory usage reduction in this manner if needed.
 
-==== [#LAZY_TJP]#The -XlazyTjp option.#
+[[LAZY_TJP]]
+==== The -XlazyTjp option.
 
 Under AspectJ 1.1.1, if the body of an advice contained a reference to a
 non-statically determinable portion of `thisJoinPoint` (such as for
@@ -155,7 +162,8 @@ turned off. Using the `-XlazyTjp` option makes the program above run
 issues. The optimization is disabled at join points advised by around
 advice, and an Xlint warning will be displayed in these cases.
 
-==== [#INCREMENTAL]#Improvements to incremental compilation.#
+[[INCREMENTAL]]
+==== Improvements to incremental compilation.
 
 AspectJ 1.2 provides more complete incremental compilation support than
 AspectJ 1.1.1. Firstly, incremental compilation resulting from a change
@@ -172,7 +180,8 @@ Changes to a jar file on the inpath, injars or aspectpath will now be
 detected, but will trigger a full rebuild, as will any change to the
 paths used to control compilation.
 
-==== [#ERROR_MESSAGES]#Improved error messages.#
+[[ERROR_MESSAGES]]
+==== Improved error messages.
 
 AspectJ 1.1.1 did not provide source context information for messages
 produced during the weaving phase, even in the case where source files
@@ -226,7 +235,8 @@ file called `BadClass.java`, contains a join point
 (`method-call(void C.bad())` matched by a `declare error` statement on
 line 5 of the file `DeclareError.java`.
 
-==== [#LINT]#New lint warnings.#
+[[LINT]]
+==== New lint warnings.
 
 Consider the program:
 
@@ -324,7 +334,8 @@ A complimentary Xlint warning, `brokeSerialVersionCompatibility`
 process of weaving makes an incompatible change to a serializable class
 (for example, through the addition of an inter-type declared field).
 
-==== [#REWEAVABLE]#The -Xreweavable option.#
+[[REWEAVABLE]]
+==== The -Xreweavable option.
 
 The new `-Xreweavable` option produces class files that contain enough
 additional information in them that they can be rewoven. In time we hope
@@ -344,7 +355,8 @@ requires that all aspects that have previously modified a class file
 during weaving be present in the system during a reweave. An error will
 be issued if any are missing.
 
-==== [#INPATH]#The -inpath option.#
+[[INPATH]]
+==== The -inpath option.
 
 The new `-inpath` option replaces the `-injars` option (which is still
 supported for backwards compatibility). It allows both directories and
@@ -353,7 +365,8 @@ the path. This option makes it easy for class files produced as the
 result of building one project to become binary input to the compilation
 of a second project.
 
-==== [#COMPLIANCE]#The default compliance mode of the compiler has changed from -1.3 to -1.4.#
+[[COMPLIANCE]]
+==== The default compliance mode of the compiler has changed from -1.3 to -1.4.
 
 The default AspectJ compiler compliance level is now 1.4 (whereas in
 previous releases the default compliance level was 1.3). This has a
@@ -429,7 +442,8 @@ actual type of the receiver.
 
 '''''
 
-==== [#AJDOC]#The ajdoc tool makes a comeback in the AspectJ 1.2 distribution.#
+[[AJDOC]]
+==== The ajdoc tool makes a comeback in the AspectJ 1.2 distribution.
 
 `ajdoc` (the AspectJ replacement for the `javadoc` tool) is once again
 included in the AspectJ distribution. The `ajdoc` tool produces regular
@@ -456,7 +470,8 @@ image:images/ajdoc1.JPG[image]
 
 image:images/ajdoc2.JPG[image]
 
-==== [#LTW]#A sample script is supplied that supports load-time weaving from the command-line#
+[[LTW]]
+==== A sample script is supplied that supports load-time weaving from the command-line
 
 The AspectJ 1.2 distribution ships with sample scripts for Windows and
 Unix platforms that exploit AspectJ's binary weaving capabilities at
@@ -536,14 +551,16 @@ welcome contributions from users to improve these scripts.
 
 '''''
 
-==== [#SOFTEX]#SoftException now supports getCause()#
+[[SOFTEX]]
+==== SoftException now supports getCause()
 
 `org.aspectj.lang.SoftException` now supports the `getCause()` method,
 which returns the original exception wrapped by the `SoftException`.
 This means that exception chains will print correctly on 1.4 and later
 JREs.
 
-==== [#LTW2]#org.aspectj.weaver.tools package added#
+[[LTW2]]
+==== org.aspectj.weaver.tools package added
 
 A new set of public APIs are exported by the
 link:api/index.html[`org.aspectj.weaver.tools`] package that can be used
@@ -554,8 +571,7 @@ example of how to use these APIs, see the
 
 '''''
 
-[#allchanges]##
-
+[[allchanges]]
 === All changes are listed in the bug database
 
 For a complete list of changes in the 1.2 release, search for
diff --git a/docs/dist/doc/README-12.html b/docs/dist/doc/README-12.html
deleted file mode 100644
index 8f9f541ff..000000000
--- a/docs/dist/doc/README-12.html
+++ /dev/null
@@ -1,555 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2003,2004 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.2 Readme</h1>
-
-<p> The definition of the AspectJ language is unchanged in the 1.2 release.
-Instead, AspectJ 1.2 provides major improvements to the functionality of the 
-supporting tools
-and enforces some language limits that went unchecked before.
-This document describes the tools differences between
-AspectJ versions 1.2 and 1.1.1.
-Users new to AspectJ need only read
-the <a href="progguide/index.html">AspectJ Programming Guide</a>
-since it describes the 1.2 language.
-Users familiar with AspectJ 1.1 may find this document
-a quicker way to learn what changed in the tools, 
-and should use it as a guide for porting
-programs from 1.1 to 1.2,
-together with <a href="porting.html">porting.html</a>.
-</p>
-
-<p>This document first summarizes changes from the 1.1.1 release in
-</p>
-
-<ul>
-  <li><a href="#compiler">the compiler</a>,</li>
-  <li><a href="#tools">the support tools</a>,</li>
-  <li><a href="#runtime">the runtime</a>,</li>
-  <li><a href="#devenv">the development environment support</a>,</li>
-</ul>
-
-<p> then <a href="#details">details</a> some of the changes,
-    and finally points readers to the bug database for 
-    <a href="#allchanges">all the changes</a>.
-</p>
-
-<!-- ============================== -->
-
-<!-- ============================== -->
-<hr>
-<h2><a name="compiler">The Compiler</a></h2>
-
-  Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler...
-  
-  <ul>
-  <li><a href="#WEAVE_TIME">Is faster</a>, with weaving completing in less than half the time it
-      used to take in many cases.
-      <a name="WEAVE_CHART"><img src="images/AspectJ11v12.JPG"></img></a>.</li>
-  <li>Supports the <a href="#LAZY_TJP">-XlazyTjp option</a> which produces code that runs 
-  faster and uses less memory in some common cases.</li>
-  <li>Has <a href="#INCREMENTAL">much better support for incremental compilation</a>.</li>
-  <li>Produces <a href="#ERROR_MESSAGES">better error messages</a>.</li>
-  <li>Has some <a href="#LINT">new lint warnings</a> to catch common mistakes and changes to serializability.</li>
-  <li>Supports the <a href="#REWEAVABLE">-Xreweavable option</a> that allows classes to be woven more
-  than once.<li>
-  <li>Supports the <a href="#INPATH">-inpath option</a> which allows both directories and jars
-  containing class files to be specified as input to the weaver.</li>
-  <li><a href="#COMPLIANCE">Changes the default compiler compliance mode</a> from -1.3 to -1.4.
-  </ul>
-
-  <p> A short description of the options ajc accepts is available with
-  "<code>ajc -help</code>". 
-  Longer descriptions are available in the 
-  <a href="devguide/ajc-ref.html">Development Environment Guide
-  section on ajc</a>. </p>
-  <p> </p>
-
-
-<!-- ============================== -->
-<hr>
-<h2><a name="tools">Support Tools</a></h2>
-
-  <p>AspectJ 1.2 contains two important changes to the supporting tools:</p>
-  
-  <ul>
-  <li><a href="#AJDOC">ajdoc</a> is back<li>A sample script is supplied for <a href="#LTW">load-time weaving</a> from the command-line.
-  </ul> 
-<!-- ============================== -->
-<hr>
-<h2><a name="runtime">The Runtime Library</a></h2>
-
-  <p>This release has minor updates to the runtime library classes.
-     As with any release, you should compile and run with the runtime
-     library that came with your compiler, and you may run with
-     a later version of the library without recompiling your code.</p>
-
-  <ul>
-  <li><a href="#SOFTEX"><code>SoftException</code></a> now supports <code>getCause()</code>.</li>
-  
-  <li>Although not part of <code>aspectjrt.jar</code> this release also provides a new set of
-  tools APIs in the <a href="#LTW2"><code>org.aspectj.weaver.tools</code></a> that provide a weaving class loader
-  and an adapter that can be used to integrate load-time weaving into an existing class loader
-  hierarchy.</li>
-  <li>Cflow stack management has been modified to use thread local storage on JVMs that support this feature.
-  This improves performance in terms of heap usage for multi-threaded applications that use cflow.
-  </ul>
-
-<!-- ============================== -->
-<hr>
-<h2><a name="devenv">The AJDE Tools</a></h2>
-
-  <p> The AJDE based tools for JBuilder, NetBeans and Emacs continue to be independent
-  SourceForge projects. The AspectJ 1.2 distribution includes an updated version of the 
-  AjBrowser tool that benefits from all the enhancements made in the 1.2 compiler.</p>
-  
-  <p>The 1.2 release of AspectJ also lays a lot of the groundwork for a much better AspectJ
-  IDE experience that we hope to surface initially through AJDT (AspectJ support 
-	for Eclipse). Amongst the many improvements, we
-  will have full eager parsing support that avoids the need to keep the whole structure
-  model of a project in memory, hopefully making AJDT much less memory hungry and much
-  slicker to use. For more details see the <a href="http://www.eclipse.org/ajdt">
-  AJDT project website</a>.
-
-<!-- ============================== -->
-<hr>
-<h2><a name="details">Details</a> of some compiler changes</h2>
-
-  <h3><a name="WEAVE_TIME">Compilation (weave) times reduced.</a></h3>
-  
-  <p>Our benchmark suite shows that AspectJ 1.2 is at least twice as fast in the
-  weaving phase as AspectJ 1.1.1 for matches based on a variety of pointcut expressions
-  (see the <a href="#WEAVE_CHART">chart above</a>). We've also made the base 
-  incremental compilation implementation in AspectJ 1.2 approximately twice as fast
-  as in AspectJ 1.1.1, so when this is combined with the weave time improvements you
-  should see speed-ups of up to 4x for incremental compilation.</p>
-  
-  <p>In addition, AspectJ 1.2 maintains only weak references to some of its recoverable data structures,
-  allowing the JVM to optimise between performance and memory usage. Experiments forcing GC
-  showed that we can achieve about a 20% memory usage reduction in this manner if needed.</p>
-  
-  <h3><a name="LAZY_TJP">The -XlazyTjp option.</a></h3>  
-  
-  <p>Under AspectJ 1.1.1, if the body of an advice contained a reference to a 
-  non-statically determinable portion of <code>thisJoinPoint</code> (such as for example a call
-  to <code>getArgs()</code>), then a JoinPoint object was always creating before entering the advice.
-  This was the case even if the advice was guarded with an <code>if()</code> pointcut that 
-  evaluated to false. </p>
-  
-  <p>AspectJ 1.2 now supports the <code>-XlazyTjp</code> option that only creates the JoinPoint object just
-  before dispatching to the advice body. By promoting the guard to a test in an <code>if()</code> pointcut,
-  the creation of the JoinPoint object can be avoided altogether in the case where the test returns false.</p>
-  
-  <p>Consider a simple tracing aspect as follows:</p>
-  
-  <pre>
-  
-  public aspect Tracing {
-    
-    public static boolean enabled = false;
-  
-    pointcut toBeTraced() : execution(* *(..)) || execution(new(..));
-    
-    before() : toBeTraced() && if(enabled) {
-      Object[] args = thisJoinPoint.getArgs();
-      // format args and print out entry trace record etc....
-    }
-  }
-  
-  </pre>
-  
-  <p> The most important consideration is the system overhead when tracing is turned off. Using the 
-  <code>-XlazyTjp</code> option makes the program above run 10-100x faster, even when running a 
-  small test case with minimal GC issues. The optimization is disabled at join points advised by
-  around advice, and an Xlint warning will be displayed in these cases.
-  </p>
-
-  <h3><a name="INCREMENTAL">Improvements to incremental compilation.</a></h3>  
-  
-  <p>AspectJ 1.2 provides more complete incremental compilation support than AspectJ 1.1.1. 
-  Firstly, incremental compilation resulting from a change to a source file is now approximately
-  twice as fast as it was under 1.1.1 (even before taking the improvements to weaving time into
-  account). Secondly, the incremental coverage now takes into account changes to resources, classes and jars
-  on the inpath, injars, and aspectpath. The new <code>inpath</code> option in AspectJ 1.2 allows
-  directories to be specified in addition to jars (just like a classpath) as input to the weaver. Any update, addition
-  or deletion of a class file in a directory on the inpath will cause incremental (re)weaving.  
-  
-  <p>Changes to a jar file on the inpath, injars or aspectpath will now be detected, but will trigger a
-  full rebuild, as will any change to the paths used to control compilation.</p>
-
-  <h3><a name="ERROR_MESSAGES">Improved error messages.</a></h3>  
-  
-  <p>AspectJ 1.1.1 did not provide source context information for messages produced during the weaving phase,
-  even in the case where source files were passed to the compiler. For example, an error message arising as 
-  a result of a <code>declare error</code> statement might look as follows under AspectJ 1.1.1: </p>
-
-  <font color="red">
-  <pre>
-
-  BadClass.java:6 should not be calling bad methods
-  </pre>
-  </font>
-  
-  <p>whereas in AspectJ 1.2 you will see:</p>
-  
-  <font color="red">
-  <pre>
-
-  BadClass.java:6 error should not be calling bad methods
-  new C().bad();
-  ^^^^^^^^^^^^^^
-       method-call(void C.bad())
-       see also: DeclareError.java:5
-  </pre>
-  </font>
-  
-  <p>There are four new things to note about this error message. Firstly, errors and 
-  warnings are now prefixed with the word "error", or "warning" as appropriate. 
-  Secondly, the offending line of source is shown if source code is available. Thirdly, 
-  in the case of weaver messages arising as a result of <code>declare error</code> and 
-  <code>declare warning</code> statements, AspectJ now shows not only the location of the 
-  error or warning, but also the location of the <code>declare</code> statement itself. 
-  Finally, note that messages produced as a result of <code>declare error</code> and 
-  <code>declare warning</code> statements now also display the matched join point at the 
-  location of the error:</p>
-  
-  <p>When source code is not available, the messages show the binary input source (class
-  file or jar file) in which the error or warning was detected: </p>  
-  <font color="red">
-  <pre>
-
-  BadClass.java:6 error should not be calling bad methods
-  (no source information available)
-         method-call(void C.bad())
-         see also: C:\...\DeclareError.java:5
-         see also: C:\...\bin-input.jar
-  </pre>
-  </font>
-
-  <p>This error message tells us that <code>BadClass.class</code> contained in a jar on the inpath called <code>bin-input.jar</code>,
-  and originally compiled from a source file called <code>BadClass.java</code>, contains a join point 
-  (<code>method-call(void C.bad())</code> matched by a <code>declare error</code> statement on line 5 of the file 
-  <code>DeclareError.java</code>.
-
-  <h3><a name="LINT">New lint warnings.</a></h3>  
-  
-  <p>Consider the program:</p>
-  
-  <pre>
-  <code>
-  01 class A {
-  02   public void doIt() {...};
-  03 }
-  04
-  05 class B extends A {
-  06   public void doThisToo() {...};
-  07 }
-  08
-  09
-  10 public class CallsAandB {
-  11 
-  12  public static void main(String[] args) {
-  13    B b = new B();
-  14    A bInDisguise = new B();
-  15   
-  16    b.doIt();               // AspectJ 1.2 matches here
-  17    bInDisguise.doIt();     // this is never matched
-  18  }
-  19
-  20 }
-  21
-  22 aspect CallPCDMatchingExample {
-  23
-  24   before() : call(* B.doIt(..)) {
-  25     System.out.println("About to call B.doIt(...)");
-  26   }
-  27
-  28 }
-  </code>
-  </pre>
-  
-  <p>Because the static type of <code>bInDisguise</code> is <code>A</code> (line 14), the call on line
-  17 is never matched by the pointcut expression on 24, even though the runtime type of 
-  <code>bInDisguise</code> is <code>B</code>. Type patterns matched in <code>call</code> pointcut
-  designators are matched based on static type matching. Some users have found
-  this static type matching confusing, and AspectJ 1.2 has a new Xlint warning 
-  (<code><b>unmatchedSuperTypeInCall</b></code>) which is enabled by default.</p>
-
-  <p>The compiler will now produce a warning whenever a call pointcut designator does not match at a
-  join point, and a user may have expected it to. Compiling the above program using AspectJ 1.2 
-  produces the following compiler output:</p>
-
-  <pre>
-  <code>
-  <font color="red">
-  CallsAandB.java:24 warning does not match because declaring type is A, if match desired use target(B) [Xlint:unmatchedSuperTypeInCall]
-  before() : call(* B.doIt(..)) {
-             ^^^^^^^^^^^^^^^
-	  see also: CallsAandB.java:17
-  </font>
-  <font color="blue">
-  1 warning
-  </font>
-  </code>
-  </pre>
-
-  <p> The warning is telling us that the call pointcut associated with the before advice on line 24 
-  of the source file does not match at a join point where the user may have expected it to. The source 
-  location corresponding to the unmatched join point is indicated by the "see also" line - in this case 
-  line 17 of the source file. At line 17 we find a call to <code>bInDisguise.doIt()</code>. Since the 
-  static type of <code>bInDisguise</code> is <code>A</code>, this call will never be matched.  
-  The warning also tells us a possible solution if we intended the pointcut to match at this join point: use 
-  <code>call(* doIt(..) && target(B)</code>.</p>
-
-  <p>If you find warnings of this kind coming out when you use the AspectJ 1.2 compiler, the recommended fix is to
-  switch to using the <code>target</code> designator in place of a type pattern in the <code>call</code> pointcut 
-  expression. Note that there is no loss of runtime efficiency here - runtime tests are only added in the cases
-  where it cannot be determined at compile time whether the type of the receiver will match the type specified in
-  the <code>target</code> expression. Also note that <code>target</code> cannot be used in <code>declare</code> statements.
-  </p>
-  
-  <p>A new Xlint warning, <code><b>needsSerialVersionUIDField</b></code> (disabled by default) will produce a 
-  warning at compile time if the process of weaving changes the default <code>serialVersionUID</code> of
-  a serializable class, and the class does not define a <code>serialVersionUID</code>. By defining a 
-  <code>serialVersionUID</code> field, the programmer can ensure that objects serialized without the aspect
-  present can be read by a version of the program in which the aspect is present, and vice-versa.</p>
-  
-  <p>A complimentary Xlint warning, <code><b>brokeSerialVersionCompatibility</b></code> (disabled by default) will
-  produce a warning at compile time if the process of weaving makes an incompatible change to a serializable
-  class (for example, through the addition of an inter-type declared field). 
-
-  <h3><a name="REWEAVABLE">The -Xreweavable option.</a></h3>  
-  
-  <p>The new <code>-Xreweavable</code> option produces class files that contain enough additional information in
-  them that they can be rewoven. In time we hope that this can become a standard option, replacing the current
-  <code>-Xnoweave</code> option. Using reweavable produces class files that can be legally loaded by a JVM, whereas
-  with noweave, it is too easy to produce class files that will result in a verify error at runtime. The reweavable
-  option makes it easy to weave code many times without having to decide which weave is the final one. In a future version
-  of the AspectJ compiler, producing reweavable class files may become the default option. The trade-off at the moment is that
-  reweavable class files are currently approximately twice the size of their non-reweavable counterparts. 
-  
-  <p>To ensure consistent semantics when reweaving, the AspectJ compiler requires that all aspects that have previously
-  modified a class file during weaving be present in the system during a reweave. An error will be issued if any are
-  missing.
-  
-  <h3><a name="INPATH">The -inpath option.</a></h3>  
-  
-  <p>The new <code>-inpath</code> option replaces the <code>-injars</code> option (which is still supported
-  for backwards compatibility). It allows both directories and jar files to be specified using path separators 
-  to separate entries in the path. This option makes it easy for class files produced as the result of building
-  one project to become binary input to the compilation of a second project. 
-
-  <h3><a name="COMPLIANCE">The default compliance mode of the compiler has changed from -1.3 to -1.4.</a></h3>  
-  
-  <p>The default AspectJ compiler compliance level is now 1.4 (whereas in
-   previous releases the default compliance level was 1.3). This has a number 
-   of implications: 
-   <ul>
-   <li> class files generated by the compiler are now JRE v1.2 and upwards
-   compatible. (At compliance level 1.3, AspectJ generated class files that
-   were compatible with JRE 1.1 also).
-   <li> <code>call</code> pointcuts may match more join points than in the same
-   program compiled at compliance level 1.3.
-   </ul>
-   <p>The AspectJ compiler can be restored to 1.3 compliance settings by specifying the
-   "-1.3" option on the command-line.
-   </p>
-   <p>Consider again the following example program which illustrates the differences in join point matching
-   with the <code>call</code> pointcut designator between 1.4 and 1.3 compliance levels. 
-
-   <pre>
-   <code>
-   01 class A {
-   02   public void doIt() {...};
-   03 }
-   04
-   05 class B extends A {
-   06   public void doThisToo() {...};
-   07 }
-   08
-   09
-   10 public class CallsAandB {
-   11 
-   12  public static void main(String[] args) {
-   13    B b = new B();
-   14    A bInDisguise = new B();
-   15   
-   16    b.doIt();               // AspectJ 1.2 matches here
-   17    bInDisguise.doIt();     // this is never matched
-   18  }
-   19
-   20 }
-   21
-   22 aspect CallPCDMatchingExample {
-   23
-   24   before() : call(* B.doIt(..)) {
-   25     System.out.println("About to call B.doIt(...)");
-   26   }
-   27
-   28 }
-   </code>
-   </pre>
-
-   <p>When this program is compiled with AspectJ 1.2 using the default compiler options, 
-   it will produce one line of output when it is executed:</p>
-   <p><code>About to call B.doIt(...)</code></p>
-   <p>The same program compiled under AspectJ 1.1 (or using AspectJ 1.2 with the -1.3 flag specified) 
-   does not produce any output when it is run. The reason for the additional call pcd match is that 
-   prior to compliance level 1.4, Java compilers produced bytecodes that call A.doIt() (the defining type of the method),
-   rather than B.doIt() (the declared type in the program text). The generated call to
-   A.doIt() is not matched by the call pcd used in the before advice.  At 
-   compliance level 1.4, the bytecodes retain the declared type of the receiver in the
-   program source, generating a call to B.doIt(), which <i>is</i> matched by the call pcd.
-
-   <p>This is a good example of why the recommended style is to use <code>call(* doIt(..)) && target(B)</code>,
-   which always matches based on the actual type of the receiver.
-  
-<!-- ============================== -->
-<hr>
-
-  <h3><a name="AJDOC">The ajdoc tool makes a comeback in the AspectJ 1.2 distribution.</a></h3>  
-
-  <p><code>ajdoc</code> (the AspectJ replacement for the <code>javadoc</code> tool) is once again included in
-  the AspectJ distribution.  The <code>ajdoc</code> tool produces regular javadoc that also shows advises and
-  advised by relationships next to methods and advice. A future enhancement will show inter-type declarations
-  in the target class too. </p>
-<p><b>Known limitations: </b>Please note that <code>ajdoc</code> documents 
-advice and pointcut members, shows where advice applies and links affected 
-members back to the advice.&nbsp; It currently does not document or add 
-structural links for any inter-type declarations or other declare forms.</p>
-<p>Run the &quot;ajdoc.bat&quot; script just 
-	as you run javadoc.&nbsp; For a list of accepted parameters run &quot;ajdoc 
-	-help&quot;.&nbsp; For example, to document everything in the Spacewar example 
-	run:<br>
-	<tt>&gt; cd examples<br>
-	&gt; ajdoc -d doc -private spacewar coordination</tt></p>
-  
-  <p><code>ajdoc</code> sample output for an aspect source file:</p>
-  
-  <p><img src="images/ajdoc1.JPG"/></p>
-  
-  <p><code>ajdoc</code> sample output for advised methods:</p>
-  
-  <p><img src="images/ajdoc2.JPG"/></p>
-
-  <h3><a name="LTW">A sample script is supplied that supports load-time weaving from the command-line</a></h3>  
-  
-  <p>The AspectJ 1.2 distribution ships with sample scripts for Windows and Unix platforms that exploit AspectJ's 
-  binary weaving capabilities at application load time. You will find these scripts in the 
-  <code>doc/examples/ltw</code> directory of your AspectJ installation. </p>
-  
-  <p>The scripts allow you to set an environment variable, <code>ASPECTPATH</code>, containing a path-separator
-  delimited list of aspect-library jar files. A Java application can then be launched using the "<code>aj</code>"
-  script ("<code>aj</code>" is to "<code>ajc</code>" as "<code>java</code>" is to "<code>javac</code>"). If the
-  <code>ASPECTPATH</code> is unset or empty, "<code>aj</code>" behaves exactly the same as "<code>java</code>",
-  but if the <code>ASPECTPATH</code> contains one or more aspect libraries, the aspects in the library will be 
-  linked (woven) with the application code as it is loaded.<p>
-  
-  <p>The <code>doc/examples/ltw</code> directory of your AspectJ installation contains a sample application that
-  demonstrates these capabilities. Following the instructions in the <code>README</code> file in that directory,
-  running "<code>aj tracing.ExampleMain</code>" with <code>ASPECTPATH</code> unset produces the output:</p>
-  
-  <font color="blue">
-  <pre>
-  c1.perimeter() = 12.566370614359172
-  c1.area() = 12.566370614359172
-  s1.perimeter() = 4.0
-  s1.area() = 1.0
-  c2.distance(c1) = 4.242640687119285
-  s1.distance(c1) = 2.23606797749979
-  s1.toString(): Square side = 1.0 @ (1.0, 2.0)
-  </pre>
-  </font>
-  
-  <p>If you set <code>ASPECTPATH</code> to include <code>../jars/tracingLib.jar</code>, and run
-  "<code>aj tracing.ExampleMain</code>" again, the output will be:</p>
-  
-  
-  <font color="blue">
-  <pre>
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Circle(double, double, double)
-  <-- tracing.Circle(double, double, double)
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Circle(double, double, double)
-  <-- tracing.Circle(double, double, double)
-  --> tracing.Circle(double)
-  <-- tracing.Circle(double)
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Square(double, double, double)
-  <-- tracing.Square(double, double, double)
-  --> tracing.Square(double, double)
-  <-- tracing.Square(double, double)
-  --> double tracing.Circle.perimeter()
-  <-- double tracing.Circle.perimeter()
-c1.perimeter() = 12.566370614359172
-  --> double tracing.Circle.area()
-  <-- double tracing.Circle.area()
-c1.area() = 12.566370614359172
-  --> double tracing.Square.perimeter()
-  <-- double tracing.Square.perimeter()
-s1.perimeter() = 4.0
-  --> double tracing.Square.area()
-  <-- double tracing.Square.area()
-s1.area() = 1.0
-  --> double tracing.TwoDShape.distance(TwoDShape)
-    --> double tracing.TwoDShape.getX()
-    <-- double tracing.TwoDShape.getX()
-    --> double tracing.TwoDShape.getY()
-    <-- double tracing.TwoDShape.getY()
-  <-- double tracing.TwoDShape.distance(TwoDShape)
-  etc...
-  </pre>
-  </font>
-  
-  <p>The scripts only support JDK 1.4 and above - attempting to use them with a 1.3 or lower JDK will most
-  likely produce <code>NoClassDefFound</code> errors. We welcome contributions from users to improve these
-  scripts.</p>
-  
-<!-- ============================== -->
-<hr/>
-  
-  <h3><a name="SOFTEX">SoftException now supports getCause()</a></h3>  
-  
-  <p><code>org.aspectj.lang.SoftException</code> now supports the <code>getCause()</code> method, which returns the
-  original exception wrapped by the <code>SoftException</code>. This means that exception chains will print correctly
-  on 1.4 and later JREs.
-
-  <h3><a name="LTW2">org.aspectj.weaver.tools package added</a></h3>  
-  
-  <p>A new set of public APIs are exported by the 
-  <a href="api/index.html"><code>org.aspectj.weaver.tools</code></a> package that can be used
-  to integrate load-time weaving into an existing class loader hierachy. The package implementation
-  is included in <code>aspectjtools.jar</code>. For an example of how to use these APIs, see the
-  <code>org.aspectj.weaver.WeavingURLClassLoader</code> implementation.
-
-<hr/>
-	<a name="allchanges"></a>
-	<h2>All changes are listed in the bug database</h2>
-	For a complete list of changes in the 1.2 release, search for 
-	<code>target 1.2</code> in the bug database:
-	<a href="https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2">
-		https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2
-	</a>
-  
-</body> </html>
diff --git a/docs/dist/doc/README-121.adoc b/docs/dist/doc/README-121.adoc
index f2a66fda0..74d4b3030 100644
--- a/docs/dist/doc/README-121.adoc
+++ b/docs/dist/doc/README-121.adoc
@@ -108,7 +108,7 @@ aspectjtools.jar around (aspectjweaver.jar is approx. 5 times smaller).
 
 In addition, the load-time weaving "aj" script which was included in the
 doc/examples/ltw directory in the 1.2 distribution has been moved into
-the regular bin directory. See link:README-12.html[README-12] for
+the regular bin directory. See xref:README-12.adoc[README-12] for
 details of using this script.
 
 === Binary Compatibility
@@ -125,8 +125,7 @@ comes with the distribution you used to build your application.
 
 '''''
 
-[#allchanges]##
-
+[[allchanges]]
 === All changes are listed in the bug database
 
 For a complete list of changes in the 1.2.1 release, search for
diff --git a/docs/dist/doc/README-121.html b/docs/dist/doc/README-121.html
deleted file mode 100644
index 408c910f6..000000000
--- a/docs/dist/doc/README-121.html
+++ /dev/null
@@ -1,148 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.2.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2004 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.2.1 Readme</h1>
-
-<p>AspectJ 1.2.1 is largely a bug-fix release and the definition of the 
-	AspectJ language is unchanged from the 1.2.0 release (with the exception
-	that AspectJ 1.2.1 permits the use of the '+' operator to concatenate
-	the messages for declare error and warning statements).
-This document describes the tools differences between AspectJ versions 1.2 and 1.2.1.
-Users familiar with AspectJ 1.2 may find this document
-a quicker way to learn what changed in the tools.
-</p>
-
-<p>This document summarizes changes in:
-<ul>
-	<li>Weaver messages</li>
-	<li>Dump support</li>
-	<li>JDT Compiler version</li>
-	<li>Line number information for join points</li>
-	<li>Runtime performance</li>
-	<li>String concatentation in declare error and warning statements</li>
-	<li>Load-time weaving support</li>
-	<li>Use of aspect libraries generated by ajc 1.2.1 with earlier versions of ajc</li>
-</ul>	
-	
-</p>
-<p>
-	See the <a href="changes.html">changes document</a> for more details, or
-	<a href="#allchanges">all the changes</a> as detailed in the bugzilla 
-	database.
-</p>
-
-<h2>Weaver Informational Messages</h2>
-<p> 
-	The AspectJ 1.2.1 compiler can produce informational messages about the
-	weaving process. To see these messages, use the -showWeaveInfo compiler
-	option, or set showweaveinfo=true in the iajc ant task.
-</p>	
-<p>The following is an example of the messages produced when this option is enabled:</p>
-<pre>
-	C:\aspectj1.2.1\doc\examples\tjp>ajc -showWeaveInfo *.java
-
-    Type 'tjp.Demo' (Demo.java:20) advised by around advice from 'tjp.GetInfo' 
-    (GetInfo.java:26) [RuntimeTest=true]
-
-    Type 'tjp.Demo' (Demo.java:30) advised by around advice from 'tjp.GetInfo' 
-    (GetInfo.java:26) [RuntimeTest=true]
-
-    Type 'tjp.Demo' (Demo.java:34) advised by around advice from 'tjp.GetInfo' 
-    (GetInfo.java:26) [RuntimeTest=true]
-</pre>
-
-<h2>Dump Support</h2>
-<p>In the event of a compiler crash, AspectJ 1.2.1 will produce a dump file giving
-	important information about the state of the compiler at the time of the crash. 
-	These dump files should enable us to analyze problems more effectively. In the
-	rare event that you witness a compiler crash, please attach the dump file to 
-	the bug report.</p>
-<p>In addition to producing a dump file when an abort condition is detected, the
-	AspectJ 1.2.1 compiler can also be requested to create a dump file on detection
-	of a compilation error. Set the property org.aspectj.weaver.Dump.condition=error to
-	enable this behaviour.</p>
-
-<h2>JDT Compiler Version</h2>
-<p>AspectJ 1.2.1 is based on the Eclipse 3.0 final JDT compiler.</p>
-
-<h2>Line Number Information for Join Points</h2>
-<p>For source files compiled by ajc (as opposed to binary inputs to the compiler
-	compiled with some other java compiler), ajc now emits better line number information
-	for execution join points. In particular, for a method, constructor or advice
-	execution join point (as matched for example by a declare error or declare warning
-	statement), ajc 1.2.1 reports the first line number of the declaration,
-	as opposed to the line number of the first line of code in the body. </p>
-
-<h2>Runtime Performance</h2>
-<p>AspectJ 1.2.1 contains a small number of runtime performance optimisations, including
-	optimisations of if(true) and if(false) pointcut expressions, caching of getSignature()
-	and toString() results on JoinPoint objects, and an optimised implementation of cflow.</p>
-	<p>In the case where there are no arguments bound in
-     the cflow pointcut, programs compiled under AspectJ 1.2.1 and that make
-     heavy use of cflow will run significantly faster. Thanks to the abc compiler team 
-     for detecting this performance related bug and for piloting the fix. </p>
-
-<h2>String Concatentation in Declare Error/Warning Statements</h2>
-<p>String concatentation in declare error and warning statements is now supported. 
-	For example, you can write:</p>
-	<pre>
-		declare warning : jdbcCall() &amp;&amp; !inDataLayer()
-		                : "Please don't make calls to JDBC " +
-		                  "outside of the data layer.";
-	</pre>
-	
-<h2>Load-time Weaving Support</h2>
-<p>
-	The AspectJ 1.2.1 distribution contains a new jar in the lib directory,
-	aspectjweaver.jar, that contains the subset of aspectjtools.jar needed
-	for weaving only. This jar may be used in situations where you wish to
-	exploit AspectJ's binary weaving capabilities, but do not want the full
-	aspectjtools.jar around (aspectjweaver.jar is approx. 5 times smaller).
-</p>
-<p>
-	In addition, the load-time weaving "aj" script which was included in the
-	doc/examples/ltw directory in the 1.2 distribution has been moved into
-	the regular bin directory. See <a href="README-12.html">README-12</a> for
-	details of using this script.
-</p>
-
-<h2>Binary Compatibility</h2>
-<p>AspectJ 1.2.1 introduces a backwards-incompatible change to the class
-	file format generated by the AspectJ compiler. Classes generated by
-	ajc v1.2.1 cannot be used on the inpath or aspectpath of a weaver from
-	a prior version of the compiler. Classes generated by prior versions of
-	the compiler can of course be placed on the inpath or aspectpath of the
-	1.2.1 weaver.</p>
-<p>
-	As ever, you should use the AspectJ runtime library (aspectjrt.jar) that 
-	comes with the distribution you used to build your application.
-</p>
-<hr/>
-
-
-	<a name="allchanges"></a>
-	<h2>All changes are listed in the bug database</h2>
-	For a complete list of changes in the 1.2.1 release, search for 
-	<code>target 1.2.1</code> in the bug database:
-	<a href="https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2.1">
-		https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.2.1&bug_status=RESOLVED&resolution=FIXED
-	</a>
-  
-</body> </html>
diff --git a/docs/dist/doc/README-150.adoc b/docs/dist/doc/README-150.adoc
index 3e553f239..2f29cc894 100644
--- a/docs/dist/doc/README-150.adoc
+++ b/docs/dist/doc/README-150.adoc
@@ -4,8 +4,7 @@
 
 AspectJ 5 introduces several important changes to the language and tools
 in order to support Java 5 and extend the capabilities of AspectJ in
-general. For language changes, see link:adk15notebook/index.html[AspectJ
-5 Developer's Notebook]. For tools changes, see the
+general. For language changes, see xref:../../adk15ProgGuideDB/adk15notebook.adoc[AspectJ 5 Developer's Notebook]. For tools changes, see the
 link:devguide/index.html[AspectJ Development Environment Guide],
 especially the section on link:devguide/ltw.html[Load-time weaving]. The
 changes are summarized in the faq.html#q:aspectj5features[FAQ entry on
diff --git a/docs/dist/doc/README-150.html b/docs/dist/doc/README-150.html
deleted file mode 100644
index f36bc132b..000000000
--- a/docs/dist/doc/README-150.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 5 Development Kit v1.5.0 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2005 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 5 Readme</h1>
-
-<p>AspectJ 5 introduces several important changes to the language and tools
-in order to support Java 5 and extend the capabilities of AspectJ in
-general. For language changes, see <a href="adk15notebook/index.html">AspectJ 5
-Developer's Notebook</a>.  For tools changes, see the
-<a href="devguide/index.html">AspectJ Development Environment Guide</a>,
-    especially the section on 
-<a href="devguide/ltw.html">Load-time weaving</a>.
-The changes are summarized in the 
-    <a href="faq.html#q:aspectj5features">FAQ entry on AspectJ 5</a>.
-
-</p>
-<p>
-    Some of the other documentation has not been updated for AspectJ 5.
-    For the latest documentation, see
-    <a href="http://eclipse.org/aspectj/doc/next/index.html">
-        http://eclipse.org/aspectj/doc/next/index.html
-    </a>, linked off 
-    <a href="http://eclipse.org/aspectj/docs.php">
-        the AspectJ documentation home page
-    </a>.
-</p>
-
-<p>For information on bug fixes in AspectJ 5 v1.5.0, see the <a href="changes.html">
-changes</a> document.</p>
-
-</body> </html>
diff --git a/docs/dist/doc/README-151.html b/docs/dist/doc/README-151.html
deleted file mode 100644
index ec5d17877..000000000
--- a/docs/dist/doc/README-151.html
+++ /dev/null
@@ -1,45 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 5 Development Kit v1.5.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2006 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 5 v1.5.1 Readme</h1>
-
-<p>
-This release is primarily a bug fix and performance / memory usage release. 
-Over 70 fixes and enhancements have been incorporated since 1.5.0, you can see 
-the list through 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.1&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED">
-this bugzilla query</a>. 
-</p>
-<p>
-AspectJ 1.5.1 has significantly lower memory usage than AspectJ 1.5.0, 
-especially when building inside of AJDT. The improvements are also noticeable 
-when batch building with Ant, or when load-time weaving. Batch building a 
-project with over 1000 source files with both AspectJ 1.5.1 and AspectJ 1.5.0 
-shows a 16% reduction in peak memory usage, and an 8% reduction in heap consumed 
-by temporary objects. The AspectJ 1.5.1 compiler integrated into AJDT gives memory 
-savings of at least 50%. The greater savings in the AJDT environment are due to 
-improvements in areas such as structure model generation that are not exercised 
-</p>
-
-<p>For information on bug fixes in AspectJ 5 v1.5.1, see the <a href="changes.html">
-changes</a> document.</p>
-
-</body> 
-</html>
diff --git a/docs/dist/doc/README-152.adoc b/docs/dist/doc/README-152.adoc
index ec41e1488..99ac5a87d 100644
--- a/docs/dist/doc/README-152.adoc
+++ b/docs/dist/doc/README-152.adoc
@@ -10,19 +10,19 @@ bugzilla query].
 
 Notable changes since the 1.5.1 release include:
 
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=126167[[126167]] The
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=126167[[_126167]] The
 handling of proceed in @Around advice has changed to be more compatible
 with code style.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=147711[[147711]] Members
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=147711[[_147711]] Members
 generated as a result of the AspectJ weaving process are now marked Java
 synthetic - enabling coverage tools such as Emma to process woven
 classes correctly.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=138316[[138316]] AspectJ
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=138316[[_138316]] AspectJ
 has now transitioned from the CPL to the EPL license.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=140695[[140695]] Using a
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=140695[[_140695]] Using a
 more optimal world for managing types when load-time weaving - reduces
 heap usage (work in progress).
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=101983[[101983]] AspectJ
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=101983[[_101983]] AspectJ
 can now support separate output folders for each input source folder -
 enables AJDT to behave more like JDT.
 
diff --git a/docs/dist/doc/README-152.html b/docs/dist/doc/README-152.html
deleted file mode 100644
index c53b7d16c..000000000
--- a/docs/dist/doc/README-152.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 5 Development Kit v1.5.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2006 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 5 v1.5.2 Readme</h1>
-
-<p>
-This release is primarily a bug fix release. 
-It includes approximately 60 fixes and enhancements that have been incorporated since 
-the 1.5.1 release. You can see 
-the full list through 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.2&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED">
-this bugzilla query</a>. 
-</p>
-<p>
-Notable changes since the 1.5.1 release include:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=126167">[126167]</a> The handling of proceed in @Around advice has changed to be more compatible with code style.</li>
-<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=147711">[147711]</a> Members generated as a result of the AspectJ weaving process are now marked Java synthetic - enabling coverage tools such as Emma to process woven classes correctly.</li>
-<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=138316">[138316]</a> AspectJ has now transitioned from the CPL to the EPL license.</li>
-<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=140695">[140695]</a> Using a more optimal world for managing types when load-time weaving - reduces heap usage (work in progress).</li>
-<li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=101983">[101983]</a> AspectJ can now support separate output folders for each input source folder - enables AJDT to behave more like JDT.</li>
-</ul>
-</p>
-
-<p>For information on bug fixes in AspectJ 5 v1.5.2, see the <a href="changes.html">
-changes</a> document.</p>
-
-</body> 
-</html>
diff --git a/docs/dist/doc/README-153.html b/docs/dist/doc/README-153.html
deleted file mode 100644
index a10c65b6e..000000000
--- a/docs/dist/doc/README-153.html
+++ /dev/null
@@ -1,114 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 5 Development Kit v1.5.3 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2006 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 5 v1.5.3 Readme</h1>
-
-<p>This release includes a number of bug fixes and enhancements (over 80).  The full list of resolved issues can be found with 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.5.3&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">
-this bugzilla query</a>.
-</p>
-<p>
-Notable changes since the 1.5.2 release include:
-<br>
-
-<h2>Pipeline compilation - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=146781">146781</a></h2>
-<p>Until this release, the memory profile for AspectJ looked like this (time is along the X axis, memory usage is the Y axis)</p>
-
-<code><pre>
-     /\_
-    /   \_
-   /      \_
-  /         \_
- /            \_
-/               \
-</pre></code>
-<p>
-The first phase (as we go up and up and up) is the compilation of every file - when the peak is reached we then start weaving files one by one, discarding them once woven and dumped to disk.
-
-In 1.5.3 we don't compile everything up front - we compile and weave files one at a time.  Giving us this profile:
-</p>
-<code><pre>
-  /\  /\  /\
- /  \/  \/  \
-/            \
-</pre></code>
-<p>
-Each peak is compiling a file, then it is woven, dumped to disk and the space recovered (the trough) - we then move onto the next file.
-
-What does this mean?  The peaks are far far lower, so you need far less memory to compile a project.  For example, I have a 1000file project, affected by aspects at >750 join points.
-
-For given values of Xmx, here are the times taken to compile it (on the command line) with AspectJ1.5.2:</p>
-<pre><code>
-Xmx  Time
-512M 33seconds
-256M 40seconds
-220M 116seconds
-212M OutOfMemory
-</pre></code>
-
-<p>The times gradually increase as the memory is reduced because the VM starts to thrash in garbage collection.
-
-Here are the results for AspectJ1.5.3:</p>
-<pre><code>
-Xmx  Time
-512M 33s
-256M 33s
-180M 33s
-140M 33s
-100M 35s
-80M  43s
-70M  OutOfMemory
-</pre></code>
-
-<p>So with 1.5.3, it isn't until around 80M that the VM starts to struggle with memory.  These savings will affect any code built from source: on the command line, in Ant,
-or in AJDT.  It will not affect binary weaving - that is a future enhancement.</p>
-
-
-<h2>Serviceability - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150487">150487</a></h2>
-<p>As AspectJ grows in popularity, we find that it is becoming more difficult for users to come up with the small testcases
-that recreate problems - the usage scenarios for AJ are becoming more and more sophisticated.  To help us work on
-problems in these scenarios we have added a tracing and logging framework and improved our dump mechanism.  These traces and
-dumps can be attached to bug reports.  In AspectJ 1.5.3 we have included
-some <a href="http://www.eclipse.org/aspectj/doc/released/pdguide/index.html">documentation</a> on how to configure these new features.  Don't be surprised if you get asked
-for an AspectJ trace on a future bug report!
-</p>
-
-<h2>LTW enhancements</h2>
-
-<h3>User and System Configuration Files - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=149289">149289</a></h3>
-<p>The <code>-outxml</code> option now generates a file named <code>META-INF/aop-ajc.xml</code>.
-This no longer clashes with a user defined <code>META-INF/aop.xml</code> configuration file.
-Both file names along with an OSGi-friendly <code>org/aspectj/aop.xml</code> (which can also be
-signed) are used by default to configure LTW.</p>
-
-<h3>Weaving Concrete Aspects Defined in aop.xml - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=132080">132080</a></h3>
-<p>Concrete aspects defined using aop.xml are now exposed for weaving.</p>
- 
-<h2>Pertypewithin enhancement - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=123423">123423</a></h2>
-<p>It is now possible to ask an instance of a ptw aspect which type it is 'attached' to.  The method:</p>
- <code><pre>String getWithinTypeName()</pre></code>
- <p>can be called on an aspect and will return the full qualified name of the type (eg. "com.foo.MyClass")
-</p>
-
-<hr>
-<p>For information on bug fixes in AspectJ 5 v1.5.3, see the <a href="changes.html"> changes</a> document.</p>
-
-</body> 
-</html>
diff --git a/docs/dist/doc/README-154.html b/docs/dist/doc/README-154.html
deleted file mode 100644
index 2257a9c58..000000000
--- a/docs/dist/doc/README-154.html
+++ /dev/null
@@ -1,36 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 5 Development Kit v1.5.4 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2006 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 5 v1.5.4 Readme</h1>
-
-<p>This release includes a number of bug fixes and enhancements.  The full list of resolved issues can be found with 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.5.4&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">
-this bugzilla query</a>.
-</p>
-<p>
-Some key fixes include better handling of generic type declarations, both in regular Java classes and in combination with AspectJ constructs (for example, inter-type declarations)
-</p>
-<br>
-
-<hr>
-<!--p>For information on bug fixes in AspectJ 5 v1.5.4, see the <a href="changes.html"> changes</a> document.</p-->
-
-</body> 
-</html>
diff --git a/docs/dist/doc/README-160.html b/docs/dist/doc/README-160.html
deleted file mode 100644
index c190608a2..000000000
--- a/docs/dist/doc/README-160.html
+++ /dev/null
@@ -1,160 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 6 Development Kit v1.6.0 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2008 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ v1.6.0 Readme</h1>
-
-<h3>AspectJ v1.6.0 - 23 Apr 2008</h3>
-
-<p>For the complete list of every issue addressed since the last full release, see
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">this bugzilla link</a>.
-
-<p>Some of the highlights of 1.6.0 are:
-
-<h4>Upgrade to a Java 1.6 compiler</h4>
-<p>AspectJ1.6.0 upgrades the internal Eclipse compiler level to version 785_R33x - a Java 1.6 level compiler</p>
-
-<h4>Better incremental compilation support in the IDE</h4>
-<p>Changes under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427">bug 221427</a> mean that the compiler 
-is better able to maintain incremental state for projects in Eclipse and determine whether full builds or incremental
-builds are required when project dependencies change.  The result is that the compiler will more frequently do
-an incremental build rather than falling back to doing a full build.  Some basic performance findings can be seen in
-<a href="http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html">this mailing list post</a>.
-
-<h4>Parameter annotation matching</h4>
-<p>Parameter matching is possible for constructors and methods.  The use
-of parentheses around the parameter types in a method signature
-determine whether the annotations relate to the type of the parameter
-or the parameter itself.
-
-<pre><code>
-execution(* *(@A *));
-</code></pre>
-<p>- Execution of a method/ctor whose first parameter is of a type
-annotated with @A.
-
-<pre><code>
-execution(* *(@A (*)));
-</code></pre>
-<p>- Execution of a method/ctor whose first parameter is annotated with @A
-
-<pre><code>
-execution(* *(@A (@B *)))
-</code></pre>
-<p>- Execution of a method/ctor whose first parameter is annotated with
-@A and is of a type annotated with @B.
-
-Example:
-<pre><code>
------- Start of Test.java -----
-@interface A {}
-@interface B {}
-
-class C {
- public void foo(@A String s) {}
- public void goo(@A @B String s) {}
-}
-
-aspect X {
- before(): execution(* *(@A (*))) {}
- before(): execution(* *(@B (*))) {}
-}
------- End of Test.java -----
-$ ajc -showWeaveInfo -1.6 Test.java
-Join point 'method-execution(void C.foo(java.lang.String))' in Type 'C' (A.java:5) advised by before advice from 'X' (A.java:10)
-
-Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:11)
-
-Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:10)
-</code></pre>
-<p>The first piece of advice matched both methods.  The second only matched goo().
-<br><br>
-<h4>Annotation Value Matching</h4>
-
-<p>This allows static matching of the values of an annotation - if the matching is done statically at weave time, it is possible
-to avoid some of the reflection that is currently required within the advice (in some cases).  A typical use case is tracing where
-the trace level is defined by an annotation but may be switched OFF for a method if the annotation has a particular value.  Perhaps
-tracing has been turned on at the type level and a few critical methods should not get traced.  Here is some code showing the
-use case:
-<p>
-
-<pre><code>
-enum TraceLevel { NONE, LEVEL1, LEVEL2, LEVEL3 }
-
-@interface Trace {
-  TraceLevel value() default TraceLevel.LEVEL1;
-}
-  
-aspect X {
-  // Advise all methods marked @Trace except those with a tracelevel of none
-  before(): execution(@Trace !@Trace(TraceLevel.NONE) * *(..)) {
-    System.err.println("tracing "+thisJoinPoint);
-  }
-}
-
-public class ExampleOne {
-
-  public static void main(String[] args) {
-    ExampleOne eOne = new ExampleOne();
-    eOne.m001();
-    eOne.m002();
-    eOne.m003();
-    eOne.m004();
-    eOne.m005();
-    eOne.m006();
-    eOne.m007();
-  }
-
-  @Trace(TraceLevel.NONE)
-  public void m001() {}
-
-  @Trace(TraceLevel.LEVEL2)
-  public void m002() {} // gets advised
-
-  @Trace(TraceLevel.LEVEL3)
-  public void m003() {} // gets advised
-
-  @Trace(TraceLevel.NONE)
-  public void m004() {}
-
-  @Trace(TraceLevel.LEVEL2)
-  public void m005() {} // gets advised
-
-  @Trace(TraceLevel.NONE)
-  public void m006() {}
-
-  @Trace
-  public void m007() {} // gets advised
-
-}
-</pre></code>
-<p>Matching is currently allowed on all annotation value types *except* class and array. Also it is
-not currently supported for parameter annotation values.
-
-<h4>Changes since release candidate</h4>
-<p>The only fix 1.6.0 final includes beyond the release candidate is a multi-threading problem in the weaver - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029">bug 227029</a>.
-
-<h4>Releases leading up to AspectJ 1.6.0
-<p>AspectJ v1.6.0rc1- 16 Apr 2008</p>
-<p>AspectJ v1.6.0M2 - 26 Feb 2008</p>
-<p>AspectJ v1.6.0M1 - 16 Jan 2008</p>
-<hr>
-
-</body> 
-</html>
diff --git a/docs/dist/doc/README-161.html b/docs/dist/doc/README-161.html
deleted file mode 100644
index 857284eda..000000000
--- a/docs/dist/doc/README-161.html
+++ /dev/null
@@ -1,156 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2008 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.1 Readme</h1>
-
-<p>The main themes of AspectJ1.6.1 are better memory usage and faster weaving.
-This has been achieved through profiling of the weaving process and has
-resulted in some serious refactoring of the weaver component within AspectJ.  It provides
-exactly the same functionality as in previous releases, it just weaves faster now, using
-less code and less memory.  This readme will give an overview of the kind of changes
-made and what can be expected when using 1.6.1 compared to previous releases.</p>
-
-<p>The complete list of issues resolved for AspectJ 1.6.1 can be found with
-these bugzilla queries.  The first lists bugs addressed (more than 60!) whilst the second details
-enhancements made in this release.</p>
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_severity=enhancement&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Enhancements implemented</a>
-</ul>
-<hr>
-
-<h2>Refactored (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396">bug 231396</a>)</h2>
-
-<p>The bugzilla entry goes into more specifics on what has changed, the end result is that aspectjweaver.jar has had around 275 classes removed (about 25%) and 
-has slimmed down by 350k (about 20%).  In terms of performance for different scenarios:
-
-<h4>Straight compilation</h4>
-<p>The refactoring effort has been focused on the weaver component, hence there is limited impact on the performance of source compilation but this comparison shows it is faster.  Four scenarios are compared, in each scenario a different aspect
-is applied to the JDT compiler (just as a sample piece of source code).
-<ol>
-<li>1100 source files, few aspects that target 859 join points.
-<li>1100 source files, code style trace aspect targeting public methods (22000 join points)
-<li>1100 source files, annotation style trace aspect (22000 join points)
-<li>1100 source files, insane aspect (before(): within(*) {}) (203000 join points)
-</ol>
-<p>
-<center>
-<img src="perfSourceCompile_161.jpg"></img>
-</center>
-
-<h4>Binary weaving</h4>
-<p>Moving on from source compilation to pure binary weaving, the improvements are more obvious.  Here we are using the complete JVM 
-classes jar 'rt.jar' as an example of a large jar file for weaving.
-<ol>
-<li>Binary weaving rt.jar (~12000 classes) with a simple aspect (1200 join points)
-<li>Binary weaving rt.jar (~12000 classes) with a code style trace aspect (121000 join points)
-<li>Binary weaving rt.jar (~12000 classes) with an annotation style trace aspect (121000 join points)
-<li>Binary weaving rt.jar (~12000 classes) with an insane aspect (before(): within(*) {}) (352000 join points)
-</ol>
-<center>
-<img src="perfBinaryWeave_161.jpg"></img>
-</center>
-
-<h4>Loadtime weaving</h4>
-<p>The loadtime weaving improvements are similar to those seen for binary weaving (naturally).  Here we are using the JDK 
-tools jar 'tools.jar' as an example of a jar file for loadtime weaving.
-<ol>
-<li>Binary weaving tools.jar (~1900 classes) with a code style trace aspect
-<li>Binary weaving tools.jar (~1900 classes) with an insane aspect (before(): within(*) {})
-</ol>
-<center>
-<img src="perfLTW_161.jpg"></img>
-</center>
-<p>The refactoring work has also reduced the amount of unnecessary garbage created on the heap during the weaving process.  The next comparison shows roughly the
-reduction in amount of 'stuff' created on the heap during a weave.  This isn't the max heap required to do a weave, it is just showing how many less temporary objects
-are allocated during an entire run of the weaver
-<ol>
-<li>First, the number of kilobytes of memory allocated from the heap during a weave of tools.jar with a code style trace aspect
-<li>Second, another run of the same thing
-<li>Third, this time using the insane aspect
-</ol>
-<center>
-<img src="heapContents_161.jpg"></img>
-</center>
-<p>So in terms of memory required, weaving the insane aspect into tools.jar created 1.4G of 'stuff' over the entire weaving process, compared to 1.75G with 1.6.0.
-
-<h4>Loadtime weaving stress</h4>
-<p>As well as addressing the memory usage of a single load time weaver, we have also looked at the use of load time weaving in a larger
-scale scenario, where multiple classloaders are being instantiated and discarded over time and each has an associated load time weaver.
-Under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=210470">bug 210470</a> we looked in detail at whether the lifecycle of the
-weaver instance correctly matched the lifecycle of the associated classloader.  It did not, but now it does!
-
-Here is a memory usage graph for AspectJ1.6.1 - this shows an application that spawns 7 threads which run continuously for a few minutes.  Each thread
-repeatedly creates a classloader, weaves 500 classes using it then discards the classloader.  You can see that over time the memory is recovered
-correctly and when all threads complete (and all classloaders are orphaned), all the weavers are discarded.
-
-<p>First, AspectJ 1.6.0, in which memory was never correctly recovered and so an OutOfMemory problem would always occur eventually.
-<center>
-<img src="memLtwStress_160.jpg"></img>
-</center>
-<p>And now AspectJ 1.6.1:
-<center>
-<img src="memLtwStress_161.jpg"></img>
-</center>
-
-
-<h2>Incremental compilation</h2>
-<p>Following on from the work done to improve compilation under Eclipse in AspectJ 1.6.0 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427">Bug 221427</a>
-) - we now support the building of 'broken code' (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=102733">bug 102733</a>).  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.
-
-<h2>Language changes</h2>
-<h4>Optmized syntax for annotation value binding (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943">Bug234943</a>)</h4>
-<p>If only binding an annotation at a method-execution join point in order to access an <b>enum value</b>
-within it, there is a more optimal syntax that can be used to produce faster code.
-Given this setup:</p>
-<code><pre>
-enum Colour { RED,GREEN,BLUE;}
-
-@interface ColouredAnnotation { Colour value(); }
-
-@ColouredAnnotation(Colour.RED)
-public void colouredMethod() { }
-</pre></code>
-
-<p>Current syntax:</p>
-<pre><code>
-before(ColouredAnnotation anno): execution(* *(..)) && @annotation(anno) {
-  printTheColour(anno.value());
-}
-</pre></code>
-<p>New optional syntax:</p>
-<code><pre>
-before(Colour col): execution(* *(..)) && @annotation(ColouredAnnotation(col)) {
-  printTheColour(col);
-}
-</pre></code>
-
-<hr>
-
-
-<!-- ============================== -->
-  
-</body> </html>
diff --git a/docs/dist/doc/README-1610.html b/docs/dist/doc/README-1610.html
deleted file mode 100644
index 4e2fec3a2..000000000
--- a/docs/dist/doc/README-1610.html
+++ /dev/null
@@ -1,51 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.10 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2010 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.10 Readme</h1>
-
-<p>The full list of resolved issues in 1.6.10 is available <a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.10;target_milestone=1.6.10M1;target_milestone=1.6.10M2;target_milestone=1.6.10RC1">here</a></h2></p>
-
-<h2>Changes</h2>
-<p>1.6.10 is primilarily just bug fixes for AspectJ, mainly in the areas of ITDs and generic aspects.  However, there are a couple
-of important changes that users ought to be aware of:</p>
-<h3>AJDT Memory usage</h3>
-<p>Type demotion has been in use during loadtime weaving for a while now, this enables the load time weavers to discard state
-and recover it at a later time (and so generally run with a smaller memory footprint).  Type demotion is now supported under AJDT
-in Eclipse and will enable AJDT to run with smaller heaps.  This feature is still experimental and needs turning ON if you want
-to try it out.  To turn it on, open your AspectJ project properties in eclipse and in the AspectJ Compiler section, scroll down to 'Other' and
-in the non-standard compiler options setting, specify:</p>
-<pre><tt>-Xset:minimalModel=true,typeDemotion=true</tt></pre>
-<p>If I can get enough positive feedback about this option, it will be made the default.  For a more detailed write up, check out
-the blog post:
-<a href="http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html">
-http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html</a>
-</p>
-<h3>Runtime changes</h3>
-<p>A big thank you to Abraham Nevado and his team who have been working on some issues to optimize loadtime weaving and the
-code generated by AspectJ.  1.6.10 includes some new changes to the aspectjrt.jar.  The changes are new methods that enable
-the woven code to be a little shorter/neater.  As we want to continue to have compatibility with older aspectjrt.jar a user needs to
-choose to activate these optimizations by specifying the option:  <tt>-Xset:targetRuntime1_6_10=true</tt>.  With that option on
-you will need to ensure you run against the aspectjrt.jar from a 1.6.10 build.</p>
-<p>The changes are discussed in <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=323438">bug 323438</a></p>
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-1611.html b/docs/dist/doc/README-1611.html
deleted file mode 100644
index d75862d35..000000000
--- a/docs/dist/doc/README-1611.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.11 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2010-2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.11 Readme</h1>
-
-<p>The full list of resolved issues in 1.6.11 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.11;">here</a></h2>.</p>
-
-<h4>1.6.11 available 15-03-2011</h4>
-
-
-<h2>Notable Changes</h2>
-<h3>RC1 - Our own XML parser</h3>
-<p>Due to the way AspectJ loads one of the standard XML parsers (for processing aop.xml) it was possible to get into a deadlock situation.
-To avoid this completely we now have our own XML parser inside for processing this files.  It is basic but should support all the
-known syntax we have for aop files.  To use it instead of the default (if you are encountering the deadlock) you need to specify 
-this system property: <tt>org.aspectj.weaver.loadtime.configuration.lightxmlparser=true</tt>.
-</p>
-<hr>
-
-<h3>M2 - Multithreaded world access</h3>
-<p>The weaver is backed by a representation of types called a world.  Traditionally the worlds have supported single threads - and that
-is how they are used when doing compile time weaving or load time weaving.  However in some configurations, e.g. pointcut
-matching under Spring, a single world instance may be getting accessed by multiple threads at the same time.  Under 
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=337855">bug337855</a> some changes have been made to better support this kind
-of configuration.</p>
-
-<h3>M2 - various attribute deserialization issues</h3>
-<p>In 1.6.9 we made some radical changes to the serialized form.  It turns out some of the
-deserialization code wasn't handling these new forms quite right.  This would manifest as an IllegalStateException or
-IndexOutOfBoundsException or similar, during attribute unpacking.  These issues have now all been sorted out in 1.6.11.M2.</p>
-
-<h3>M2 - further optimizations in model for AJDT</h3>
-<p>More changes have been made for users trying out the <tt>-Xset:minimalModel=true</tt> option to try and reduce the memory used in
-their Eclipse/AJDT configurations. This option is discussed in detail <a href="http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html">here</a>.
-It now saves even more memory.  Also, previously the amount of memory it recovered depended on compilation order (which the user has no control over), but now
-it is insensitive to ordering and should always recover the same amount across builds of the same project.  With a bit more positive feedback on this option,
-it will become the default under AJDT.</p>
-
-<h3>M2 - spaces in path names can cause problems</h3>
-<p>AspectJ had problems if the paths it was being passed (e.g. aspectpath) included spaces.  
-This is bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=282379">282379</a> and has now been fixed.</p>
-
-<hr>
-
-<h3>M1 - Annotation removal</h3>
-<p>Traditionally AspectJ has taken an additive approach, where methods/fields/supertypes/annotations can only be added to types.
-Now, chaos would likely ensue if we allowed removal of supertypes, methods, etc, but we are seeing an increasing number of 
-requirements to do more with annotations.  What kinds of thing? Basically remove existing annotations, or modify existing
-annotations by changing their values.
-1.6.11 includes a new piece of syntax that we are thinking might be appropriate for one of these scenarios.  1.6.11 supports this:
-<pre><code>declare @field: int Foo.i: -@Anno;
-</code></pre>
-<p>Notice the '-' in front of the annotation, meaning 'removal'.  The whole construct means 'remove the @Anno annotation from the
-int field called i in type Foo'.  It is not yet supported on the other forms of declare @.
-
-<h3>M1 - Intertype innertypes</h3>
-<p>More work has gone into this feature.  It was originally added in 1.6.9 but the inability to use it with binary weaving
-greatly reduced the usefulness.  Fixes have gone into 1.6.11 to support binary weaving.  What do we mean by intertype innertypes?
-Here is an example:
-
-<pre><code>class Foo {
-  public void m() {
-    System.out.println(Inner.i);
-  }
-}
-
-aspect X {
-  public static class Foo.Inner {
-    static int i = 34;
-  }
-}
-</code></pre>
-<p>Only static inner types are supported.
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-1612.html b/docs/dist/doc/README-1612.html
deleted file mode 100644
index dc7c814c7..000000000
--- a/docs/dist/doc/README-1612.html
+++ /dev/null
@@ -1,214 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.12 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2010-2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.12 Readme</h1>
-
-<p>The full list of resolved issues in 1.6.12 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.12;">here</a></h2>.</p>
-
-<h4>1.6.12 released 18-Oct-2011</h4>
-<h4>1.6.12.RC1 available 3-Oct-2011</h4>
-<h4>1.6.12.M2 available 18-Aug-2011</h4>
-<h4>1.6.12.M1 available 7-Jun-2011</h4>
-
-<h2>Notable Changes</h2>
-
-<h3>RC1 - annotation value matching and !=</h3>
-<p>
-Prior to this change it was only possible to specify an annotation match like this:<br><br>
-<tt>get(@Anno(someValue=1) * *) || get(@Anno(someValue=3) * *)</tt><br>
-<p>Now it is possible to use != and write this:<br><br>
-<tt>get(@Anno(someValue!=2) * *)</tt><br>
-<p>This can enable a group of annotated elements to be more easily identified.<br>
-<br>
-
-
-<h3>RC1 - More flexible pointcut/code wiring in aop.xml</h3>
-<p>
-Prior to this version the wiring was quite limited.  In order to wire a pointcut to a piece of code the user
-needed to write an abstract aspect that included an abstract pointcut and some advice attached to that
-abstract pointcut.  Then compile this aspect and finally write the XML to concretize the abstract pointcut.  With 1.6.12
-more flexibility has been added and for some cases there can be no need for that abstract aspect.
-<p>This is a work in progress but now you can write this in the aop.xml:
-<pre><code>
-&lt;concrete-aspect name="MyAspect"&gt;
-  &lt;before pointcut="execution(* Hello.say2(..)) AND args(message)"
-   invokeClass="SomeRegularJavaClass" 
-   invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/&gt;
-  &lt;after pointcut="execution(* Hello.say2(..)) AND args(message)"
-   invokeClass="SomeRegularJavaClass" 
-   invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/&gt;
-&lt;/concrete-aspect&gt;
-
-public class SomeRegularJavaClass {
-
-  public static void someMethod(org.aspectj.lang.JoinPoint tjp, String s) {
-    System.out.println("in advice4: s="+s+" at "+tjp);
-  }
-  
-  public static void someOtherMethod(org.aspectj.lang.JoinPoint tjp, String s) {
-    System.out.println("in advice5: s="+s+" at "+tjp);
-  }
-}
-</code></pre>
-<p>In this example there is a simple regular java class containing some static methods.  In the XML these
-can be joined to pointcuts, kind as if they were advice.  Notice in the XML it specifies:
-<ul>
-<li>The pointcut
-<li>The <tt>invokeClass</tt> - the fully qualified name of the class containing the Java method
-<li>The <tt>invokeMethod</tt> - the method, including signature in the specified class.
-</ul>
-<p>
-Due to the method specification being in XML the parameter types must be fully specified.  The only
-exception to this rule is that the AspectJ core types JoinPoint (and JoinPoint.StaticPart) do not
-have to be fully qualified (see the example above).
-<b>Important:</b> notice that in the case above which does argument binding, the names are
-bound according to the XML specification, not according to the parameter names in the Java code.
-<p>Around advice is also supported (the return type of the method must match the joinpoint return
-type).  The example shows after advice, currently there is no way to specify either after returning
-or after finally, there is only after.
-<p>Expanding this further would enable support for all the code style features in the XML.  Some
-of the language features like declare annotation cannot be done in annotation style aspects but the
-XML doesn't have the same kind of restrictions.  If anyone wants to help out by fleshing this area
-of the weaver out, let me know and I'll help you get started!
-  
-<hr>
-<h3>M2 - thisAspectInstance (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649">bug239649</a>)</h3>
-<p>
-There is now a new well known name that you can use in the if clauses in your aspects.  <tt>thisAspectInstance</tt> provides access to the aspect instance.
-
-Here is an example:
-
-<code><pre>aspect X {
-  boolean doit() {
-    System.out.println("In instance check method doit()");
-    return true;
-  }
-
-  before():execution(* m(..)) && if(thisAspectInstance.doit()){
-    System.out.println(thisJoinPoint);
-  }
-}</pre></code>
-
-<p>Now why not just use <tt>X.aspectOf()</tt> instead of <tt>thisAspectInstance</tt>?  Well <tt>thisAspectInstance</tt> is quite useful 
-when working with abstract/concrete aspects:
-
-<code><pre>
-abstract aspect X {
-abstract pointcut p();
-
-boolean doit() {
-    return true;
-  }
-
-  before():p()  && if(thisAspectInstance.doit()){
-    System.out.println(thisJoinPoint);
-  }
-}
-
-aspect Y extends X {
-
-  pointcut p(): execution(* m(..));
-
-}</pre></code>
-
-<p>Now <tt>thisAspectInstance</tt> will be an instance of the Y, not X.
-
-It enables the aspect instance to be used in some kind of check/guard that will avoid the costly creation of a thisJoinPoint object if
-the advice isn't going to run.
-
-<b>Note:</b> right now this only works for singleton aspects.  If you have need of it with other instantiation models, please comment on
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649">https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649</a>
-</p>
-<h3>M2 - weaving groovy</h3>
-<p>
-Although we have been successfully weaving groovy for a long time, it is becoming more popular and a few issues have been uncovered
-when using non-singleton aspects with groovy code.  These have been fixed.
-</p>
-
-<h3>M2 - AJDT memory</h3>
-<p>
-The release notes for the last few versions of AspectJ have mentioned two options (minimalModel and typeDemotion) which can be
-switched on to reduce memory consumption.  They have had enough field testing now and from 1.6.12.M2 onwards they are on by default.
-Users should see a reduction in memory consumed by AspectJ projects in AJDT.  It won't affect load time weaving.  It may also help
-command line (or Ant) compile time weaving.  If these options cause a problem then please raise a bugzilla but in the interim you could
-work around the problem by actively turning them off by 
-specifying <tt>-Xset:minimalModel=false,typeDemotion=false</tt> in the project properties for your AspectJ project.
-</p>
-
-<h3>M2 - Java7 weaving support</h3>
-<p>Some preliminary work has been done to support Java7.  Java7 class files must contain the necessary extra verifier support attributes 
-in order to load successfully on a Java7 VM - the attributes were only optional in Java6.  It is possible to force loading of classes missing 
-the attributes but that requires use of a -XX option.  AspectJ 1.6.12.M2 should create these for you if you weave Java7 level class
-files.  Nothing has been done yet to rebase AspectJ on a version of the Eclipse compiler that supports Java7 language constructs - 
-that will happen after Eclipse 3.7.1 is out.
-</p>
-
-<hr>
-<h3>M1 - synthetic is supported in pointcut modifiers <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=327867">327867</a></h3>
-<p>It is now possible to specify synthetic in pointcuts:
-</p>
-<pre><code>pointcut p(): execution(!synthetic * *(..));
-</code></pre>
-
-<h3>M1 - respect protection domain when generating types during weaving <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=328099">328099</a></h3>
-<p>This enables us to weave signed jars correctly.  AspectJ sometimes generates closure classes during weaving and
-these must be defined with the same protection domain as the jar that gave rise to them.  In 1.6.12.M1 this should
-now work correctly.
-</p>
-
-<h3>M1 - Suppressions inline with the JDT compiler <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=335810">335810</a></h3>
-<p>Starting with Eclipse 3.6, the Eclipse compiler no longer suppresses raw type 
-warnings with @SuppressWarnings("unchecked"). You need to use 
-@SuppressWarnings("rawtypes") for that.  AspectJ has now been updated with this rule too.
-</p>
-
-<h3>M1 - Optimized annotation value binding for ints <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=347684">347684</a></h3>
-<p>The optimized annotation value binding now supports ints - this is for use when you want to match upon the existence of an annotation but
-you don't need the annotation, you just need a value from it. This code snippet shows an example:</p>
-<pre><code>@interface SomeAnnotation {
-  int i();
-}
-
-before(int i): execution(* *(..)) && @annotation(SomeAnnotation(i)) {
-</code></pre>
-<p>
-Binding values in this way will result in code that runs *much* faster than using pointcuts that 
-bind the annotation itself then pull out the value.
-</p>
-
-<p>Under that same bug some changes were made to match values by name when binding too.  Suppose the annotation
-had multiple int values, how would we select which int to bind?  AspectJ will now use the name (if it can) to select
-the right value:
-<pre><code>@interface SomeAnnotation {
-  int mods();
-  int flags();
-}
-
-before(int flags): execution(* *(..)) && @annotation(SomeAnnotation(flags)) {
-</code></pre>
-<p>Here the use of 'flags' as the name of the value being bound will ensure the 'flags' value from any SomeAnnotation is
-bound and not the 'mods' value.</p>
-
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-162.html b/docs/dist/doc/README-162.html
deleted file mode 100644
index e311c42c7..000000000
--- a/docs/dist/doc/README-162.html
+++ /dev/null
@@ -1,81 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2008 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.2 Readme</h1>
-
-<p>The main theme of AspectJ1.6.2 was improved IDE incremental performance and a number of changes
-have gone in to improve how AspectJ and AJDT communicate - greatly reducing the time taken 
-to perform an incremental compile (more details below).  1.6.2 also includes a number of fixes
-and enhancements covering areas such as:
-<ul>
-<li>better support for generics and intertype declarations
-<li>better support for annotation style syntax
-<li>improvements to ajdoc
-<li>bringing the AspectJ structure model more in line with the JDT model
-</ul>
-<p>Many thanks to all the users that helped diagnose problems, provide testcases and contribute fixes. In particular:
-<ul>
-<li>Dave Whittaker - for generics and intertype declaration testing and testcases
-<li>Jason Naylor, Arturo Salazar - for ajdoc testcases, fixes and design input
-<li>Andrew Eisenberg - for helping shape the AJDT/AspectJ interface and improving incremental
-</ul>
-
-<p>The complete list of issues resolved for AspectJ 1.6.2 (more than 60) can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.2&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-
-<hr>
-
-<h2>Incremental compilation (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=247742">bug 247742</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=245566">bug 245566</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=243376">bug 243376</a>)</h2>
-
-<p>Two main changes in this area.
-<ul>
-<li>Better communication between AJDT and AspectJ.  The interface between the two has been modified so that AJDT can give more input
-to AspectJ about what needs to be done for an incremental compile, rather than having AspectJ discover it each time.
-<li>Structure model changes.  The AspectJ structure model (of types in a project and the weaving amongst them) allows handles to be created
-for every node, as a lightweight reference to the elements of the model.  These handles were similar to those that JDT uses for references to
-elements of a project but not identical.  Many many fixes have gone in to bring the handle formats closer and closer.  For example including src folders
-as elements in the AspectJ model and using the fully correct set of JDT delimiters throughout each handle.  This means there is no longer an expensive 
-transformation cost in going from an AspectJ element to its related JDT element and no need for AJDT to maintain a more JDT like version of the
-AspectJ structure model.  The imminent development builds of AJDT will utilise these changes.
-</ul>
-
-<p><i>What difference does it make?</i>
-<p>For every kind of build there are two numbers to take into account.  Firstly there is the time spent in the compiler (time spent compiling and weaving), 
-secondly there is the time spent in AJDT (time spent communicating what happened back to the user via the problems view, gutter annotations).  Values
-for these times can be seen by opening the 'AJDT Event Trace View' in eclipse.  The changes within AspectJ obviously effect the time spent in the compiler
-and that is described as 'time spent in AJDE' within the event trace view (AJDE being the compiler wrapper invoked by AJDT).
-<p>For a 1000 source file AspectJ project, the times spent in AJDE have changed as follows for a single whitespace change and save operation:
-<ul>
-<li>For a sourcefile unaffected by aspects.  Was 1828ms, now 75ms.
-<li>For a sourcefile affected by some advice.  Was 1844ms, now 90ms.
-<li>For a sourcefile affected by lots of advice.  Was 1937ms, now 188ms.
-</ul>
-<p>The AspectJ changes are done to support this, but we are still bedding them down in AJDT.  If you want to see numbers like those above you need to 
-install the latest AJDT dev builds for Eclipse 3.4 (an AJDT 1.6.1 dev build from the dev update site: http://download.eclipse.org/tools/ajdt/34/dev/update ) 
-and then after starting Eclipse, select 'Window>Preferences' and in the AspectJ tab select 'Incremental Compiler Optimizations'.  Let us know how you get 
-on!  When it has had enough testing it will be made the default and then is likely to be back ported to Eclipse 3.3 AJDT.
-<p>
-<hr>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-163.adoc b/docs/dist/doc/README-163.adoc
index 74ca5e5a4..55835f3ee 100644
--- a/docs/dist/doc/README-163.adoc
+++ b/docs/dist/doc/README-163.adoc
@@ -9,8 +9,7 @@
 
 '''''
 
-[#split]##
-
+[[split]]
 === Split matching/weaving
 
 The main goal of AspectJ 1.6.3 was to make the line between matching and
@@ -43,8 +42,7 @@ and reflection based - both of which require compilation).
 
 '''''
 
-[#bugsfixed]##
-
+[[bugsfixed]]
 === Bugs fixed
 
 The complete list of issues resolved for AspectJ 1.6.3 (more than 50)
@@ -58,8 +56,7 @@ issues.
 
 '''''
 
-[#notable]##
-
+[[notable]]
 === Notable bug fixes
 
 * More improvements to the way AspectJ/AJDT communicate (251277, 249216,
@@ -74,8 +71,7 @@ type (256669)
 
 '''''
 
-[#whatsnext]##
-
+[[whatsnext]]
 === What's next?
 
 The JDT World should be completed in the 1.6.4 timeframe and that will
diff --git a/docs/dist/doc/README-163.html b/docs/dist/doc/README-163.html
deleted file mode 100644
index 253d5739f..000000000
--- a/docs/dist/doc/README-163.html
+++ /dev/null
@@ -1,84 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.3 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2008 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.3 Readme</h1>
-
-<ul>
-<li><a href="#split">Split matching/weaving</a></li>
-<li><a href="#bugsfixed">Bugs fixed</a></li>
-<li><a href="#notable">Notable bug fixes</a></li>
-<li><a href="#whatsnext">What's next?</a></li>
-</ul>
-<hr>
-<a name="split"/>
-<H4>Split matching/weaving</h4>
-<p>The main goal of AspectJ 1.6.3 was to make the line between matching and weaving more explicit and
-introduce the notion of a matcher artifact.  This matcher would enable reuse of the semantics of 
-AspectJ pointcut matching without including the unnecessary code that is the weaver.  Why?  In some
-environments, for example Spring AOP, the weaving may be done in an entirely different way and the 
-default weaver included in aspectjweaver.jar is just unnecessary code.  Some users also find they have trouble getting
-approval for using the 'aspectjweaver.jar' in their projects because it includes a bytecode 
-modification library, even when they are not using that code.
-<p>The result of this work is documented in <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125">bug 246125</a>
-and there is now a new jar file in the distribution called org.aspectj.matcher.jar that includes
-a first pass at the matching code.  It is not quite as slimmed down as it could be but is a first
-pass that includes no bytecode modification toolkit.
-<p>To use this matcher standalone it simply requires an abstraction of some type system to be plugged in.
-The matcher code can then be used to parse standard pointcuts and answer questions about whether they match against
-that type system.  There is no documentation on how to do this yet, as we don't think many users will 
-be contributing new type systems, but internally we are working on an Eclipse JDT type system abstraction that will
-enable us to show matches in AJDT without actually compiling code (currently the two type system abstractions
-we ship are bytecode based and reflection based - both of which require compilation).
-<hr>
-<a name="bugsfixed"/>
-<h4>Bugs fixed</h4>
-<p>The complete list of issues resolved for AspectJ 1.6.3 (more than 50) can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.3&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-<p>During 2008, there have been four AspectJ releases, fixing almost 200 issues.
-<hr>
-<a name="notable"/>
-<h4>Notable bug fixes</h4>
-
-<ul>
-<li>More improvements to the way AspectJ/AJDT communicate (251277, 249216, 258325)
-<li>More ajdoc improvements (256514)
-<li>Better support for non standard annotation style parameter ordering (164573, 219419)
-<li>Fixed long standing issue with extending Spring SecurityInterceptor (252722)
-<li>Ensure parameter annotations made on an ITD reach the target affected type (256669)
-</ul>
-
-<hr>
-<a name="whatsnext"/>
-<h4>What's next?</h4>
-
-<p>The JDT World should be completed in the 1.6.4 timeframe and that will surface as benefits in AJDT, possibly leading to better
-LTW tooling.  Some improved syntax for intertype declarations is a possible candidate feature (see discussion in 
-<a href="http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10208.html">this mailing list thread</a>).
-A possible introduction of a code style syntax for the mixin style that is @DeclareParents (and a renaming of 
-@DeclareParents to perhaps DeclareMixin or DeclareDelegate).
-
-<hr>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-164.adoc b/docs/dist/doc/README-164.adoc
index dd5deea5a..b1de0e9b0 100644
--- a/docs/dist/doc/README-164.adoc
+++ b/docs/dist/doc/README-164.adoc
@@ -9,8 +9,7 @@
 
 '''''
 
-[#compilation]##
-
+[[compilation]]
 === Compilation times
 
 In AspectJ 1.6.4 the goal was to improve the IDE experience, through a
@@ -122,8 +121,7 @@ http://andrewclement.blogspot.com/2009/02/aspectj-fixing-reverse-cascade-errors.
 
 '''''
 
-[#language]##
-
+[[language]]
 === Language Enhancements
 
 *Optimizing support for maintaining per join point state*
@@ -214,8 +212,7 @@ deprecated.
 
 '''''
 
-[#bugsfixed]##
-
+[[bugsfixed]]
 === Bugs fixed
 
 The complete list of issues resolved for AspectJ 1.6.4 (more than 70)
@@ -226,8 +223,7 @@ resolved]
 
 '''''
 
-[#whatsnext]##
-
+[[whatsnext]]
 === What's next?
 
 *More incremental build enhancements*
diff --git a/docs/dist/doc/README-164.html b/docs/dist/doc/README-164.html
deleted file mode 100644
index eadb5a8f5..000000000
--- a/docs/dist/doc/README-164.html
+++ /dev/null
@@ -1,204 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.4 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2009 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.4 Readme</h1>
-
-<ul>
-<li><a href="#compilation">Compilation times</a></li>
-<li><a href="#language">Language enhancements</a></li>
-<li><a href="#bugsfixed">Bugs fixed</a></li>
-<li><a href="#whatsnext">What's next?</a></li>
-</ul>
-<hr>
-<a name="compilation"/>
-<H4>Compilation times</h4>
-<p>In AspectJ 1.6.4 the goal was to improve the IDE experience, through a combination of improved compilation speed (both full 
-builds and incremental builds), improved support for multiple-project configurations, and improved feedback in the editor.  The
-following sections go into details on each of those topics.</p>
-
-<p><B>Full Compilation</b></p>
-<p>As an example project, all the measurements here are based on the modified JDT compiler that AspectJ uses internally.  It is 
-1100 source files and includes aspects that affect around 850 join points.  Here are the full build times in AJDT:
-</p>
-<p>AJDT 1.6.3 (uses AspectJ 1.6.3)</p>
-<code><pre>
-21352ms
-21597ms
-21502ms
-</pre></code>
-
-<p>AJDT 1.6.5dev builds (use AspectJ 1.6.4)</p>
-<code><pre>
-19811ms
-19802ms
-19504ms
-</pre></code>
-<p>
-About 1.5-2 seconds faster for this example.
-</p>
-<p><b>Incremental Compilation and multi-project scenarios</b></p>
-<p>In most common project configurations there are multiple eclipse projects in some kind of dependency hierarchy.  Depending on
-what changes in a top level project, those downstream may need to be rebuilt.  The analysis around this area has greatly improved
-in AspectJ 1.6.4, and this has resulted in much reduced incremental build times.  The example timed here is around 20 AspectJ
-projects in a hierarchy, and a change is made to a source file in the top level project and build times are observed for the
-downstream projects.</p>
-<p>The timings reported here are accessible to anyone with AJDT installed - just open the 'AJDT Event Trace View' and it will
-report ongoing information about what the compiler/weaver and AJDT are up to.  Be aware that data is only recorded in this view 
-if it is open - so for optimal performance it should be shutdown, but it is useful for debugging scenarios or collecting
-basic benchmark numbers.  Within the event trace view output, the time recorded for 'time spent in AJDE' represents the time
-spent in the compiler: analysing what has changed on the classpath, building code, weaving code.
-</p>
-<p>Initially this is using AJDT 1.6.2 (which embeds AspectJ 1.6.3):</p>
-<p>
-<code><pre>
-Type of change: adding a new method to a type
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-462ms, 4ms, 145ms, 8ms, 9ms, 287ms, 471ms, 222ms, 1028ms, 143ms, 505ms, 199ms, 261ms, 1224ms, 
-321ms, 704ms, 75ms, 233ms, 257ms
-Summary: Total time spent in the compiler for that change: <b>6558ms</b>
----
-Type of change: whitespace change (adding just a harmless space character)
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-229ms, 5ms, 10ms, 9ms, 10ms, 79ms, 43ms, 62ms, 80ms, 37ms, 64ms, 32ms, 79ms,
-154ms, 94ms, 189ms, 72ms, 144ms, 205ms
-Summary: Total time spent in the compiler for that change: <b>1597ms</b>
-</pre></code>
-</p>
-<p>Now with AspectJ 1.6.5 dev builds (which embed AspectJ 1.6.4):</p>
-<p>
-<code><pre>
-Type of change: adding a new method to a type
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-288ms, 3ms, 143ms, 2ms, 2ms, 162ms, 244ms, 89ms, 489ms, 113ms, 277ms, 108ms, 143ms, 626ms,
-135ms, 260ms, 2ms, 96ms, 6ms
-Summary: Total time spent in the compiler for that change: <b>3188ms</b> down from 6558ms
-
-Type of change: whitespace change (adding just a harmless space character)
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-101ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 2ms, 0ms, 1ms, 0ms, 2ms, 2ms
-Summary: Total time spent in the compiler for that change: <b>118ms</b> (down from 1597ms)
-</pre></code>
-</p>
-<p>
-Improvements all round, and almost instant builds now for whitespace changes, even in large
-project setups.
-</p>
-<p>In addition the compilation times are also improved in situations where AspectJ projects depend upon Java projects and
-where aspectpath is used.  AJDT 1.6.5 dev builds also include some changes that really speed up builds.
-</p>
-<h4>Better editor feedback</h4>
-<p>Under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=246393">bug 246393</a> the problem has been addressed where
-sometimes spurious errors would appear throughout the editor for a file in AJDT when just one single simple syntax errors exists.  More
-detail on this problem can be found 
-<a href="http://andrewclement.blogspot.com/2009/02/aspectj-fixing-reverse-cascade-errors.html">here</a>.
-</p>
-<hr>
-<a name="language"/>
-<H4>Language Enhancements</h4>
-<p><b>Optimizing support for maintaining per join point state</b></p>
-<p>The traditional way to maintain state on a per join point basis involves using the JoinPoint.StaticPart as a key
-into a map:
-<code><pre>
-aspect X pertypewithin(*) {
-  Map&lt;JoinPoint.StaticPart,Timer&gt; timerMap = ...
-  
-  Object around(): execution(public * *(..)) {
-    Timer timerToUse = timerMap.get(thisJoinPointStaticPart);
-    timerToUse.start();
-    Object o =  proceed();
-    timerToUse.stop();
-    return o;
-  }
-}
-</pre></code>
-<p>These map lookups are slow.  In AspectJ 1.6.4 there is a new getId() method on the JoinPoint.StaticPart object.
-The ids for all affected join points within a target type are unique (and start from 0) - they are ideal for
-array lookups.  So using this the above aspect can be rewritten:
-</p>
-
-<code><pre>
-aspect X pertypewithin(*) {
-  Timer[] timerArray = ...
-  
-  Object around(): execution(public * *(..)) {
-    Timer timerToUse = timerArray[thisJoinPointStaticPart.getId()];
-    timerToUse.start();
-    Object o =  proceed();
-    timerToUse.stop();
-    return o;
-  }
-}
-</pre></code>
-<p>much faster.  Just be aware that the ids are only unique within an affected target type - hence the use of pertypewithin 
-in this example to ensure there is an aspect instance (and so a different array) for each advised type.</p>
-<p>See related <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009">bug 89009</a> for the full discussion</p>
-
-<h4>@DeclareMixin</h4>
-<p>The annotation style declare parents support (@DeclareParents) has been (rightly) criticized because it really does not offer 
-an equivalent to what is possible with code style declare parents, it really offers a mixin strategy.  It also has limitations
-such as the delegate instance used to satisfy any method invocations on an affected target cannot access the object instance for 
-which it is acting as a delegate.  To address these concerns a proper mixin notation has been introduced that makes it more clear 
-that a mixin strategy is being employed and it addresses the problem of the mixin delegate accessing the affected target instance.
-</p>
-<p>
-The @DeclareMixin annotation is attached to a factory method which returns instances of the delegate.  Here is a basic example:
-</p>
-<code><pre>
-        // The factory method that can build the delegate instance is annotated with @DeclareMixin.
-        // The annotation value defines the type pattern for targets of the mixin.
-        // The parameter is the object for which a delegate is being constructed.
-        // The interface that will be mixed in is the return value of the factory method.
-        @DeclareMixin("org.xyz..*")
-        public static SomeInterface createDelegate(Object instance) {
-          return new SomeImplementation(instance);
-        }
-</pre></code>
-<p>More examples are <a href="http://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj-itds.html">here in the online
-documentation</a>.</p>
-<p>Going forward attempts will be made to try and make @DeclareParents behave more like code style - if this cannot
-be done it is likely to be deprecated.</p>
-<hr>
-<a name="bugsfixed"/>
-<h4>Bugs fixed</h4>
-<p>The complete list of issues resolved for AspectJ 1.6.4 (more than 70) can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.4&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-<hr>
-<a name="whatsnext"/>
-<h4>What's next?</h4>
-<p><b>More incremental build enhancements</b></p>
-<p>A number of situations still exist where incremental compile speeds still needs optimizing, particular when capabilities
-like aspectpath or inpath are used.</p>
-<p><b>Build state persistence</b></p>
-<p>Between restarts of Eclipse the state of each project is not recorded - hence full builds are required upon restart.  The 
-state (and associated relationship model) should be persisted between restarts, but both of these need a review first to ensure
-they are not larger than they need to be.
-</p>
-<p><b>Memory consumption</b</p>
-<p>Both for source compilation and load-time weaving scenarios.  The size of the model in the IDE needs reviewing, and also the
-type map within the weaver.  Although the type map uses Weak/Soft references to try and better control how it uses memory, the JVM
-policies for managing these references vary wildly and so some work needs to be done to allow for these differences.
-<hr>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-165.adoc b/docs/dist/doc/README-165.adoc
index 4d52fc0eb..6b67ccf97 100644
--- a/docs/dist/doc/README-165.adoc
+++ b/docs/dist/doc/README-165.adoc
@@ -2,8 +2,7 @@
 
 == AspectJ 1.6.5 Readme
 
-[#bugsfixed]##
-
+[[bugsfixed]]
 === Bugs fixed
 
 The complete list of issues resolved for AspectJ 1.6.5 can be found with
diff --git a/docs/dist/doc/README-165.html b/docs/dist/doc/README-165.html
deleted file mode 100644
index e7132edef..000000000
--- a/docs/dist/doc/README-165.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.5 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2009 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.5 Readme</h1>
-
-<a name="bugsfixed"/>
-<h4>Bugs fixed</h4>
-<p>The complete list of issues resolved for AspectJ 1.6.5 can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.5&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-<hr>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-166.adoc b/docs/dist/doc/README-166.adoc
index 9064cb793..b5de2009b 100644
--- a/docs/dist/doc/README-166.adoc
+++ b/docs/dist/doc/README-166.adoc
@@ -2,8 +2,7 @@
 
 == AspectJ 1.6.6 Readme
 
-[#bugsfixed]##
-
+[[bugsfixed]]
 === Bugs fixed
 
 The complete list of issues resolved for AspectJ 1.6.6 can be found with
diff --git a/docs/dist/doc/README-166.html b/docs/dist/doc/README-166.html
deleted file mode 100644
index 36b0ca156..000000000
--- a/docs/dist/doc/README-166.html
+++ /dev/null
@@ -1,105 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.6 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2009 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.6 Readme</h1>
-
-<a name="bugsfixed"/>
-<h4>Bugs fixed</h4>
-<p>The complete list of issues resolved for AspectJ 1.6.6 can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.6&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-<hr>
-<h2>Changes</h2>
-
-<p><b>Java5</b></p>
-<p>The features of Java5 (generics, autoboxing, covariance, etc) are being exploited in the AspectJ codebase.  This does not in
-any way change the generated code or supported source code, or the dependencies that code has, but it *does* mean that AspectJ 
-requires Java5 in order to run.  The ability to use typed collections has already flushed out a few issues within the codebase,
-improving the quality of AspectJ.</p>
-<!--
-<br>
-<p><b>Supporting aop.xml for batch or IDE compilation</b></p>
-<p>This is a new feature, not totally complete, but in a usable state.  The idea here is to make it easier for users to
-develop the aop.xml configuration files that will later be used for load-time weaving.  If these files are supported for configuring
-compile time weaving (batch or IDE) then they can be developed alongside the codebase against which they will be used.</p>
-<p>The work-in-progress enhancement is <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460">https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460</a>.
-AspectJ 1.6.6 supports the inclusion of xml files on the command line:</p>
-<pre><code>ajc Foo.aj -xmlConfigured myaop.xml</code></pre>
-<p>or through iajc.  Within the iajc task include a section like this:</p>
-<pre><code>&lt;inxml&gt;
-  &lt;pathelement="myaop.xml"/&gt;
-&lt;/inxml&gt;
-</code></pre>
-<p>The compiler does not yet support concrete-aspect definitions made in these xml files, but it should respect 
-include/exclude patterns.  It is a work in progress, please provide feedback!  Under AJDT there is a configuration page for aop.xml
-files to be included in a build under ProjectProperties>AspectJBuild>aop.xml management.  Incremental builds based on changes to 
-these files is not yet supported.  IMPORTANT: When switching to using aop.xml files to control compilation, the entire compiler for
-that project switches into the same mode as you would see when load-time weaving.  What does this mean?  It means aspects are 
-opt-in rather than opt-out - if you want an aspect to weave your code, you must define it in an aop.xml file.</p>
-
-<br>
-<p><b>Aspect scoping in aop.xml</b></p>
-<p>This is related to the previous topic.  When a user declares an aspect in an aop.xml they can now specify a scope where it
-should apply.  This enables the aspect developer to have some degree of control over where the aspect can be applied, in addition
-to what they may have captured in pointcuts within the defined aspect.</p>
-<p>Here is an example:</p>
-<pre><code>
-&lt;aspectj&gt;
-&lt;aspects&gt;
-  &lt;aspect name="A" scope="B*"/&gt;
-  &lt;!-- &lt;aspect name="A2"/&gt; --&gt;
-&lt;/aspects&gt;
-&lt;/aspectj&gt;
-</code></pre>
-<p>This XML defines the aspect A but limits where it can be applied to types matching the pattern B*.  It is still a work in
-progress so scopes are only supported at compile time right now, not load-time.  Any feedback appreciated.  Yes, it may look like
-just another way to specify the weaver section include/exclude patterns - but the intention of scope is that it would be set 
-by the aspect developer (aspect library provider) whilst the weaver section would be defined by the aspect consumer.</p>
--->
-<br>
-<p><b>Closing streams</b></p>
-<p>Some routes through AspectJ were leaving inputstreams open and this has now been fixed.  For example if supplying a user
-written configuration file for Lint options.  Thanks to Michael Pradel for supplying patches to fix these issues.</p>
-
-<br>
-<p><b>Concurrency (281654)</b></p>
-<p>Fix to address a problem seen when using the weaver in a highly concurrent environment.  Thanks to Kristian Rosenvold for
-the patch.</p>
-
-<br>
-<p><b>Incremental compilation</b></p>
-<p>A few fixes to problems seen only on incremental builds, problem areas included:</p><ul>
-<li>problems when fully qualifying the target type in an intertype declaration (269652)
-<li>problems when using annotation style pointcuts and reference pointcuts together (286341)
-</ul>
-
-<br>
-<p><b>JavadocRunner in NetBeans</b></p>
-<p>Fixed by a patch from Joseph A. Levin - thanks!</p>
-
-<br>
-<p><b>Various fixes/enhancements to the structure model to fix issues with feedback on weaving in AJDT</b></p>
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-167.adoc b/docs/dist/doc/README-167.adoc
index a6fea804f..66476f8cc 100644
--- a/docs/dist/doc/README-167.adoc
+++ b/docs/dist/doc/README-167.adoc
@@ -20,15 +20,15 @@ looks a little like this:
 
 ....
 Pointcut matching cost (total=6532ms for 675000 joinpoint match calls):
-Time:482ms (jps:#168585) matching against 
+Time:482ms (jps:#168585) matching against
     (staticinitialization(*y*.()) && persingleton(SimpleAspect))
-Time:3970ms (jps:#168585) matching against 
+Time:3970ms (jps:#168585) matching against
     (execution(* *t*.*(*)) && persingleton(SimpleAspect))
-Time:538ms (jps:#168584) matching against 
+Time:538ms (jps:#168584) matching against
     (execution(* *f*(..)) && persingleton(SimpleAspect))
-Time:1536ms (jps:#168584) matching against 
+Time:1536ms (jps:#168584) matching against
     (execution(* java.lang.CharSequence+.*e*(..)) && persingleton(SimpleAspect))
-Time:4ms (jps:#662) matching against 
+Time:4ms (jps:#662) matching against
     (within(*p*) && persingleton(SimpleAspect))
 ....
 
@@ -170,8 +170,7 @@ value.
 
 '''''
 
-[#bugsfixed]##
-
+[[bugsfixed]]
 ==== Bugs fixed
 
 The complete list of issues resolved for AspectJ 1.6.7 can be found with
diff --git a/docs/dist/doc/README-167.html b/docs/dist/doc/README-167.html
deleted file mode 100644
index 11c0737d1..000000000
--- a/docs/dist/doc/README-167.html
+++ /dev/null
@@ -1,165 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.7 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2009 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.7 Readme</h1>
-
-<p>AspectJ 1.6.7 includes some radical internal changes.  These improvements enable faster compilation, faster binary weaving,
-faster load time weaving and in some situations faster generated code.</p>
-
-<h2>Pointcut timers</h2>
-<p>Until 1.6.7 there has not really been a way to determine if it is just one of your pointcuts that is hurting your weaving
-performance.  In 1.6.7 it is possible to turn on timers for pointcuts.  These timers show
-the time spent in the weaver matching the pointcut components against join points.  The details on this feature are
-here: <a href="http://andrewclement.blogspot.com/2009/11/aspectj-profiling-pointcut-matching.html">Profiling pointcut
-matching</a>.  Basically by turning on the options '-timers -verbose' on the command line (or via Ant), output will be produced
-that looks a little like this:
-
-<pre><code>
-Pointcut matching cost (total=6532ms for 675000 joinpoint match calls):
-Time:482ms (jps:#168585) matching against 
-    (staticinitialization(*y*.()) && persingleton(SimpleAspect))
-Time:3970ms (jps:#168585) matching against 
-    (execution(* *t*.*(*)) && persingleton(SimpleAspect))
-Time:538ms (jps:#168584) matching against 
-    (execution(* *f*(..)) && persingleton(SimpleAspect))
-Time:1536ms (jps:#168584) matching against 
-    (execution(* java.lang.CharSequence+.*e*(..)) && persingleton(SimpleAspect))
-Time:4ms (jps:#662) matching against 
-    (within(*p*) && persingleton(SimpleAspect))
-</code></pre>
-
-<p>It shows the component, the number of joinpoints (jps) the weaver attempted to match it against and how many milliseconds were 
-spent performing those matches.  The options can also be turned on 
-<a href="http://contraptionsforprogramming.blogspot.com/2009/11/getting-aspectj-pointcut-matching-timer.html"/>through AJDT</a>.
-Armed with this information you can optimize your pointcuts or post on the mailing list asking for help.  The timers can even be 
-turned on for load time weaving.  </p>
-
-
-<h2>Faster matching</h2>
-
-<p>The changes to enable pointcut profiling enabled some targeted work to be done on the matching algorithms.  These
-have remained unchanged for a few years, but in 1.6.7 have received a bit of an overhaul.  'Fast match' has
-been implemented for the execution() pointcut, drastically reducing weave times for heavy users of execution - more details
-<a href="http://andrewclement.blogspot.com/2009/11/aspectj-how-much-faster-is-aspectj-167.html">here</a>.  The pointcut cost
-calculator (which is used to sort pointcuts to optimize matching speed) has been reviewed and after determining that 
-this() ought to be considered cheaper than call() - any user combining those two pointcut designators should see an improvement 
-(one users build time reduced from 38minutes to 6minutes with that change!).</p>
-
-<p>As well as faster matching there is also less exploration to determine a match.  Visitors that walk hierarchies and discover
-methods  now terminate as early as possible once they can determine something is a match or is definetly not a match.  This reduces 
-memory usage, speeds up weaving and reduces the occurrences of those annoying 'cantFindType' messages.</p>
-
-<h2>aop.xml processing</h2>
-
-<p>The processing of include/exclude entries in aop.xml has been rewritten.  It now optimizes for many more common patterns.  If
-a pattern is optimized then there is no need to ask the weaver to do an expensive include/exclude match.  More details
-<a href="http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html">here</a>.
-
-<h2>Less need to tweak options for load time weaving</h2>
-
-<p>A number of options were previously configurable for load time weaving that were considered experimental.  These options 
-have now been tested enough in the field that they are considered fully reliable and are on by default in 1.6.7.  If you have
-been using either of these:
-<ul>
-<li>typeDemotion
-<li>runMinimalMemory
-</ul>
-<p>then please delete them from your weaver options section, the weaver will now do the right thing out of the box.</p>
-
-<h2>Benchmarking memory and performance</h2>
-
-<p>All those changes above, and some additional tweaks, mean we are now using less memory than ever before and getting
-things done more quickly.</p>
-<p><a href="http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html">This post</a> discusses
-the details.  From that article, the graph below shows the speed and memory consumption of the
-various AspectJ 1.6 releases when load time weaving a small application loading in Tomcat.  For each of 10 iterations (x axis), 
-the top comparison is startup time in
-milliseconds, the lower comparison is memory used in bytes.</p>
-<p><img src="167Memory.png" align="center"/></p>
-
-<h2>Annotation binding</h2>
-
-<p>All those changes affect compilation/weaving but what about the code that actually runs?  One user, Oliver Hoff, raised
-a query on the performance of annotation binding.  His case uncovered an old TODO left in the code a few years ago:</p>
-<code><pre>// OPTIMIZE cache result of getDeclaredMethod and getAnnotation?</pre></code>
-
-<p>Annotation binding has become a very common use case since that was written and 1.6.7 was the time TODO it.</p>
-
-<p>The result is an optimization for the general case of binding an annotation, but also support for a new bit of syntax
-that aids binding of a string annotation member value - using this latter syntax generates extremely fast code.</p>
-
-<p>Here are some numbers for a simple benchmark retrieving the annotation value at an execution join point
-in different ways.  The three scenarios look like this (where the annotation type is 'Marker' and it has a String value field 
-called 'message'):</p>
-
-<code><pre>
-  // CaseOne: annotation value fetching is done in the advice:
-  pointcut adviceRetrievesAnnotation(): execution(@Marker * runOne(..));
-  before(): adviceRetrievesAnnotation() {
-    Marker marker = (Marker) ((MethodSignature)
-        thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Marker.class);
-    String s = marker.message();
-  }
-
-  // CaseTwo: annotation binding is done in the pointcut, advice retrieves message
-  pointcut pointcutBindsAnnotation(Marker l): execution(@Marker * runTwo(..)) && @annotation(l);
-  before(Marker l): pointcutBindsAnnotation(l) {
-    String s = l.message();
-  }
-
-  // CaseThree: annotation binding directly targets the message value in the annotation
-  pointcut pointcutBindsAnnotationValue(String msg):
-    execution(@Marker * runThree(..)) && @annotation(Marker(msg));
-  before(String s): pointcutBindsAnnotationValue(s) {
-    // already got the string
-  }
-</pre></code>
-
-<p>Before 1.6.7, case 2 was slower than case 1 and case 3 wasn't supported syntax.  The two bugs with more info are
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484">Bug 296484</a> and 
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=296501">Bug 296501</a>.</p>
-
-<p>Now this is a micro benchmark, slightly unrepresentative of the real world because the advice isn't doing anything
-else, but it does really stress the AspectJ binding code.  For the benchmark numbers the join points advised by those advice 
-were invoked 1,000,000 times. AspectJ 1.6.7:</p>
-
-<code><pre>
-Manually fetching annotation with getAnnotation(): 645ms
-Binding annotation with @annotation(Marker): 445ms  (was >20 *seconds* for 1.6.6, due to an extra reflection call)
-Binding annotation value with @annotation(Marker(message)): 3ms
-</pre></code>
-
-<p>The new syntax is definetly the best way to bind an annotation string value.</p>
-
-<hr>
-
-<a name="bugsfixed"/>
-<h4>Bugs fixed</h4>
-<p>The complete list of issues resolved for AspectJ 1.6.7 can be found with
-this bugzilla query:
-<ul>
-<li><a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.7&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">Bugs resolved</a>
-</ul>
-<hr>
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-168.html b/docs/dist/doc/README-168.html
deleted file mode 100644
index e15d52cd1..000000000
--- a/docs/dist/doc/README-168.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.8 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2009 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.8 Readme</h1>
-
-<p>The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some radical internal changes.'</p>
-<p>Unfortunately not enough testing was done on 1.6.7 and two nasty issues were found that really needed addressing. Fixes for
-these issues are all that is new in 1.6.8.</p>
-
-<h2>Incorrect treatment of some aop.xml include/exclude patterns</h2>
-
-<p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786">Bug 298786</a></p>
-<p>Basically, if a certain combination of includes and excludes were specified in the within section, then the weaver 
-would fail to merge them correctly.  The conditions for the failure are: </p>
-<ul>
-<li>you need an exclude pattern that the weaver is not optimizing for (basically a pattern that could not be matched based upon
-the typename alone, eg. based on whether the type has an annotation)
-<li>you need two include patterns - one that is being optimized and one that is not
-</ul>
-<p>
-These three meet that spec:</p>
-<code><pre>
-    &lt;include within="*"/&gt;
-    &lt;include within="@Foo *"/&gt;
-    &lt;exclude within="*Funk*y*"/&gt;
-</pre></code>
-
-<p>The include="*" can be optimized.  The include="@Foo *" is not optimized.  The exclude="*Funk*y*" is not
-optimized (this one could be but isn't right now as it includes multiple wildcards).</p>
-
-<p>With that configuration any types that the include="*" would have accepted are
-not accepted.</p>
-
-<h2>Stack overflow problem in ReferenceType.isAssignableFrom()</h2>
-
-<p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908">Bug 298908</a></p>
-<p>This is actually a problem AspectJ has had for a long time, but has always proved elusive to recreate.  It turns out
-that it is memory related and the more aggressive policy in 1.6.7 causes it to occur much more frequently.</p>
-
-<p>The stack trace when this is hit looks like:</p>
-
-<code><pre>
-	...
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-	at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-	...
-</pre></code>
-
-<p>The weaver has changed over the 1.5 and 1.6 releases and is now reaching a point where it really shrinks quite
-small when not in use (maybe in a loadtime environment you have finished loading all your classes).  The aim is that
-it can rebuild any required state that is needed later.  With the move in 1.6.7 from Soft to Weak references, things are 
-being discarded much sooner and this is exercising the state rebuilding code that wasn't used that often prior to 1.6.7.</p>
-
-<p>The problem is actually because the call on a generic type to get the raw type was actually broken
-and returning the generic type.  This then loops forever trying to get the raw type from the generic type.  This happens because
-the world should store only raw types (which point to their generic form) but there was a bug in state rebuilding that instead
-put the generic type directly in the world.</p>
-
-<hr>
-Thanks to everyone who helped get to the bottom of these problems.
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-169.html b/docs/dist/doc/README-169.html
deleted file mode 100644
index f8ac87302..000000000
--- a/docs/dist/doc/README-169.html
+++ /dev/null
@@ -1,245 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.6.9 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2010 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.6.9 Readme</h1>
-
-<p>The full list of resolved issues in 1.6.9 is available <a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.9;target_milestone=1.6.9M1;target_milestone=1.6.9M2;target_milestone=1.6.9RC1">here</a></h2>
-
-<h2>Features</h2>
-
-<h3>declare annotation supports compound signature patterns: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=287613">287613</a></h3>
-<p>Until now it wasn't possible to express a compound pattern in any of the declare annotation constructs that
-take a member signature.  For example, if you wanted to attach an annotation to all your getter like methods, you needed
-two constructs</p>
-<pre><code>
-declare @method: * is*(): @FooBar;
-declare @method: * get*(): @FooBar;
-</code></pre>
-<p>Now AspectJ allows compound patterns for declare @method/@constructor/@field.</p>
-<pre><code>
-declare @method: (* is*()) || (* get*()): @FooBar;
-</code></pre>
-
-<h3>Intertype declaration of member types</h3>
-
-<p>It is now possible to ITD member types.  The syntax is as would be expected.  This example introduces a new member type called
-Inner into type Foo:</p>
-<pre><code>public class Foo {
-	public static void main(String[] args) {
-		new Inner().run();
-	}
-}
-
-aspect Magic {
-	public static class Foo.Inner {
-		public void run() {
-			System.out.println("Inner.run() executing");
-		}
-	}
-}</code></pre>
-<p>Only static member types are supported.</p>
-
-<h3>'Optional' aspects: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=310506">310506</a></h3>
-
-<p>It is not uncommon to ship a library aspect separately to a jar upon which it depends.  In the case of Spring there is
-an aspect library containing a multitude of aspects that attach different technologies (transactions/persistence/etc) to your
-application.  Normally an aspect will fail with a "can't find type" style message if a weaver is told to use it and yet it
-references some missing dependency.  This can be annoying and require you to include jars on your classpath (or in your maven
-configuration) that you don't actually use, they are *only* there to avoid problems with the aspect.  In 1.6.9 you can add
-a setting to these aspects in the aop.xml that makes them optional.  The setting mentions a type and if that type cannot be found
-the aspect immediately shuts itself down.  This basically means that the aspect is only going to do its job if the type being
-mentioned in the setting is around.  This enables the aspect library to be on the aspect path but any aspects within it to 
-switch-off if there is nothing for them to do.
-</p>
-<p>Here is an example, 'AspectA' will switch itself off if the type 'a.b.c.Anno' cannot be found:</p>
-<code><pre>
- &lt;aspect name="AspectA" requires="a.b.c.Anno"/&gt;
-</pre></code>
-
-<h3>Reduction in class file sizes: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=312839">312839</a></h3>
-
-<p>More details here: <a href="http://andrewclement.blogspot.com/2010/05/aspectj-size-is-important.html">http://andrewclement.blogspot.com/2010/05/aspectj-size-is-important.html</a>
-but basically some work has been done to improve the serialized form of aspects.  As an example, a compiled Roo petclinic sample (which
-uses lots of aspects and ITDs) is down from 1Meg (AspectJ 1.6.9m2) to 630k (AspectJ 1.6.9rc1).</p>
-
-<h3>Transparent weaving: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743">309743</a></h3>
-<p>In a further step towards transparent weaving, support for the AjType reflection system is now being made optional.
-This means if intending to use the AjTypeSystem to reflect on woven code, then the code must be built with the 
-option -makeAjReflectable. This change is being made because the reflection supporting metadata that 
-enables the AjTypeSystem to work can break other tools that are just using regular reflection on the classes.  These 
-days many more users are processing classes using standard reflection than are using AjTypeSystem.  The related bugzilla
-discussing this issue is <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743">309743</a>.</p>
-
-<h3>Overweaving: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450">293450</a></h3>
-
-<p>Preliminary support for overweaving was added in AspectJ 1.6.7, but now in AspectJ 1.6.9m2 it is much more reliable.
-Basically it is an alternative to reweaving when needing to weave a class multiple times.  Overweaving can cope with
-'other tools' modifying the bytecode in between AspectJ weaves, whereas reweaving cannot.  More details are in the related
-bugzilla <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450">293450</a> and in this 
-<a href="http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html">blog article</a>.  A weaver is switched
-into overweaving mode by the option -Xset:overWeaving=true - which can be specified on the command line or in the weaver
-options section of aop.xml.  There is still more work to be done on this feature - any feedback is welcome.</p>
-
-<h3>AOP Scoping: <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460">124460</a></h3>
-
-<p>Another feature that had preliminary support a while ago is aspect scoping in aop.xml.  This has also been improved in 
-AspectJ1.6.9m2.  For those not aware of it, it is the ability to specify a scope against aspects defined in your loadtime
-weaving aop.xml file.  A scope effectively enables the user to limit the applicability of your aspect to some subset of all those 
-types included by the weaver include section.  Why is it needed?  It can be useful when taking an aspect that did not
-originally scope itself properly (using a within clause) and needing to limit its effect in a load time weaving context. 
- Think of it as a within
-pattern that you can put into the aop.xml that augments all the pointcuts defined in the original aspect.</p>
-
-<p>Here is an example:</p>
-<code><pre>
-&lt;aspectj&gt;
-  &lt;aspects&gt;
-    &lt;aspect name="X"/&gt;
-    &lt;aspect name="Y" scope="com.foo..*"/&gt;
-  &lt;/aspects&gt;
-  &lt;weaver&gt;
-    &lt;include within="com..*"/&gt;
-  &lt;/weaver&gt;
-&lt;/aspectj&gt;
-</pre></code>
-<p>In this example the weaver include section specifies all the types in com..* should be woven and the 
-aspects to be used are X and Y.  The new 'scope' setting on aspect Y's definition allows finer control, and specifies that
-Y should in fact only be applied to com.foo..* types.</p>
-
-<h3>Message inserts for declare warning/error messages</h3>
-
-<p>It is now possible to use joinpoint context in the messages attached to declare warning and declare error constructs.  Some
-examples:</p>
-
-<code><pre>
-declare warning: execution(* A.m(..)): "joinpoint is {joinpoint}";
-declare warning: execution(* A.m(..)): "joinpoint kind is '{joinpoint.kind}'";
-declare warning: get(int *) && within(A): "joinpoint signature is {joinpoint.signature}";
-declare warning: execution(* A.m(..)): "joinpoint declaring type is {joinpoint.signature.declaringType}";
-declare warning: execution(* A.m(..)): "signature name for method is {joinpoint.signature.name}";
-declare warning: execution(* A.m(..)): "joinpoint location is {joinpoint.sourcelocation.sourcefile}:{joinpoint.sourcelocation.line}";
-declare warning: execution(* A.m(..)): "joinpoint line is '{joinpoint.sourcelocation.line}'";
-
-declare warning: get(int *): "warning is from aspect {advice.aspecttype}";
-declare warning: execution(* A.m(..)): "warning sourcelocation is {advice.sourcelocation.sourcefile}:{advice.sourcelocation.line}";
-</pre></code>
-
-<p>The syntax is to enclose the relevant key within curly brackets within the message.  Please raise an enhancement request 
-if you need other keys - the set supported so far are all those shown in the example above.</p>
-
-
-<h3>declare warning/error for type patterns</h3>
-
-<p>It is now possible to use a type pattern with declare warning and declare error.  For example:</p>
-
-<code><pre>
-declare warning: I+ && !hasfield(int i): "Implementations of I are expected to have a int field called i";
-</pre></code>
-
-<h3>Type category type patterns</h3>
-
-<p>This is the ability to narrow the types of interest so that interfaces can be ignored, or inner
-types, or classes or aspects.  There is now a new is() construct that enables this:</p>
-
-<code><pre>
-execution(* (!is(InnerType)).m(..)) {}
-!within(* && is(InnerType)) {}
-</pre></code>
-
-<p>Options for use in is() are: ClassType, AspectType, InterfaceType, InnerType, AnonymousType, EnumType, AnonymousType.</p>
-<p>Note: It is important to understand that "!within(is(InnerType))" and "within(!is(InnerType))" are not the same.  The latter one is
-unlikely to be what you want to use.  For example here:
-<code><pre>
-class Boo {
-  void foo() {}
-  class Bar {
-    void foo() {}
-  }
-}
-</pre></code>
-<p>Bar.foo() will match within(!is(InnerType)) because within considers all surrounding types (so although Bar doesn't match the
-pattern, the surrounding Boo will match it).  Bar.foo() will not match !within(is(InnerType)) because Bar will match the pattern
-and then the result of that match will be negated.</p>
-
-<h3>Intertype fields preserve visibility and name</h3>
-
-<p>Some users always expect this:</p>
-
-<code><pre>
-class C {
-}
-
-aspect X {
-  private int C.someField;
-}
-</pre></code>
-
-<p>To cause a private field called 'someField' to be added to C.  This is conceptually what happens during compilation but if any
-user then later attempts to access someField via reflection or runs a javap against the class file, they will see that isn't
-what happens in practice.  A public member is added with a mangled name.  For code attempting to access someField built with ajc,
-the visibility of the declaration will, of course, be respected.  But for frameworks accessing the code later (typically through
-reflection), it can cause confusion.  With AspectJ 1.6.9 the name and visibility are now preserved.  Compile time semantics
-remain the same, it is only the weaving process that has changed to produce slightly different output.</p>
-<p>Here is the output of javap when that is built with 1.6.8:</p>
-<code><pre>
-class C extends java.lang.Object{
-    public int ajc$interField$X$someField;
-    C();
-}
-</pre></code>
-<p>Here is the output of javap when that is built with 1.6.9:</p>
-<code><pre>
-class C extends java.lang.Object{
-    private int someField;
-    C();
-    public static int ajc$get$someField(C);
-    public static void ajc$set$someField(C, int);
-}
-</pre></code>
-<p>The name 'someField' is preserved.  The visibility is also preserved but because of that we also need to generate some accessors
-to get at the field.</p> 
-
-<h3>AspectJ snapshots in a maven repo</h3>
-
-<p>To ease how AspectJ development builds can be consumed, they are now placed into a maven repo.  When a new version of AspectJ
-is put into AJDT it is also put into the maven.springframework.org repo.  
-The maven compatible repo is <code>maven.springframework.org/snapshot/org/aspectj</code> - and if you browse to it you will 
-see it currently contains 1.6.9 dev builds under the name 1.6.9.BUILD-SNAPSHOT.
-
-The repo is added with this magic:</p>
-
-<code><pre>
-&lt;repository&gt;
-    &lt;id&gt;maven.springframework.org&lt;/id&gt;
-    &lt;name&gt;SpringSource snapshots&lt;/name&gt;
-    &lt;url&gt;http://maven.springframework.org/snapshot&lt;/url&gt;
-&lt;/repository&gt;
-</pre></code>
-<p>
-and then the version to depend upon is:
-
-1.6.9.BUILD-SNAPSHOT</p>
-
- <hr>
-
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-170.html b/docs/dist/doc/README-170.html
deleted file mode 100644
index 13b1f6fba..000000000
--- a/docs/dist/doc/README-170.html
+++ /dev/null
@@ -1,122 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.7.0 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.7.0 Readme</h1>
-
-<p>The full list of resolved issues in 1.7.0 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.0;">here</a></h2>.</p>
-
-<ul>
-<li>1.7.0 available 2-Jul-2012
-<li>1.7.0.RC1 available 25-May-2012
-<li>1.7.0.M1 available 16-Dec-2011
-</ul>
-
-<h2>Notable Changes</h2>
-
-<h3>Java 7 bytecode weaving</h3>
-<p>The first milestone of 1.7.0 upgraded the compiler but this still left the weaver with some issues 
-if it had to weave into bytecode containing some of the new features that were allowed by Java 1.7.
-In particular this meant any bytecode containing the INVOKEDYNAMIC (new instruction for 1.7) and 
-the related new constant pool entry types that support it.  RC1 now supports weaving into bytecode
-containing these features.  However, the new INVOKEDYNAMIC instruction does not surface as a join
-point yet so you cannot write a pointcut to match on it. If you use execution() pointcuts
-as opposed to call() then you will still be able to advise what the invokedynamic actually calls.
-</p>
-<h3>Bytecode caching for loadtime weaving</h3>
-<p>Under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=367673">bug 367673</a> we have had
-a contribution (thanks John Kew!) that enables a bytecode cache for loadtime weaving.  The
-details and some rudimentary benchmark numbers are in the bug.  Basically it caches woven 
-bytecode on first start of a system
-using LTW and then reuses that woven bytecode on subsequent starts - this saves weaving time
-and also memory consumption.  To activate it, use the following system properties:</p>
-<pre><code>-Daj.weaving.cache.enabled=true
--Daj.weaving.cache.dir=/tmp/aspectj-cache/
-</code></pre>
-
-<h3>Upgrade to Java 7</h3>
-<p>
-For AspectJ 1.7.0, AspectJ moved from Eclipse JDT Core 0.785_R33x (Eclipse 3.3) to Eclipse JDT Core 0.B79_R37x (Eclipse 3.7).
-This is a big change where AspectJ is picking up four years of change from the Eclipse compiler.
-</p>
-<p>
-It means that you can now use the new Java 7 language constructs in your programs:</p>
-<p>
-- Diamond operator in advice:
-<code><pre>
-aspect Foo {
-  before(): execution(* *(..)) {
-    List<String> ls = new ArrayList<>();
-  }
-}
-</pre></code>
-<p>
-- Diamond operator in ITD:
-<code><pre>
-public List<String> DiamondITD.ls = new ArrayList<>();
-</pre></code>
-<p>
-- Underscore literals and binary literals in advice:
-<code><pre>
-  before(): execution(* *(..)) {
-    int onemill = 1_000_000;
-    int four =0b100;
-  }
-</pre></code>
-<p>
-- Multi-catch:<code><pre>
-before(): execution(* main(..)) {
-    try {
-      foo("abc");
-    } catch (ExceptionA | ExceptionB ex) {
-      bar(ex);
-    }
-}
-</pre></code>
-<p>
-- String switch:<code><pre>
- before(String s): execution(* *(..)) && args(s) {
-   switch(s) {
-     case "quux":
-       foo();
-       break;
-     case "bar":
-       foo();
-       break;
-     default:
-       foo();
-       break;
-   }
- }
-</pre></code>
-<p>
-- Try with resources:<code><pre>
-   try (
-     InputStream in = new FileInputStream(src);
-     OutputStream out = new FileOutputStream(dest))
-   {
-     // code
-   }
-</pre></code>
-</p>
-<h4>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-171.html b/docs/dist/doc/README-171.html
deleted file mode 100644
index 3fb9b2550..000000000
--- a/docs/dist/doc/README-171.html
+++ /dev/null
@@ -1,45 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.7.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.7.1 Readme</h1>
-
-<p>The full list of resolved issues in 1.7.1 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.1;">here</a></h2>.</p>
-
-<ul>
-<li>1.7.1 available 6-Sep-2012
-</ul>
-
-<h2>Changes</h2>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=388971">388971</a> Double Synthetic attributes on some around advice members<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=387718">387718</a> RuntimeException when trying to compile broken code<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=387568">387568</a> Warning "Xlint:unresolvableMember" for enums<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=387444">387444</a> Softening exception in try-with-resources<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=386888">386888</a> spring-data hello-worlds sample fails to compile with 1.7.0<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=386337">386337</a> Light AOP Parser does not support declare-annotation<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=386049">386049</a> Error "must implement abstract inter-type declaration" even though build is fine<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=384401">384401</a> NPE when no pointcut in afterthrowing annotation style advice<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=384398">384398</a> Type Mismatch error when using inner classes contained in generic types within ITDs<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=381906">381906</a> ASPECTJ Internal Compiler Error<br>
-<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=73507">73507</a> Public ITD of fields on interfaces creates mangled members<br>
-</p>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-172.html b/docs/dist/doc/README-172.html
deleted file mode 100644
index b73c37bdf..000000000
--- a/docs/dist/doc/README-172.html
+++ /dev/null
@@ -1,42 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.7.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.7.2 Readme</h1>
-
-<p>The full list of resolved issues in 1.7.2 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.2;">here</a></h2>.</p>
-
-<ul>
-<li>1.7.2 available 13-Feb-2013
-</ul>
-
-<h3>Fixes:</h3>
-<ul>
-<li>Incorrect signature attributes generated into some class files for complex generics declarations.
-<li>Generics information incorrectly being placed in the stackmap verification attributes.
-<li>Problems with generic ITDs not being picked up correctly, resulting in 'method must be implemented' errors.
-<li>Problems with multiple usages of 'requires' clause in aop.xml for conditional aspects.
-<li>Generated if() pointcut representations in class files change on only a source whitespace change.
-<li>Intermittent problem with generic ITDs due to weak references being collected too soon.
-</ul>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-173.html b/docs/dist/doc/README-173.html
deleted file mode 100644
index b9b7b8638..000000000
--- a/docs/dist/doc/README-173.html
+++ /dev/null
@@ -1,30 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.7.3 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2011 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.7.3 Readme</h1>
-
-<p>Available 13-Jun-2013</p>
-
-<p>The list of resolved issues in 1.7.3 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.3;">here</a></h2>.</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-174.html b/docs/dist/doc/README-174.html
deleted file mode 100644
index d0eacf06a..000000000
--- a/docs/dist/doc/README-174.html
+++ /dev/null
@@ -1,50 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.7.4 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2013 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.7.4 Readme</h1>
-
-<p>Available 24-Oct-2013</p>
-
-<p>The list of resolved issues in 1.7.4 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.4;">here</a></h2>.</p>
-
-<b>Notes</b>
-<ul>
-<li>This release includes an important fix for using loadtime weaving in a JVM where JMX is turned on (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=415266">415266</a>)
-<p>
-<li>There are some new message insert keys usable in declare error/warning (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=420210">420210</a>)
-The new keys are:
-<tt>
-<pre>
-joinpoint.enclosingclass // Bar
-joinpoint.enclosingmember // void Bar.foo(String)
-joinpoint.enclosingmember.name // foo
-</pre>
-</tt>
-All keys are case insensitive.
-<p>
-<li>It is now possible to specify individual xlint settings without needing to supply a file (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=419279">419279</a>)
-<tt><pre>ajc -Xlint:adviceDidNotMatch=error,noGuardForLazyTjp=ignore Foo.java</pre></tt> 
-</ul>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-180.html b/docs/dist/doc/README-180.html
deleted file mode 100644
index 4c2f52486..000000000
--- a/docs/dist/doc/README-180.html
+++ /dev/null
@@ -1,92 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.0 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2014 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.0 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.0 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.0.M1;target_milestone=1.8.0;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.0 available 17-Apr-2014
-<li>1.8.0.RC1 available 18-Mar-2014
-<li>1.8.0.M1 available 29-Jul-2013
-</ul>
-
-<h2>Notable changes</h2>
-
-<h3>Java 8 compilation</h3>
-
-<p>AspectJ has been updated to the latest available Eclipse Java
-compiler version that compiles Java8 code (the version available as a feature patch on top of Eclipse 4.3.2).</p>
-</p>
-<p>Here is a sample AspectJ8 program:</p>
-
-<pre><code>
-=== 8< ==== C.java ==== 8< ===
-import java.util.Arrays;
-
-interface I {
-    // Default method
-    default void foo() {
-        System.out.println("ABC");
-    }
-}
-
-public class C implements I{
-    public static void main(String[] args) {
-        new C().foo();
-        // Lambda
-        Runnable r = () -> { System.out.println("hello world!"); };
-        r.run();
-        // Used Java8 b97
-        Arrays.asList(MyClass.doSomething()).forEach((p) -> System.out.println(p));
-    }
-}
-
-aspect X {
-	before(): execution(* I.foo()) {
-   		System.out.println("I.foo running");
-	}
-	before(): staticinitialization(!X) {
-		System.out.println("Clazz "+thisJoinPointStaticPart);
-	}
-}
-
-
-class Utils {
-    public static int compareByLength(String in, String out) {
-        return in.length() - out.length();
-    }
-}
-
-class MyClass {
-    public static String[] doSomething() {
-        String []args = new String[]{"4444","333","22","1"};
-        // Method reference
-        Arrays.sort(args,Utils::compareByLength);
-        return args;
-    }
-}
-=== 8< ==== C.java ==== 8< ===
-</code></pre>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-181.html b/docs/dist/doc/README-181.html
deleted file mode 100644
index b217dfda7..000000000
--- a/docs/dist/doc/README-181.html
+++ /dev/null
@@ -1,39 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2014 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.1 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.1 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.1;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.1 available 20-Jun-2014
-</ul>
-
-<h2>Notable changes</h2>
-
-<h3>Java 8 update</h3>
-
-<p>As Eclipse itself nears the 4.4 release, AspectJ has been updated to the latest Eclipse JDT Core
-that will be included in it, picking up numerous Java8 related fixes.</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-1810.html b/docs/dist/doc/README-1810.html
deleted file mode 100644
index 73e88069b..000000000
--- a/docs/dist/doc/README-1810.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.10 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2016 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.10 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.10 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.10;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.10 available 9-Dec-2016
-</ul>
-
-<h2>Notable changes</h2>
-
-<h4>JDT Upgrade</h4>
-<p>The JDT compiler inside AspectJ has been upgraded to the Eclipse Neon.2 level (JDT commit #75dbfad0).</p>
-
-<h4>Java8</h4>
-<p>The Eclipse JDT compiler embedded inside AspectJ now requires Java 8, so that is the minimum required level to compile sources with AspectJ. 
-However, if only doing weaving and no compilation then it is possible to use Java 7.
-
-<h4>Annotation style around advice and proceed (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=500035">Bug 500035</a>)</h4>
-<p>A long standing issue that has been lurking in the handling of arguments passed to proceed for annotation style
-aspects has been fixed. If, at a joinpoint where 'this'/'target' differ (for example at some call joinpoints), the pointcut
-bound either 'this' or 'target' (but not both), then the system would still expect the advice to pass both 'this' and 'target' into the proceed
-call. With the fix here you only need to pass what you bind. So if you bind only 'this' you don't need to pass 'target' (and vice versa).
-This will affect users that have been working around this quirk by passing both 'this' and 'target'. That isn't necessary anymore.
-This fix is in aspectjrt.jar so you will need to be using the 1.8.10 version of aspectjrt.jar at runtime to pickup this change.
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-1811.html b/docs/dist/doc/README-1811.html
deleted file mode 100644
index e4ca44ee5..000000000
--- a/docs/dist/doc/README-1811.html
+++ /dev/null
@@ -1,38 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.11 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2017 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.11 Readme</h1>
-
-<p>This release is a small compatibility release to improve the behaviour of the AspectJ 1.8
-line on JDK9. Importantly it includes a change that knows about the Java 9 version information
-and so does not get confused and think it is running on something really old (which typically
-manifests as it complaining about annotations not being supported on this level of Java).</p>
-
-<p>With that change this release is usable for Spring AOP use cases because that is doing
-runtime pointcut matching with proxy creation rather than actual weaving. Although if you
-using Spring AOP with class level annotation retention there may still be issues. If you
-experience problems or need to do actual weaving on JDK9, please use AspectJ9 instead.</p>
-
-<ul>
-<li>1.8.11 available 26-Sep-2017
-</ul>
-
-</body>
-</html>
diff --git a/docs/dist/doc/README-182.html b/docs/dist/doc/README-182.html
deleted file mode 100644
index 22930df89..000000000
--- a/docs/dist/doc/README-182.html
+++ /dev/null
@@ -1,157 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2014 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.2 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.2 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.2;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.2 available 14-Aug-2014
-</ul>
-
-<h2>Notable changes</h2>
-
-<p>Although only a few bugs have been fixed here, they are quite important ones:</p>
-
-<h3>Update to more recent Eclipse Compiler</h3>
-
-<p>AspectJ is now based on a more up to date Eclipse compiler level (git hash 2b07958) so includes all the latest fixes</p>
-
-<h3>Correct handling of RuntimeInvisibleTypeAnnotations (type annotations without runtime visibility)</h3>
-
-<p>For anyone weaving code containing these kind of type annotations, this is an important fix. Although AspectJ does not currently
-support pointcuts matching on these kinds of annotation it was crashing when they were encountered. That is now fixed.</p>
-
-<h3>Annotation processing</h3>
-
-<p>A very long standing issue, the AspectJ compiler now supports annotation processors thanks to some work by Sergey Stupin.</p>
-
-<p>Here is a short example, a very basic annotation and application:</p>
-
-<h4>Marker.java</h4>
-<code><pre>
-import java.lang.annotation.Retention;
-import java.lang.annotation.RetentionPolicy;
-
-@Retention(RetentionPolicy.RUNTIME)
-public @interface Marker { }
-</pre></code>
-
-<h4>Code.java</h4>
-<code><pre>
-public class Code {
-
-  public static void main(String []argv) {
-    new Code().moo();
-    new Code().boo();
-    new Code().too();
-    new Code().woo();
-  }
-
-  public void moo() {}
-	
-  @Marker
-  public void boo() {}
-	
-  @Marker
-  public void too() {}
-	
-  public void woo() {}
-}
-</pre></code>
-
-<p>And now a basic annotation processor. This processor will find methods in the source marked with the annotation <tt>Marker</tt> and for 
-each one generate an aspect tailored to advising that method (this *is* a contrived demo!)</p>
-
-<h4>DemoProcessor.java</h4>
-<code><pre>
-import java.io.*;
-import javax.tools.*;
-import java.util.*;
-import javax.annotation.processing.*;
-import javax.lang.model.*;
-import javax.lang.model.element.*;
-
-@SupportedAnnotationTypes(value= {"*"})
-@SupportedSourceVersion(SourceVersion.RELEASE_6)
-public class DemoProcessor extends AbstractProcessor { 
-
-  private Filer filer;
-
-  @Override
-  public void init(ProcessingEnvironment env) {
-    filer = env.getFiler();
-  }
-
-  @Override
-  public boolean process(Set elements, RoundEnvironment env) {
-    // Discover anything marked with @Marker
-    for (Element element: env.getElementsAnnotatedWith(Marker.class)) {
-      if (element.getKind() == ElementKind.METHOD) {
-        // For any methods we find, create an aspect:
-        String methodName = element.getSimpleName().toString();
-        String aspectText = 
-            "public aspect Advise_"+methodName+" {\n"+
-            "  before(): execution(* "+methodName+"(..)) {\n"+
-            "    System.out.println(\""+methodName+" running\");\n"+
-            "  }\n"+
-            "}\n";
-        try {
-          JavaFileObject file = filer.createSourceFile("Advise_"+methodName, element);
-          file.openWriter().append(aspectText).close();
-          System.out.println("Generated aspect to advise "+element.getSimpleName());
-        } catch (IOException ioe) {
-          // already creates message can appear if processor runs more than once
-          if (!ioe.getMessage().contains("already created")) {
-            ioe.printStackTrace();
-          }
-        }
-      }
-    }
-    return true;
-  }
-}
-</pre></code>
-
-<p>With those sources, we compile the processor:</p>
-<code><pre>ajc -1.6 DemoProcessor.java Marker.java</pre></code>
-
-<p>Now compile the code with the processor specified:</p>
-<code><pre>ajc -1.6 -processor DemoProcessor -showWeaveInfo Code.java Marker.java</pre></code>
-<code><pre>
-Generated aspect to advise too
-Generated aspect to advise boo
-Join point 'method-execution(void Code.boo())' in Type 'Code' (Code.java:14) advised by before advice from 'Advise_boo' (Advise_boo.java:2)
-Join point 'method-execution(void Code.too())' in Type 'Code' (Code.java:17) advised by before advice from 'Advise_too' (Advise_too.java:2)
-</pre></code>
-
-<p>Notice the processor generates the aspects and then they are woven into the code being compiled immediately.</p>
-
-<p>Finally we can run it:</p>
-<code><pre>java Code
-boo running
-too running
-</pre></code>
-
-<p><b>Note:</b> There is still work to be done to get annotation processors behaving under AJDT.
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-183.html b/docs/dist/doc/README-183.html
deleted file mode 100644
index 5b97481d8..000000000
--- a/docs/dist/doc/README-183.html
+++ /dev/null
@@ -1,114 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.3 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2014 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.3 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.3 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.3;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.3 available 22-Oct-2014
-</ul>
-
-<h2>Notable changes</h2>
-
-<h3>Conditional aspect activation with <tt>@RequiredTypes</tt> - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=436653">Issue 436653</a></h3>
-
-<p>AspectJ is sometimes used to create aspect libraries. These libraries contain a number of aspects often covering
-a variety of domains. The library might typically be available as a jar and contains a single aop.xml file that
-names all the aspects. The library is then consumed by some application. 
-However, the application may not need to use all those aspects
-but because they are listed in the aop.xml they will be 'active'. Now the pointcuts in those unused aspects
-may not match anything in the application and could be considered harmless but the pointcuts and the aspects
-themselves may have references to types in other libraries that the application does not have around. This can lead
-to unhelpful <tt>"can't find type"</tt> messages and currently requires the user to add unnecessary entries to their
-build dependencies just to keep the unused aspects happy.
-</p>
-<p>With AspectJ 1.8.3 it is now possible to express a constraint on an aspect. The <tt>@RequiredTypes</tt>
-annotation specifies one or more fully qualified types that must be discoverable on the classpath in
-order for the aspect to activate. Using this there is no need to add those extraneous dependencies to
-an applications build classpath.
-</p>
-<p>Example:</p>
-<pre><code>import org.aspectj.lang.annotation.*;
-
-@RequiredTypes("com.foo.Bar")
-public aspect Foo {
-  before(): execution(@com.foo.Bar * *(..)) {}
-}
-</code></pre>
-
-<p>
-If the above aspect is listed in an aop.xml for loadtime weaving or passed on the aspectpath for
-compile time weaving, if the type <tt>'com.foo.Bar'</tt> is not accessible on the classpath then the
-aspect will be turned off and the pointcut will have no effect. There will be no attempt made to
-match it and so no unhelpful <tt>"can't find type"</tt> messages.
-</p>
-
-<h3>cflow and the pre-initialization joinpoint changes due to Java 7 verifier modifications - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=443477">Issue 443477</a></h3>
-
-<p>There has been a change in the Java7 verifier in a recent patch release of Java7 (update 67) that causes
-a verify error for usage of a particular AspectJ construct. The problem occurs if you are using
-cflow and it hits the preinitialization join point. The pattern of code generated in that case causes
-the verifyerror. In this release of AspectJ we have taken the 'quick' approach to solving this, namely
-to avoid advising preinitialization with the cflow construct. This problem appears to come up
-when the aspect is non-optimal anyway and hitting preinitialization was never really intended by the 
-pointcut writer. For example:
-
-<pre><code>execution(* foo(..)) && cflow(within(Bar))</code></pre>
-
-<p>The use of cflow and within there will actually hit *a lot* of joinpoints, many of which the user probably didn't mean to.
-It feels like we actually need a warning to indicate the pointcut is probably suboptimal. What the user probably
-meant was something more like this:</p>
-
-<pre><code>execution(* foo(..)) && cflow(execution(* Bar.*(..))</code></pre>
-<p>or</p>
-<pre><code>execution(* foo(..)) && cflow(within(Bar) && execution(* *(..)))</code></pre>
-
-<p>
-But even if they did want the less optimal form of cflow there still seems little use in applying it to
-pre-initialization - that is your cue to raise an AspectJ bug with a realistic use case inside that proves this
-an invalid assumption :)</p>
-
-<h3>around advice and lambdas - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=445395">Issue 445395</a></h3>
-
-<p>For optimal performance, where possible, AspectJ tries to inline around advice when it applies
-at a joinpoint. There are few characteristics of a joinpoint match that can prevent this but we
-do try to inline where we can (the inlining can be manually turned off via <tt>-XnoInline</tt>).</p>
-
-<p>Inlining of around advice basically means copying the advice instructions into the target class. This causes
-a problem when the advice uses lambdas. Lambda usage is currently implemented in java compilers by generating
-invokedynamic bytecode instructions that reference bootstrap methods created in the class and a helper method
-generated in the class containing the lambda code. When the invokedynamic is encountered at runtime, some magic
-happens and the bootstrap method is used to generate a class on the fly that calls the particular lambda method.
-All this 'extra stuff' breaks the basic inlining algorithm that simply copies the advice bytecode into the target.
-Effectively the inlining process needs to become much more sophisticated and copy the bootstrap methods and
-the lambda helper methods, avoiding clashes with existing bootstrap/helpers in the target.</p>
-
-<p>
-Prior to AspectJ 1.8.3 when the inlining failed you would get a horrible class cast exception that mentions
-constant pool entries (because the bootstrap method hadn't been copied over to the target). Temporarily in
-1.8.3 we are turning off inlining of around advice containing lambdas, which will at least avoid the failure,
-with the longer term goal of improving the inlining process to do all the necessary extra work.
-</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-184.html b/docs/dist/doc/README-184.html
deleted file mode 100644
index 056a500f8..000000000
--- a/docs/dist/doc/README-184.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.4 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2014 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.4 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.4 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.4;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.4 available 6-Nov-2014
-</ul>
-
-<h2>Notable changes</h2>
-
-<h3>Support for is(FinalType)</h3>
-
-<p>AspectJ has had type category type patterns since version 1.6.9, see the <a href="https://www.eclipse.org/aspectj/doc/released/README-169.html">README</a>. This enabled
-pointcuts to include is(..) clauses to specify which kinds of type they were or were not interested in matching, e.g. <tt>!within(* && is(InnerType))</tt> means not within innertypes.
-In 1.8.4 it is now possible to recognize (for inclusion or exclusion) final types with <tt>is(FinalType)</tt>.
-
-<h3>thisAspectInstance correctly handled with -1.8</h3>
-
-<p>This is the key fix in this release. Some products based on AspectJ were using the thisAspectInstance feature 
-(see <a href="https://www.eclipse.org/aspectj/doc/released/README-1612.html">README 1.6.12</a> for more info on the feature). Unfortunately if specifying -1.8 compliance
-and using the feature an error would be reported at compile time of the aspect. This is now fixed.</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-185.html b/docs/dist/doc/README-185.html
deleted file mode 100644
index b7c47b95e..000000000
--- a/docs/dist/doc/README-185.html
+++ /dev/null
@@ -1,36 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.5 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2015 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.5 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.5 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.5;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.5 available 28-Jan-2015
-</ul>
-
-<h2>Notable changes</h2>
-
-<p>The most important fixes in 1.8.5 are JDT compiler fixes that it includes (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=455277">455277</a>,<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=458660">458660</a>).</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-186.html b/docs/dist/doc/README-186.html
deleted file mode 100644
index e9d57f5f8..000000000
--- a/docs/dist/doc/README-186.html
+++ /dev/null
@@ -1,36 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.6 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2015 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.6 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.6 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.6;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.6 available 5-Jun-2015
-</ul>
-
-<!--
-<h2>Notable changes</h2>
--->
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-187.html b/docs/dist/doc/README-187.html
deleted file mode 100644
index 1d9b28c24..000000000
--- a/docs/dist/doc/README-187.html
+++ /dev/null
@@ -1,133 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.7 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2015 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.7 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.7 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.7;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.7 available 9-Sep-2015
-</ul>
-
-
-<h2>Notable changes</h2>
-
-<h3>ajdoc</h3>
-<p>The ajdoc tool has been fixed! It is now working again if run on a 1.7 JDK.</p>
-
-<h3>Dynamic weaver attachment</h3>
-<p>The AspectJ loadtime weaving agent can now be dynamically attached to a JVM after it has started 
-(you don't need to use -javaagent). This offers extra flexibility but obviously any
-classes loaded before attachment will not be woven.</p>
-
-<p>Here is a simple aspect:</p>
-<code><pre>
-public aspect Azpect {
-  before(): execution(* *(..)) {
-    System.out.println(thisJoinPointStaticPart);
-  }
-}
-</pre></code>
-
-<p>Compiled via:</p>
-
-<code><pre>ajc -1.8 Azpect.java -outxml</pre></code>
-
-<p>This produces a compiled class <tt>Azpect.class</tt> and a file <tt>META-INF/aop-ajc.xml</tt>.</p>
-
-<p>I then have this sample application (same directory):</p>
-
-<code><pre>
-import java.lang.management.ManagementFactory;
-import org.aspectj.weaver.loadtime.Agent;
-import com.sun.tools.attach.VirtualMachine;
-
-public class Application {
-
-  public static void main(String[] args) {
-    if (!isAspectJAgentLoaded())
-      System.err.println("WARNING: AspectJ weaving agent not loaded");
-    new Sample().doSomething();
-  }
-
-  public static boolean isAspectJAgentLoaded() {
-    try {
-      Agent.getInstrumentation();
-    } catch (NoClassDefFoundError e) {
-      System.out.println(e);
-      return false;
-    } catch (UnsupportedOperationException e) {
-      System.out.println(e);
-      return dynamicallyLoadAspectJAgent();
-    }
-    return true;
-  }
-
-  public static boolean dynamicallyLoadAspectJAgent() {
-    String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
-    int p = nameOfRunningVM.indexOf('@');
-    String pid = nameOfRunningVM.substring(0, p);
-    try {
-      VirtualMachine vm = VirtualMachine.attach(pid);
-      String jarFilePath = System.getProperty("AGENT_PATH");
-      vm.loadAgent(jarFilePath);
-      vm.detach();
-    } catch (Exception e) {
-      System.out.println(e);
-      return false;
-    }
-    return true;
-  }
-}
-</pre></code>
-
-<p>And this Sample class:</p>
-<code><pre>
-public class Sample {
-	public void doSomething() {
-		System.out.println("Do something");
-		System.out.println("Square of 7 = " + square(7));
-	}
-
-	private int square(int i) {
-		return i * i;
-	}
-}
-</pre></code>
-
-<p>Compile these with javac, <b>but you must have the aspectjweaver and the JDK tools.jar on your classpath</b>.</p>
-
-<p>Once compiled we can run it:</p>
-
-<code><pre>java -DAGENT_PATH=&lt;path-to&gt;/aspectjweaver.jar Application</pre></code>
-
-<p>What does it do? The main method calls the function that detects whether the agent is attached, if it is not then
-it programmatically attaches it using the <tt>VirtualMachine</tt> class. Then the main method accesses the
-Sample class. At this point in program execution the Sample class is loaded and because the agent has been
-attached it gets woven. Notice that the <tt>Application</tt> class itself is not woven because it was loaded prior
-to agent attachment.</p>
-
-<p>Thanks to Alexander Kriegisch for the sample code and the patch to add this behaviour to AspectJ.</p>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-188.html b/docs/dist/doc/README-188.html
deleted file mode 100644
index 1c7bc1768..000000000
--- a/docs/dist/doc/README-188.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.8 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2016 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.8 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.8 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.8;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.8 available 7-Jan-2016
-</ul>
-
-<h2>Notable changes</h2>
-
-<h3>Around advice on default methods</h3>
-<p>In previous releases attempting to apply around advice to default methods would
-create methods with rogue modifiers in the interface declaring the default method (loading
-these interfaces would then result in a verifier error).
-This has now been fixed.</p>
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-189.html b/docs/dist/doc/README-189.html
deleted file mode 100644
index b03e50ed3..000000000
--- a/docs/dist/doc/README-189.html
+++ /dev/null
@@ -1,35 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.8.9 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2016 Contributors.
-All rights reserved.
-</small></div>
-
-<h1>AspectJ 1.8.9 Readme</h1>
-
-<p>The full list of resolved issues in 1.8.9 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.9;">here</a></h2>.</p>
-
-<ul>
-<li>1.8.9 available 14-Mar-2016
-</ul>
-
-<h2>Notable changes</h2>
-
-<p>The JDT compiler inside AspectJ has been upgraded to the Eclipse Mars.2 level (commit #a7bba8b1).</p>
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-190.html b/docs/dist/doc/README-190.html
deleted file mode 100644
index 1d7759019..000000000
--- a/docs/dist/doc/README-190.html
+++ /dev/null
@@ -1,325 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.0 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2018 Contributors.
-All rights reserved.
-</small></div>
-<p>The full list of resolved issues in 1.9.0 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.0">here</a></h2>.</p>
-
-<h1>AspectJ 1.9.0</h1>
-
-<h4>Improved runtime interface</h4>
-<p>New factory methods have been added to the AspectJ runtime. This is an attempt to more optimally create <tt>thisJoinPoint</tt> and
-<tt>thisEnclosingJoinPoint</tt> objects. The generated code that invokes these now also uses the ability 
-for the LDC bytecode instruction to load class constants directly (this replaces what was happening
-previously where generated code referenced string classnames and classloading was being done from the
-aspectj runtime as the woven application was starting).</p>
-
-<p>This is turned on by using <tt>-Xajruntimetarget:1.9</tt>. This option was used previously to enable
-users to target an old runtime if they knew that old runtime is all that was available at some deployed target.
-The new generation mechanism is not the default, not until it has had a bit more testing out in the wild.</p>
-
-<p>The changes to generated code have a couple of potential side effects:
-<ul>
-<li><b>overall size</b>: the woven code may be smaller due to the use of smaller string constant pieces in the generated
-code (previously strings were smashed together in the generated code and then taken apart by AspectJ at runtime).
-Since the pieces are smaller, they can be shared across other uses in the class file.
-<li><b>method size</b>: although the overall class may be smaller there are more instructions involved in preparing the
-data for invocation of the new joinpoint factory methods. It is possible if you have a lot of joinpoints that we might
-blow the 64k instruction limit for the <tt>ajc$preClinit</tt> method (where the factory invocation code is generated).
-Please provide feedback if this happens to you!
-</ul>
-
-<p>In anticipation of not all build plugins supporting that <tt>-Xajruntimetarget</tt> option, you can now specify
-these kinds of option in the <tt>ASPECTJ_OPTS</tt> environment variable. Set that in your environment:</p>
-<pre><code>
-export ASPECTJ_OPTS="-Xajruntimetarget:1.9"
-</code></pre>
-<p>And it should get picked up by AspectJ when it runs.</p>
-
-<ul>
-<li>1.9.0 available 2-Apr-2018
-</ul>
-
-<h1>AspectJ 1.9.0.RC4</h1>
-
-<p>Primary changes in RC4 are to add support for &lt;compilerArg&gt; in the Ant task. This enables users of the Ant task to
-pass in options supported by the underlying AspectJ but not yet surfaced elsewhere.  Particularly useful with Java9 which includes
-a number of module related commands. For example, here is an iajc usage with compilerArg that is passing <tt>--add-modules java.xml.bind</tt>:
-
-<pre><code>
-  &lt;iajc destdir="bin" failonerror="true"
-     showWeaveInfo="true" source="1.9" target="1.9"
-     debug="true"  fork="true"  maxmem="256m"&gt;
-     &lt;compilerArg value="--add-modules"/&gt;
-     &lt;compilerArg value="java.xml.bind"/&gt;
-    &lt;src path="src" /&gt;
-    &lt;classpath&gt;
-            &lt;pathelement location="${aspectj.home}/lib/aspectjrt.jar"/&gt;
-    &lt;/classpath&gt;
- &lt;/iajc&gt;
-</code></pre>
-
-<li>1.9.0.RC4 available 21-Feb-2018</li>
-
-<h1>AspectJ 1.9.0.RC3</h1>
-
-<p>Primary changes in RC3 are to upgrade JDT and pickup all the fixes for Java9 that have gone into it over the last few months.</p>
-
-<li>1.9.0.RC3 available 5-Feb-2018</li>
-
-<h1>AspectJ 1.9.0.RC2</h1>
-
-
-<ul>
-<li>1.9.0.RC2 available 9-Nov-2017
-</ul>
-
-<p>Key change in 1.9.0.RC2 is actually to be more tolerant of JDK10. The version handling has been somewhat overhauled so AspectJ 9 will
-behave better on Java 10 and future JDKs. This should put AspectJ in a better place if new JDK versions are going
-to arrive thick and fast.
-
-<h1>AspectJ 1.9.0.RC1</h1>
-<ul>
-
-<li>1.9.0.RC1 available 20-Oct-2017
-</ul>
-
-<p>This is the first release candidate of AspectJ 1.9.0 - the version of AspectJ to be based on Java9.  It includes
-a recent version of the Eclipse Java9 compiler (from jdt core, commit #062ac5d7a6bf9).</p>
-
-
-<h4>Automatic Modules</h4>
-<p>AspectJ can now be used with the new module system available in Java9. The key jars in AspectJ have been given automatic module names.
-
-The automatic module name is <tt>org.aspectj.runtime</tt> for the <tt>aspectjrt</tt> module:</p>
-<pre><code>
-$ java --module-path &lt;pathto&gt;/lib/aspectjrt.jar --list-modules | grep aspectj
-
-org.aspectj.runtime file:///&lt;pathto&gt;/lib/aspectjrt.jar automatic
-
-</code></pre>
-
-<p>And similarly <tt>org.aspectj.weaver</tt> and <tt>org.aspectj.tools</tt> for <tt>aspectjweaver</tt> and <tt>aspectjtools</tt> respectively:</p>
-
-<pre><code>
-$ java --module-path &lt;pathto&gt;/lib/aspectjweaver.jar --describe-module org.aspectj.weaver
-
-org.aspectj.weaver file:///&lt;pathto&gt;/lib/aspectjweaver.jar automatic
-requires java.base mandated
-contains aj.org.objectweb.asm
-contains aj.org.objectweb.asm.signature
-contains org.aspectj.apache.bcel
-contains org.aspectj.apache.bcel.classfile
-contains org.aspectj.apache.bcel.classfile.annotation
-contains org.aspectj.apache.bcel.generic
-contains org.aspectj.apache.bcel.util
-contains org.aspectj.asm
-contains org.aspectj.asm.internal
-...
-</code></pre>
-</p>
-<br><br>
-<h4>Building woven modules</h4>
-<p>AspectJ understands module-info.java source files and building modules that include aspects. Here is an example:</p>
-
-<pre><code>
-<b>module-info.java</b>
-
-module demo {
-	exports pkg;
-	requires org.aspectj.runtime;
-}
-
-
-<b>pkg/Demo.java</b>
-
-package pkg;
-
-public class Demo {
-	public static void main(String[] argv) {
-		System.out.println("Demo running");
-	}
-}
-
-
-<b>otherpkg/Azpect.java</b>
-
-package otherpkg;
-
-public aspect Azpect {
-	before(): execution(* *(..)) && !within(Azpect) {
-		System.out.println("Azpect running");
-	}
-}
-
-</code></pre>
-
-<p>We can now build those into a module:</p>
-
-<pre><code>
-$ ajc -1.9 module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
-
-...
-module-info.java:3 [error] org.aspectj.runtime cannot be resolved to a module
-...
-</code></pre>
-
-<p>Wait, that failed!  Yes, <tt>aspectjrt.jar</tt> (which includes the required <tt>org.aspectj.weaver</tt> module) wasn't supplied.
-We need to pass it on the module-path:</p>
-
-<pre><code>
-$ ajc -1.9 --module-path &lt;pathto&gt;/aspectjrt.jar module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
-
-</code></pre>
-
-<p>Now we have a demo module we can run:</p>
-
-<pre><code>
-$ java --module-path &lt;pathto&gt;/aspectjrt.jar:demo.jar --module demo/pkg.Demo
-
-Azpect running
-Demo running
-</code></pre>
-
-<p>That's it!</p>
-
-<br><br>
-
-<h4>Binary weaving with modules</h4>
-
-<p>A module is really just a jar with a module-info descriptor. As such you can simply pass a module on the <tt>inpath</tt>
-and binary weave it with other aspects.  Take the module we built above, let's weave into it again:</p>
-
-<pre><code>extra/AnotherAzpect.java
-
-package extra;
-
-public aspect AnotherAzpect {
-	before(): execution(* *(..)) && !within(*Azpect) {
-		System.out.println("AnotherAzpect running");
-	}
-}
-</code></pre>
-
-<pre><code>
-$ ajc -inpath demo.jar AnotherAzpect.java -outjar newdemo.jar</code></pre>
-
-<p>Notice how there was no complaint here that the <tt>org.aspectj.runtime</tt> module hadn't been passed in. That is because <tt>inpath</tt>
-was being used which doesn't treat specified jars as modules (and so does not check dependencies). There is no <tt>module-inpath</tt> right now.
-
-<p>Because the new jar produced includes the compiled aspect, the module-info specification inside is still correct, so we can run it
-exactly as before:</p>
-
-<pre><code>$ java --module-path ~/installs/aspectj190rc1/lib/aspectjrt.jar:newdemo.jar --module demo/pkg.Demo
-
-Azpect running
-AnotherAzpect running
-Demo running
-</code></pre>
-<br><br>
-
-<h4>Faster Spring AOP</h4>
-<p>Dave Syer recently created a series of benchmarks for checking the speed of Spring-AspectJ: 
-<tt><a href="https://github.com/dsyer/spring-boot-aspectj">https://github.com/dsyer/spring-boot-aspectj</a></tt>
-
-<p>Here we can see the numbers for AspectJ 1.8.11 (on an older Macbook Pro):
-
-<pre><code>
-Benchmark                 (scale)  Mode  Cnt   Score   Error  Units
-StartupBenchmark.ltw          N/A  avgt   10   2.553 ~ 0.030   s/op
-StartupBenchmark.ltw_100      N/A  avgt   10   2.608 ~ 0.046   s/op
-StartupBenchmark.spring     v0_10  avgt   10   2.120 ~ 0.148   s/op
-StartupBenchmark.spring     v1_10  avgt   10   2.219 ~ 0.066   s/op
-StartupBenchmark.spring    v1_100  avgt   10   2.244 ~ 0.030   s/op
-StartupBenchmark.spring    v10_50  avgt   10   2.950 ~ 0.026   s/op
-StartupBenchmark.spring    v20_50  avgt   10   3.854 ~ 0.090   s/op
-StartupBenchmark.spring   v20_100  avgt   10   4.003 ~ 0.038   s/op
-StartupBenchmark.spring     a0_10  avgt   10   2.067 ~ 0.019   s/op
-StartupBenchmark.spring     a1_10  avgt   10   2.724 ~ 0.023   s/op
-StartupBenchmark.spring    a1_100  avgt   10   2.778 ~ 0.057   s/op
-StartupBenchmark.spring    a10_50  avgt   10   7.191 ~ 0.134   s/op
-StartupBenchmark.spring   a10_100  avgt   10   7.191 ~ 0.168   s/op
-StartupBenchmark.spring    a20_50  avgt   10  11.541 ~ 0.158   s/op
-StartupBenchmark.spring   a20_100  avgt   10  11.464 ~ 0.157   s/op
-</code></pre>
-
-<p>So this is the average startup of an app affected by aspects applying to the beans involved.
-Where numbers are referenced the first is the number of aspects/pointcuts and the second
-is the number of beans.  The 'a' indicates an annotation based pointcut vs a non-annotation 
-based pointcut ('v'). Notice things are much worse for annotation based pointcuts.  At 20
-pointcuts and 50 beans the app is 9 seconds slower to startup.
-<br>
-
-<p>In AspectJ 1.8.12 and 1.9.0.RC1 some work has been done here. The key change is to recognize that the use
-of annotations with runtime retention is much more likely than annotations with class level
-retention. Retrieving annotations with class retention is costly because we must open the
-bytes for the class file and dig around in there (vs runtime retention which are immediately
-accessible by reflection on the types). In 1.8.11 the actual type of the annotation involved
-in the matching is ignored and the code will fetch *all* the annotations on the type/method/field
-being matched against. So even if the match is looking for a runtime retention annotation, we
-were doing the costly thing of fetching any class retention annotations. In 1.8.12/1.9.0.RC1
-we take the type of the match annotation into account - allowing us to skip opening the classfiles
-in many cases. There is also some deeper work on activating caches that were not previously
-being used correctly but the primary change is factoring in the annotation type.
-
-<p>What difference does that make?
-
-AspectJ 1.9.0.RC1:
-<pre><code>
-Benchmark                 (scale)  Mode  Cnt  Score   Error  Units
-StartupBenchmark.ltw          N/A  avgt   10  2.568 ~ 0.035   s/op
-StartupBenchmark.ltw_100      N/A  avgt   10  2.622 ~ 0.075   s/op
-StartupBenchmark.spring     v0_10  avgt   10  2.096 ~ 0.054   s/op
-StartupBenchmark.spring     v1_10  avgt   10  2.206 ~ 0.031   s/op
-StartupBenchmark.spring    v1_100  avgt   10  2.252 ~ 0.025   s/op
-StartupBenchmark.spring    v10_50  avgt   10  2.979 ~ 0.071   s/op
-StartupBenchmark.spring    v20_50  avgt   10  3.851 ~ 0.058   s/op
-StartupBenchmark.spring   v20_100  avgt   10  4.000 ~ 0.046   s/op
-StartupBenchmark.spring     a0_10  avgt   10  2.071 ~ 0.026   s/op
-StartupBenchmark.spring     a1_10  avgt   10  2.182 ~ 0.032   s/op
-StartupBenchmark.spring    a1_100  avgt   10  2.272 ~ 0.024   s/op
-StartupBenchmark.spring    a10_50  avgt   10  2.557 ~ 0.027   s/op
-StartupBenchmark.spring   a10_100  avgt   10  2.598 ~ 0.040   s/op
-StartupBenchmark.spring    a20_50  avgt   10  2.961 ~ 0.043   s/op
-StartupBenchmark.spring   a20_100  avgt   10  3.093 ~ 0.098   s/op
-</code></pre>
-
-<p>Look at the a20_100 case - instead of impacting start time by 9 seconds, it impacts it by 1 second.
-
-<h3>More to come...</h3>
-
-<ul>
-<li><p>Eclipse JDT Java 9 support is still being actively worked on and lots of fixes will be coming through over the next few months
-and included in AspectJ 1.9.X revisions.</p>
-
-<li><p>AspectJ does not currently modify <tt>module-info.java</tt> files. An aspect from one module applying to code in
-another module clearly introduces a dependency between those two modules. There is no reason - other than time! - that
-this can't be done. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=526244">Issue 526244</a>)</p>
-
-<li><p>Related to that AspectJ, on detection of aspects should be able to automatically introduce the <tt>requires org.aspectj.runtime</tt> to
-the <tt>module-info</tt>. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=526242">Issue 526242</a>)</p>
-
-<li><p>Module aware variants of AspectJ paths: <tt>--module-inpath</tt>, <tt>--module-aspectpath</tt>. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=526243">Issue 526243</a>)</p>
-</ul>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-191.html b/docs/dist/doc/README-191.html
deleted file mode 100644
index 4c891d208..000000000
--- a/docs/dist/doc/README-191.html
+++ /dev/null
@@ -1,52 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.1 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2018 Contributors.
-All rights reserved.
-</small></div>
-<p>The full list of resolved issues in 1.9.1 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.1">here</a></h2>.</p>
-
-<h1>AspectJ 1.9.1</h1>
-
-<h4>Java 10 support</h4>
-<p>AspectJ has updated to a recent JDT compiler version (commit <tt>#abe06abe4ce1</tt> - 9-Apr-2018). With this update it
-now supports Java10.  This means you can use the 'var' support. A simple example of combining var with
-an aspect:</p>
-<p>
-<pre><code>
-public class Code3 {
-	public static void main(String []argv) {
-		var x = "hello";
-		System.out.println(x.getClass());
-	}
-}
-
-aspect X {
-	before(): call(* *.getClass()) && target(String) {
-		System.out.println(thisJoinPointStaticPart);
-	}
-}
-</code></pre>
-</p>
-<p>Available: 1.9.1 available 20-Apr-2018</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-192.html b/docs/dist/doc/README-192.html
deleted file mode 100644
index d93ad05a8..000000000
--- a/docs/dist/doc/README-192.html
+++ /dev/null
@@ -1,35 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.2 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2018 Contributors.
-All rights reserved.
-</small></div>
-<p>The full list of resolved issues in 1.9.2 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.2">here</a></h2>.</p>
-
-<h1>AspectJ 1.9.2</h1>
-
-<h4>Java 11 support</h4>
-<p>AspectJ now supports Java11. It has been updated to a more recent JDT compiler that supports Java 11 (JDTCore #6373b82afa49b).
-
-<p>Available: 1.9.2 available Oct-2018</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-193.html b/docs/dist/doc/README-193.html
deleted file mode 100644
index f9cc4d0cf..000000000
--- a/docs/dist/doc/README-193.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.3 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2018 Contributors.
-All rights reserved.
-</small></div>
-<p>The full list of resolved issues in 1.9.3 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.3">here</a></h2>.</p>
-
-<p>AspectJ 1.9.3 supports Java12. Java12 introduces the new switch expression syntax, but you must activate support for that via 
-an <tt>--enable-preview</tt> flag when using the compiler and attempting to run the resultant classes:
-
-Here is <tt>Switch3.java</tt>:
-<pre><code>
-=========8<=========
-public class Switch3 {
-	public static void main(String[] argv) {
-		System.out.println(one(Color.R));
-		System.out.println(one(Color.G));
-		System.out.println(one(Color.B));
-		System.out.println(one(Color.Y));
-	}
-
-	public static int one(Color color) {
-		int result = switch(color) {
-		 case R -> foo(0);
-		 case G -> foo(1);
-		 case B -> foo(2);
-		 default -> foo(3);
-		};
-		return result;
-	}
-	
-	public static final int foo(int i) {
-		return i+1;
-	}
-}
-
-enum Color {
-	R, G, B, Y;
-}
-
-aspect X {
-	int around(): call(* foo(..)) {
-		return proceed()*3;
-	}
-}
-=========8<=========
-</code></pre>
-
-Compile it with:
-<pre><code>
-$ ajc --enable-preview -showWeaveInfo -12 Switch3.java
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:12) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:13) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:14) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:15) advised by around advice from 'X' (Switch3.java:30)
-
-</code></pre>
-
-Now run it:
-<pre><code>
-$ java --enable-preview Switch3
-3
-6
-9
-12
-</code></pre>
-
-
-
-<p>Available: 1.9.3.RC1 available 7-Mar-2019</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-194.html b/docs/dist/doc/README-194.html
deleted file mode 100644
index 0abd37dab..000000000
--- a/docs/dist/doc/README-194.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.4 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2019 Contributors.
-All rights reserved.
-</small></div>
-<h1>AspectJ 1.9.4</h1>
-<p>The full list of resolved issues in 1.9.4 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.4">here</a></h2>.</p>
-
-<p>AspectJ 1.9.4 has a couple of important fixes in it:
-<ul>
-<li>Due to the new maven build process being used to build release artifacts
-for the first time, there were errors in the aspectjweaver jar that affected
-the ability to use it on the command line as an agent,
-this is now fixed.
-<li>A number of users were noticing a ClassCastException problem, which I believe was due to trying to
-run AspectJ on one level of the JDK whilst targeting another. This can happen quite easily in eclipse
-if running your Eclipse on Java 8 but developing projects targeting Java 11.
-The class cast is because Java8 couldn't understand
-the packaging of system classes post Java9 and so couldn't find java.lang.Object. This has now all been
-tidied up and should work much better. More details in <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=546807">546807</a>,
-thanks to Denys Khanzhyiev for some tips on getting to the right solution.
-</ul>
-
-
-<p>Available: 1.9.4 available 10-May-2019</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-195.html b/docs/dist/doc/README-195.html
deleted file mode 100644
index ff5588641..000000000
--- a/docs/dist/doc/README-195.html
+++ /dev/null
@@ -1,74 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.5 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2019 Contributors.
-All rights reserved.
-</small></div>
-<h1>AspectJ 1.9.5</h1>
-<p>The full list of resolved issues in 1.9.5 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.5">here</a></h2>.</p>
-
-<p>AspectJ 1.9.5 supports Java13. Java13 introduces text blocks, but you must activate support for that via 
-an <tt>--enable-preview</tt> flag when using the compiler and attempting to run the resultant classes:
-
-Here is <tt>Code.java</tt>:
-<pre><code>
-=======8<=========
-public class Code {
-  public static void main(String[] argv) {
-  }
-
-  static aspect X {
-    before(): execution(* Code.main(..)) {
-	System.out.println(
-"""
-This
-is
-on
-multiple
-lines
-"""
-);
-    }
-  }
-
-}
-=========8<=========
-</code></pre>
-
-<p>Compile it with:
-<pre><code>
-$ ajc --enable-preview -13 Code.java
-</code></pre>
-
-<p>Now run it:
-<pre><code>
-$ java --enable-preview Code
-This
-is
-on
-multiple
-lines
-</code></pre>
-
-<p>Available: 1.9.5 available 28-Nov-2019</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-196.html b/docs/dist/doc/README-196.html
deleted file mode 100644
index e85348867..000000000
--- a/docs/dist/doc/README-196.html
+++ /dev/null
@@ -1,73 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html> <head>
-<title>AspectJ 1.9.6 Readme</title>
-<style type="text/css">
-<!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
--->
-</style>
-</head>
-
-<body>
-<div align="right"><small>
-&copy; Copyright 2020 Contributors.
-All rights reserved.
-</small></div>
-<h1>AspectJ 1.9.6</h1>
-<p>The full list of resolved issues in 1.9.6 is available 
-<a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.6">here</a></h2>.</p>
-
-<p>AspectJ 1.9.6 supports Java14. Java14 introduces records, but you must activate support for that via 
-an <tt>--enable-preview</tt> flag when using the compiler and attempting to run the resultant classes:
-
-Here is <tt>Code.java</tt>:
-<pre><code>
-=======8<=========
-public record Person(String firstName, String lastName, int age) {}
-=======8<=========
-
-=======8<=========
-public class UsingPersonRecord {
-  public static void main(String[] argv) {
-    Person p = new Person("A","B",99);
-    System.out.println(p);
-    System.out.println(p.firstName());
-  }
-}
-=======8<=========
-
-=======8<=========
-public aspect TraceRecordComponents {
-  before(): execution(public * *()) {
-    System.out.println(thisJoinPointStaticPart);
-  }
-}
-=======8<=========
-</code></pre>
-
-<p>Compile it with:
-<pre><code>
-$ ajc --enable-preview -14 Person.java UsingPersonRecord.java TraceRecordComponents.java
-</code></pre>
-
-<p>Now run it:
-<pre><code>
-$ java --enable-preview UsingPersonRecord
-execution(String Person.toString())
-Person[firstName=A, lastName=B, age=99]
-execution(String Person.firstName())
-A
-</code></pre>
-
-<p>Available: 1.9.6 available 22-Jul-2020</p>
-
-<br><br>
-
-
-<!-- ============================== -->  
-</body>
-</html>
diff --git a/docs/dist/doc/README-197.html b/docs/dist/doc/README-197.html
deleted file mode 100644
index 0b39b40cb..000000000
--- a/docs/dist/doc/README-197.html
+++ /dev/null
@@ -1,127 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-
-<head>
-<title>AspectJ 1.9.7 Readme</title>
-<style type="text/css">
-  <!--
-  P   { margin-left:  20px; }
-  PRE { margin-left:  20px; }
-  LI  { margin-left:  20px; }
-  H4  { margin-left:  20px; }
-  H3  { margin-left:  10px; }
-  -->
-</style>
-</head>
-
-<body>
-<div align="right"><small>&copy; Copyright 2021 Contributors. All rights reserved.</small></div>
-
-<h1>AspectJ 1.9.7</h1>
-
-<p>
-  AspectJ (binaries, source code, documentation) is now distributed under the
-  <a href="https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt">Eclipse Public License v 2.0</a>.
-</p>
-
-<p>
-  Please note that going forward Bugzilla for issue management is deprecated and new issues should be filed as <a href="https://github.com/eclipse/org.aspectj/issues/new">GitHub issues</a>.
-  The list of issues addressed for 1.9.7 can be found
-  <a href="https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.7">here for Bugzilla</a>
-  and  <a href="https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.7">here for GitHub issues</a>.
-</p>
-
-<h2>New features</h2>
-
-<p>
-  AspectJ 1.9.7 supports <a href="https://openjdk.java.net/projects/jdk/15/">Java 15</a> &amp;
-  <a href="https://openjdk.java.net/projects/jdk/16/">Java 16</a> and their respective final and preview features:
-</p>
-<ul>
-  <li>text blocks (final 15)</li>
-  <li>records (preview 15, final 16)</li>
-  <li><tt>instanceof</tt> pattern matching (preview 15, final 16)</li>
-  <li>hidden classes (final 15)</li>
-  <li>sealed classes (preview 15, preview 16)</li>
-</ul>
-<p>
-  For features marked as preview on a given JDK, you need to compile with <tt>ajc --enable-preview</tt> and run with
-  <tt>java --enable-preview</tt> on that JDK.
-</p>
-<p>
-  Please note that you cannot run code compiled with preview features on any other JDK than the one used for
-  compilation. For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This
-  is a JVM limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16.
-  You still need to recompile, no matter what.
-</p>
-<p>
-<p>
-  You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features
-  were first supported (possibly as JVM preview features):
-</p>
-<ul>
-  <li><a href="https://github.com/eclipse/org.aspectj/tree/master/tests/features195/textblock">
-    AspectJ 1.9.5: text blocks</a></li>
-  <li><a href="https://github.com/eclipse/org.aspectj/tree/master/tests/features196/java14">
-    AspectJ 1.9.6: records, <tt>instanceof</tt> patterns</a></li>
-  <li><a href="https://github.com/eclipse/org.aspectj/tree/master/tests/features197/java15">
-    AspectJ 1.9.7: hidden classes, sealed classes</a></li>
-</ul>
-
-<h2>Using LTW on Java 16+</h2>
-
-<p>
-  Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-  <a href="https://openjdk.java.net/jeps/396">JEP 396 (Strongly Encapsulate JDK Internals by Default)</a>. Therefore,
-  you need to set the JVM parameter <tt>--add-opens java.base/java.lang=ALL-UNNAMED</tt> in order to enable aspect
-  weaving. This is due to the fact that the weaver uses internal APIs for which we have not found an adequate
-  replacement yet when defining classes in different classloaders.
-</p>
-
-<h2>Organisational and internal changes</h2>
-
-<p>
-  For AspectJ 1.9.7, we implemented a lot of internal changes concerning the build and release process, most of which
-  are not visible in the product itself but will help us to more easily maintain and release the product in the future
-  and more easily on-boarding new developers or contributors. For example:
-</p>
-<ul>
-  <li>The main repository has been moved to <a href="https://github.com/eclipse/org.aspectj">GitHub</a>, i.e. you can
-    open bug reports, feature requests and pull requests there now.</li>
-  <li>The Maven build has been improved, i.e. it is now easier to build and contribute to the product. Developers can
-    just import the Maven project and no longer depend on Eclipse to build and test AspectJ, but can e.g. also use
-    IntelliJ IDEA.</li>
-  <li>Continuous integration builds now run on GitHub for different JDK versions, also for pull requests. I.e. both
-    maintainers and contributors get to know if their changes break any tests.</li>
-  <li>We can build releases and deploy them directly to Sonatype OSSRH (snapshots) or Maven Central (releases) with
-    Maven now, i.e. it should be much easier in the future to publish development versions in order to enable users to
-    re-test fixed bugs or try new features.</li>
-  <li>All tests are portable now, i.e. they correctly run on Windows, too. This enables developers and contributors to make
-    a choice if they want to work on Linux or on Windows.</li>
-</ul>
-
-<h2>Other changes and bug fixes</h2>
-
-<ul>
-  <li>Remove legacy JRockit support.</li>
-  <li>Support Windows 10 and Windows Server 2016/2019 in installer. Those versions were not detected until now, which
-    led to bogus Windows batch files forwarding only 9 AJC parameters to the Java process via
-    <tt>%1 %2 %3 %4 %5 %6 %7 %8 %9</tt> instead of <tt>%*</tt>.</li>
-  <li>AJdoc (AspectJ's javadoc generator add-on for aspects) now supports the JDK 16 javadoc generator.</li>
-  <li>Fix <tt>serialVersionUID</tt> initialization for Java 9+</li>
-  <li>AJC (AspectJ Compiler) usage texts sometimes used to be printed twice and they were printed too often, e.g. on
-    top of every compile error. This has been fixed. Furthermore, the partly outdated usage text is now basically the
-    same as ECJ (Eclipse Java Compiler), which AJC is a fork of, plus AspectJ-specific additions which are added during
-    runtime.</li>
-  <li>Source and javadoc JARs distributed together with the AspectJ artifacts on Maven Central are now more accurate and
-    more complete with regard to what is included (ASM, JDT Core) and how package names have been relocated.</li>
-  <li>Fix sample code formatting issues (indentation) throughout the documentation.</li>
-</ul>
-
-<p>
-  Available: 1.9.7 available 24-Jun-2021
-</p>
-
-</body>
-
-</html>
diff --git a/docs/dist/doc/changes.adoc b/docs/dist/doc/changes.adoc
index 12192b51c..c7b2d6975 100644
--- a/docs/dist/doc/changes.adoc
+++ b/docs/dist/doc/changes.adoc
@@ -3,36 +3,37 @@
 
 == Changes in AspectJ
 
-* xref:#1.6.0[1.6.0] (released 2008-04)
-* xref:#1.5.4[1.5.4] (released 2007-12)
-* xref:#1.5.3[1.5.3] (released 2006-11)
-* xref:#1.5.2[1.5.2] (released 2006-06)
-* xref:#1.5.1[1.5.1] (released 2006-04)
-* xref:#1.5.0[1.5.0] (released 2005-12)
-* xref:#1.2.1[1.2.1] (released 2004-10)
-* xref:#1.2[1.2] (released 2004-05)
-* xref:#1.1.1[1.1.1] (released 2003-09)
-* 1.1.0 (released 2003-06-06) See README-11.html
-* xref:#1.0.6[1.0.6] (released 2002-07-24)
-** xref:#1.0.6compiler[Compiler]
-** xref:#1.0.6ajde[AJDE]
-** xref:#1.0.6ajdoc[Ajdoc]
-* xref:#1.0.5[1.0.5] (released 2002-06-27)
-* xref:#1.0.4[1.0.4] (released 2002-04-17)
-* xref:#1.0.3[1.0.3] (released 2002-02-08)
-* xref:#1.0.2[1.0.2] (released 2002-02-06)
-* xref:#1.0.1[1.0.1] (released 2001-12-18)
-* xref:#1.0.0[1.0.0] (released 2001-11-30)
-* xref:#1.0rc3[1.0rc3] (released 2001-11-14)
-* xref:#1.0rc2[1.0rc2] (released 2001-10-12)
-* xref:#1.0rc1[1.0rc1] (released 2001-10-5)
-* xref:#1.0beta1[1.0beta1] (released 2001-08-29)
-* xref:#1.0alpha1[1.0alpha1] (released 2001-08-09)
+* xref:#_1_6_0[1.6.0] (released 2008-04)
+* xref:#_1_5_4[1.5.4] (released 2007-12)
+* xref:#_1_5_3[1.5.3] (released 2006-11)
+* xref:#_1_5_2[1.5.2] (released 2006-06)
+* xref:#_1_5_1[1.5.1] (released 2006-04)
+* xref:#_1_5_0[1.5.0] (released 2005-12)
+* xref:#_1_2_1[1.2.1] (released 2004-10)
+* xref:#_1_2[1.2] (released 2004-05)
+* xref:#_1_1_1[1.1.1] (released 2003-09)
+* 1.1.0 (released 2003-06-06) See xref:README-11.adoc#readme-1_1[1.1.0 release notes].
+* xref:#_1_0_6[1.0.6] (released 2002-07-24)
+** xref:#_1_0_6compiler[Compiler]
+** xref:#_1_0_6ajde[AJDE]
+** xref:#_1_0_6ajdoc[Ajdoc]
+* xref:#_1_0_5[1.0.5] (released 2002-06-27)
+* xref:#_1_0_4[1.0.4] (released 2002-04-17)
+* xref:#_1_0_3[1.0.3] (released 2002-02-08)
+* xref:#_1_0_2[1.0.2] (released 2002-02-06)
+* xref:#_1_0_1[1.0.1] (released 2001-12-18)
+* xref:#_1_0_0[1.0.0] (released 2001-11-30)
+* xref:#_1_0rc3[1.0rc3] (released 2001-11-14)
+* xref:#_1_0rc2[1.0rc2] (released 2001-10-12)
+* xref:#_1_0rc1[1.0rc1] (released 2001-10-5)
+* xref:#_1_0beta1[1.0beta1] (released 2001-08-29)
+* xref:#_1_0alpha1[1.0alpha1] (released 2001-08-09)
 * xref:porting.adoc[Porting and Transition]
 
 '''''
 
-== [#1.6.0]#1.6.0#
+[[_1_6_0]]
+== 1.6.0
 
 This release rebases AspectJ on the Eclipse Compiler version 785_R33X -
 making it Java6 compliant.
@@ -40,7 +41,8 @@ making it Java6 compliant.
 A full list of bugs fixed and enhancements implemented can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=[Bugzilla].
 
-== [#1.5.4]#1.5.4#
+[[_1_5_4]]
+== 1.5.4
 
 This release contains around 40 bug fixes and enhancements since the
 1.5.3 release.
@@ -49,7 +51,8 @@ A full list of bugs fixed and enhancements implemented can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.4&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[]
 Bugzilla
 
-== [#1.5.3]#1.5.3#
+[[_1_5_3]]
+== 1.5.3
 
 This release contains around 80 bug fixes and enhancements since the
 1.5.2 release.
@@ -58,7 +61,8 @@ A full list of bugs fixed and enhancements implemented can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.3&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[]
 Bugzilla
 
-== [#1.5.2]#1.5.2#
+[[_1_5_2]]
+== 1.5.2
 
 This release contains around 60 bug fixes and enhancements since the
 1.5.1 release.
@@ -67,7 +71,8 @@ A full list of bugs fixed and enhancements implemented can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.2&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[]
 Bugzilla
 
-== [#1.5.1]#1.5.1#
+[[_1_5_1]]
+== 1.5.1
 
 This release contains over 70 bug fixes and enhancements since the 1.5.0
 release.
@@ -76,18 +81,20 @@ A full list of bugs fixed in AspectJ 5 can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.1&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[]
 Bugzilla
 
-== [#1.5.0]#1.5.0#
+[[_1_5_0]]
+== 1.5.0
 
 This release contains nearly 400 bug fixes and enhancements since the
 1.2.1 release. Major updates to the language are documented in the
-link:adk15notebook/index.html[AspectJ 5 Developer's Notebook]. There are
+xref:../../adk15ProgGuideDB/adk15notebook.adoc[AspectJ 5 Developer's Notebook]. There are
 also a number of enhancements to accompanying tools documented in the
 link:devguide/index.html[Developer's Guide]
 
 A full list of bugs fixed in AspectJ 5 can be found in
 https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&product=AspectJ&resolution=FIXED&chfieldfrom=2004-11-06&chfieldto=2005-12-20[bugzilla].
 
-== [#1.2.1]#1.2.1#
+[[_1_2_1]]
+== 1.2.1
 
 All known P1 and P2 bugs have been fixed in this release. The
 https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.2.1&bug_status=RESOLVED&resolution=FIXED[full
@@ -206,7 +213,8 @@ aspectjweaver.jar is included in the lib directory, which contains the
 subset of aspectjtools.jar needed for weaving. The "aj" script is also
 moved into the bin directory.
 
-== [#1.2]#1.2#
+[[_1_2]]
+== 1.2
 
 All known P1 and P2 bugs have been fixed in this release. The
 https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.2[full
@@ -332,7 +340,8 @@ contain a valid manifest file.
 local storage used to manage cflow stacks when available - improves
 cflow performance when working with a multi-threaded application.
 
-== [#1.1.1]#1.1.1#
+[[_1_1_1]]
+== 1.1.1
 
 All known P1 and P2 bugs have been fixed in this release. The
 https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.1.1[full
@@ -388,18 +397,21 @@ source directory, following ajc and javac. As a result, now you can use
 ajc to compile JSP's in Tomcat. Thanks to Ron Bodkin for investigating
 how to integrate ajc with Tomcat.
 
-== [#1.0.6]#1.0.6#
+[[_1_0_6]]
+== 1.0.6
 
 This release contains mainly bug fixes for ajde and ajdoc.
 
-=== [#1.0.6compiler]#Compiler#
+[[_1_0_6compiler]]
+=== Compiler
 
 We fixed a bug with switch statements, thanks largely to Jason Rimmer's
 diligence in helping us isolate the problem. Also, to help Log4J parse
 stack traces, we changed class file symbolic line references to use []
 instead of () for the virtual start lines of each file.
 
-=== [#1.0.6ajde]#AJDE#
+[[_1_0_6ajde]]
+=== AJDE
 
 *AJDE Framework, AJBrowser, and AJDE for Forte/NetBeans*
 
@@ -429,7 +441,8 @@ In addition, thanks to user feedback that indicated trouble building
 JBuilder OpenTools with AJDE/JBuilder, the OpenTool is now being built
 with itself.
 
-=== [#1.0.6ajdoc]#Ajdoc#
+[[_1_0_6ajdoc]]
+=== Ajdoc
 
 * Fixed http://aspectj.org/bugs/resolved?id=790[790] aspect code
 comments suppressed by fix to bug 710
@@ -437,7 +450,8 @@ comments suppressed by fix to bug 710
 
 '''''
 
-== [#1.0.5]#1.0.5#
+[[_1_0_5]]
+== 1.0.5
 
 This release includes significant improvements to AspectJ Development
 Environment (AJDE) support. The entire user interface has been revised
@@ -446,12 +460,13 @@ JBuilder and NetBeans/Forte support. JBuilder support now includes
 graphical configuration file editing and an integrated AspectJ Browser
 tool.
 
-* xref:#1.0.5compiler[Compiler]
-* xref:#1.0.5ajde[AJDE]
-* xref:#1.0.5ajdoc[Ajdoc]
-* xref:#1.0.5anttasks[Ant tasks]
+* xref:#_1_0_5compiler[Compiler]
+* xref:#_1_0_5ajde[AJDE]
+* xref:#_1_0_5ajdoc[Ajdoc]
+* xref:#_1_0_5anttasks[Ant tasks]
 
-=== [#1.0.5compiler]#Compiler#
+[[_1_0_5compiler]]
+=== Compiler
 
 This was another compiler release primarily concerned with fixing corner
 cases in the language implementation. Our handling of nested classes,
@@ -459,7 +474,8 @@ the assert statement, and cflow were the principal offenders this time.
 Thanks to Nicholas Alex Leidenfrost and Patrick Chan for their clear and
 concise bug reports on some of these issues.
 
-=== [#1.0.5ajde]#AJDE#
+[[_1_0_5ajde]]
+=== AJDE
 
 ==== This release includes significant improvements to AspectJ Development Environment (AJDE) support. All known bugs have been fixed, and the core framework quality has been significantly increased thanks to the adoption of a unit test suite. The following changes apply to all of the AJDE NetBeans/Forte, JBuilder, and the AspectJ Browser support. NetBeans/Forte and JBuilder-specific changes are listed below.
 
@@ -520,7 +536,8 @@ the options dialog, and make sure that both the Java executable is on
 your path, and the class that you expect to execute on your classpath.
 * The error messages UI has been improved.
 
-=== [#1.0.5ajdoc]#Ajdoc#
+[[_1_0_5ajdoc]]
+=== Ajdoc
 
 Bug fixes:
 
@@ -534,7 +551,8 @@ docs for methods or constructors declared on other types.]
 * http://aspectj.org/bugs/resolved?id=751[751 - error loading doclet
 resource]
 
-=== [#1.0.5anttasks]#Ant tasks#
+[[_1_0_5anttasks]]
+=== Ant tasks
 
 Bug fixes:
 
@@ -543,15 +561,17 @@ ajc flags]
 
 '''''
 
-== [#1.0.4]#1.0.4#
+[[_1_0_4]]
+== 1.0.4
 
-* xref:#1.0.4compiler[Compiler]
-* xref:#1.0.4ajde[AJDE]
-* xref:#1.0.4ajdoc[Ajdoc]
-* xref:#1.0.4taskdefs[Ant taskdefs]
-* xref:#1.0.4doc[Documentation]
+* xref:#_1_0_4compiler[Compiler]
+* xref:#_1_0_4ajde[AJDE]
+* xref:#_1_0_4ajdoc[Ajdoc]
+* xref:#_1_0_4taskdefs[Ant taskdefs]
+* xref:#_1_0_4doc[Documentation]
 
-=== [#1.0.4compiler]#Compiler#
+[[_1_0_4compiler]]
+=== Compiler
 
 * Over a dozen people independently reported a bug in error handling for
 the wrong number number of arguments to `proceed`. This has been turned
@@ -585,10 +605,11 @@ exception.
 design for some uses of after returning advice. This compiler behavior
 was fixed, and advice whose behavior might be changed by this bug fix
 will be highlighted with a compiler warning. More information about some
-of these changes can be found in the xref:porting.adoc#pre-1.0.4[porting
+of these changes can be found in the xref:porting.adoc#pre-1_0_4[porting
 notes].
 
-=== [#1.0.4ajde]#AJDE#
+[[_1_0_4ajde]]
+=== AJDE
 
 This is the first release of AJDE support with significant external
 contribution. A big thanks goes out to Phil Sager for porting the AJDE
@@ -621,31 +642,36 @@ projects and should be used for navigating structure instead.
 
 * This is a bug fix release only.
 
-=== [#1.0.4ajdoc]#Ajdoc#
+[[_1_0_4ajdoc]]
+=== Ajdoc
 
 Ajdoc now runs under J2SE 1.4, but still requires the tools.jar from
 J2SE 1.3 be on the classpath.
 
-=== [#1.0.4taskdefs]#Ant tasks#
+[[_1_0_4taskdefs]]
+=== Ant tasks
 
 * Repackaged to fit into the AspectJ product directory - e.g.,
 `aspectj-ant.jar` moved to `lib` as expected by `examples/build.xml`.
 * Fixed bugs, esp. http://aspectj.org/bugs/resolved?id=682[682]: Throw
 BuildException if failonerror and ajdoc detects misconfiguration.
 
-=== [#1.0.4doc]#Documentation#
+[[_1_0_4doc]]
+=== Documentation
 
 Added a 1-page quick reference guide. Improved javadoc documentation for
 the org.aspectj.lang package.
 
 '''''
 
-== [#1.0.3]#1.0.3#
+[[_1_0_3]]
+== 1.0.3
 
-* xref:#1.0.3compiler[Compiler]
-* xref:#1.0.3taskdefs[Ant taskdefs]
+* xref:#_1_0_3compiler[Compiler]
+* xref:#_1_0_3taskdefs[Ant taskdefs]
 
-=== [#1.0.3compiler]#Compiler#
+[[_1_0_3compiler]]
+=== Compiler
 
 This release fixes a single significant bug in 1.0.2 where ajc could
 generate unreachable code in `-usejavac` or `-preprocess` mode. This
@@ -654,14 +680,16 @@ consisted solely of a `while (true) {}` loop. We now properly handle the
 flow-analysis for this case and generate code that is acceptable to
 javac. Thanks to Rich Price for reporting this bug.
 
-=== [#1.0.3taskdefs]#Ant taskdefs#
+[[_1_0_3taskdefs]]
+=== Ant taskdefs
 
 Added support to the Ajc taskdef for the -source 1.4 and -X options
 generally.
 
 '''''
 
-== [#1.0.2]#1.0.2#
+[[_1_0_2]]
+== 1.0.2
 
 This release is mainly about keeping up with the Joneses. To keep up
 with SUN's release candidate for J2SE1.4, we now officially support the
@@ -672,11 +700,12 @@ since some of our users are starting to work on Mac OSX, AJDE now works
 nicely on this platform. We also fixed almost all of the bugs you
 reported in 1.0.1.
 
-* xref:#1.0.2compiler[Compiler]
-* xref:#1.0.2ajde[AJDE]
-* xref:#1.0.2ajdb[AJDB]
+* xref:#_1_0_2compiler[Compiler]
+* xref:#_1_0_2ajde[AJDE]
+* xref:#_1_0_2ajdb[AJDB]
 
-=== [#1.0.2compiler]#Compiler#
+[[_1_0_2compiler]]
+=== Compiler
 
 * Official support for `-source 1.4` option to compile new
 http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html[1.4
@@ -718,7 +747,8 @@ javac].
 * Changes required adding runtime classes, so please compile and run
 using the latest `aspectjrt.jar`
 
-=== [#1.0.2ajde]#AJDE#
+[[_1_0_2ajde]]
+=== AJDE
 
 This is a bug fix release only.
 
@@ -742,7 +772,8 @@ not be updated after a recompile.
 
 * Keyboard shortcuts were fixed to work with Mac OSX.
 
-==== [#1.0.2ajdb]#AJDB#
+[[_1_0_2ajdb]]
+==== AJDB
 
 Some minor bug fixes, but this is still early-access software. Please
 try using another JPDA-compliant debugger. If it uses JDI correctly,
@@ -752,13 +783,15 @@ would appreciate any reports of success or failure.
 
 '''''
 
-== [#1.0.1]#1.0.1#
+[[_1_0_1]]
+== 1.0.1
 
-* xref:#1.0.1compiler[Compiler]
-* xref:#1.0.1ajde[AJDE]
-* xref:#1.0.1ajdb[AJDB]
+* xref:#_1_0_1compiler[Compiler]
+* xref:#_1_0_1ajde[AJDE]
+* xref:#_1_0_1ajdb[AJDB]
 
-=== [#1.0.1compiler]#Compiler#
+[[_1_0_1compiler]]
+=== Compiler
 
 This release fixes a significant performance issue in the compiler,
 reported by Rich Price, that could lead to extremely long compiles in
@@ -775,7 +808,8 @@ Thanks to Vincent Massol for pointing out the importance of this. It is
 expected that this prefix will either become the default compiler
 behavior in the future or a non-experimental flag will replace it.
 
-=== [#1.0.1ajde]#AJDE#
+[[_1_0_1ajde]]
+=== AJDE
 
 Minor bug fixes, including: AJDE for JBuilder failed to preserve
 application parameters from project settings when executing the
@@ -783,7 +817,8 @@ application.
 
 Source builds were cleaned up for JBuilder and Forte sources.
 
-=== [#1.0.1ajdb]#AJDB#
+[[_1_0_1ajdb]]
+=== AJDB
 
 Two bugs were reported and have been fixed in this release. (Note that
 ajdb is still considered early-access software.)
@@ -791,19 +826,22 @@ ajdb is still considered early-access software.)
 * bug 611: NullPointerException dumping non-primitive values
 * bug 617: -X and -D options not passed to debug VM correctly
 
-== [#1.0.0]#1.0.0#
+[[_1_0_0]]
+== 1.0.0
 
-* xref:#1.0.0language[Language]
-* xref:#1.0.0compiler[Compiler]
-* xref:#1.0.0ajde[AJDE]
-* xref:#1.0.0ajdoc[AJDoc]
-* xref:#1.0.0taskdefs[Ant taskdefs]
+* xref:#_1_0_0language[Language]
+* xref:#_1_0_0compiler[Compiler]
+* xref:#_1_0_0ajde[AJDE]
+* xref:#_1_0_0ajdoc[AJDoc]
+* xref:#_1_0_0taskdefs[Ant taskdefs]
 
-== [#1.0.0language]#Language#
+[[_1_0_0language]]
+== Language
 
 There were no language changes for this release.
 
-== [#1.0.0compiler]#Compiler#
+[[_1_0_0compiler]]
+== Compiler
 
 Several minor bugs primarily in error handling were reported and have
 been fixed in this release. The two most serious bugs are described
@@ -822,7 +860,8 @@ compiler sometimes generating illegal code when introduced methods on a
 class overrode introduced methods on an interface implemented by that
 class. This is now fixed.
 
-== [#1.0.0ajde]#AJDE#
+[[_1_0_0ajde]]
+== AJDE
 
 Numerous user interface refinements were made to the browser and core
 AJDE functionality. Error handling and reporting has been improved. All
@@ -851,20 +890,24 @@ http://aspectj.org/docs
 * Pop-up jump menu now placed (with mouse pointer) near cursor.
 * [AJDEE only] Improved filtering of legal code completions.
 
-=== [#1.0.0ajdoc]#AJDoc#
+[[_1_0_0ajdoc]]
+=== AJDoc
 
 * Runs only in J2SE 1.3 - not 1.2 or 1.4. You can document 1.x-reliant
 programs by using the options to compile using 1.x libraries.
 * Disabled some non-functioning options, documented as `unsupported` in
 the syntax message.
 
-=== [#1.0.0taskdefs]#Ant taskdefs#
+[[_1_0_0taskdefs]]
+=== Ant taskdefs
 
 * Fork is not supported in the AJDoc taskdef
 
-== [#1.0rc3]#1.0rc3#
+[[_1_0rc3]]
+== 1.0rc3
 
-== [#1.0rc3language]#Language#
+[[_1_0rc3language]]
+== Language
 
 There have been several minor clarifications/changes to the language.
 
@@ -877,7 +920,8 @@ more closely. This led to several small improvements and clarifications
 to this language feature.
 http://aspectj.org/pipermail/users/2001/001258.html[More details...]
 
-== [#1.0rc3compiler]#Compiler#
+[[_1_0rc3compiler]]
+== Compiler
 
 This release saw several changes to the compiler in order to work-around
 known bugs in different JVMs, or to otherwise mimic the behavior of
@@ -915,7 +959,8 @@ noticed this ourselves when running the jacks compiler test suite from
 the jikes group, and had added the feature days before getting our first
 bug report for it not being there.
 
-== [#1.0rc3ajde]#AJDE#
+[[_1_0rc3ajde]]
+== AJDE
 
 * The structure view has been improved.
 * Multiple user-configurable views are supported.
@@ -957,7 +1002,8 @@ right-clicking to select the "Display Sources" command.
 * For AJDEE, compatibility with JDEE 2.2.9beta4. Also, fixes in
 completion, ajdoc launch, and speedbar.
 
-=== [#1.0rc3ajdoc]#AJDoc#
+[[_1_0rc3ajdoc]]
+=== AJDoc
 
 Some of the more obvious NullPointerException bugs in Ajdoc were fixed,
 but Ajdoc does not implement all the functionality of Javadoc and has
@@ -977,7 +1023,8 @@ command line
 Further, Ajdoc has not been testing on variants of the J2SE (it uses
 javadoc classes).
 
-=== [#1.0rc3taskdefs]#Ant taskdefs#
+[[_1_0rc3taskdefs]]
+=== Ant taskdefs
 
 The Ajc taskdef was updated to support the new compiler options and the
 .aj extension, and some NullPointerException bugs were fixed (thanks to
@@ -988,23 +1035,27 @@ $\{ant.home}/lib.
 
 '''''
 
-== [#1.0rc2]#1.0rc2#
+[[_1_0rc2]]
+== 1.0rc2
 
-* xref:#1.0rc2language[Language]
-* xref:#1.0rc2compiler[Compiler]
-* xref:#1.0rc2ajde[AJDE]
+* xref:#_1_0rc2language[Language]
+* xref:#_1_0rc2compiler[Compiler]
+* xref:#_1_0rc2ajde[AJDE]
 
-== [#1.0rc2language]#Language#
+[[_1_0rc2language]]
+== Language
 
 There are no language changes in this release. This is a bug fix release
 only.
 
-== [#1.0rc2compiler]#Compiler#
+[[_1_0rc2compiler]]
+== Compiler
 
 A bug in handling inner type names that conflict with enclosing type
 names was fixed. Many error messages were improved.
 
-== [#1.0rc2ajde]#AJDE#
+[[_1_0rc2ajde]]
+== AJDE
 
 * This is a bug fix release only.
 
@@ -1058,13 +1109,15 @@ properly when changing directories.
 
 '''''
 
-== [#1.0rc1]#1.0rc1#
+[[_1_0rc1]]
+== 1.0rc1
 
-* xref:#1.0rc1language[Language]
-* xref:#1.0rc1compiler[Compiler]
-* xref:#1.0rc1ajde[AJDE]
+* xref:#_1_0rc1language[Language]
+* xref:#_1_0rc1compiler[Compiler]
+* xref:#_1_0rc1ajde[AJDE]
 
-== [#1.0rc1language]#Language#
+[[_1_0rc1language]]
+== Language
 
 Some of the details of the specification for perthis and pertarget have
 changed. These changes make these language constructs implementable on
@@ -1080,7 +1133,8 @@ is serialized or cloned, and rather than make an arbitrary choice right
 now we've chosen to leave the most room to design them right in a future
 release.
 
-== [#1.0rc1compiler]#Compiler#
+[[_1_0rc1compiler]]
+== Compiler
 
 ajc now directly generates .class files without using javac as a
 back-end. This should result in improved compiler performance, better
@@ -1098,7 +1152,8 @@ correctly when compiling against the jdk1.4 libraries. In addition, this
 release of ajc will run under SUN's jdk1.4beta2. However, we still
 strongly recommend that most users use the non-beta jdk1.3.
 
-== [#1.0rc1ajde]#AJDE#
+[[_1_0rc1ajde]]
+== AJDE
 
 * The structure view can now be configured (using the "Options" dialog)
 to display different kinds of associations between program elements that
@@ -1151,14 +1206,16 @@ computational overhead.
 
 '''''
 
-== [#1.0beta1]#1.0beta1#
+[[_1_0beta1]]
+== 1.0beta1
 
-* xref:#1.0beta1language[Language]
-* xref:#1.0beta1compiler[Compiler]
-* xref:#1.0beta1ajbrowser[AJBrowser]
-* xref:#1.0beta1ajde[AJDE]
+* xref:#_1_0beta1language[Language]
+* xref:#_1_0beta1compiler[Compiler]
+* xref:#_1_0beta1ajbrowser[AJBrowser]
+* xref:#_1_0beta1ajde[AJDE]
 
-== [#1.0beta1language]#Language#
+[[_1_0beta1language]]
+== Language
 
 There is one language change since 1.0alpha1. The static modifier is no
 longer needed or allowed on pointcut declarations. Name binding for
@@ -1171,7 +1228,8 @@ design of this part of the language will almost certainly see some
 changes in the next release to address issues of implementability on the
 JVM as well as related issues.
 
-== [#1.0beta1compiler]#Compiler#
+[[_1_0beta1compiler]]
+== Compiler
 
 The ajc compiler should now catch all errors in source code and you
 should no longer see errors coming from files in 'ajworkingdir'. Please
@@ -1183,7 +1241,8 @@ should work correctly in this release. Thanks to Morgan Deters for a
 very thorough bug report on this broken feature days after the 1.0alpha1
 release.
 
-== [#1.0beta1ajbrowser]#AJBrowser#
+[[_1_0beta1ajbrowser]]
+== AJBrowser
 
 * Support for executing classes has been added.
 * .lst can now be passed as arguments on the command line.
@@ -1192,7 +1251,8 @@ release.
 ** In order to execute classes they must be available on the classpath
 that the browser is launched with.
 
-== [#1.0beta1ajde]#AJDE#
+[[_1_0beta1ajde]]
+== AJDE
 
 * The performance and UI of the structure tree has been improved.
 * Compilation now runs in a separate thread and a progress monitor is
@@ -1236,22 +1296,24 @@ beanshell is no longer required for use of these modes.
 
 '''''
 
-== [#1.0alpha1]#1.0alpha1#
+[[_1_0alpha1]]
+== 1.0alpha1
 
 This is the first alpha release of the 1.0 language and tools. There
 have been many changes in the language, and many improvements to the
 tools. We wish to thank our users for putting up with the high
 volatility of AspectJ in the push to 1.0.
 
-* xref:#1.0alpha1language[Language]
-* xref:#1.0alpha1compiler[Compiler]
-* xref:#1.0alpha1documentation[Documentation]
-* xref:#1.0alpha1ajdoc[AJDoc]
-* xref:#1.0alpha1ant[Ant]
-* xref:#1.0alpha1ajbrowser[AJBrowser]
-* xref:#1.0alpha1ajde[AJDE]
+* xref:#_1_0alpha1language[Language]
+* xref:#_1_0alpha1compiler[Compiler]
+* xref:#_1_0alpha1documentation[Documentation]
+* xref:#_1_0alpha1ajdoc[AJDoc]
+* xref:#_1_0alpha1ant[Ant]
+* xref:#_1_0alpha1ajbrowser[AJBrowser]
+* xref:#_1_0alpha1ajde[AJDE]
 
-=== [#1.0alpha1language]#Language#
+[[_1_0alpha1language]]
+=== Language
 
 There have been many changes to make the 1.0 language both simpler and
 more powerful. User feedback has driven most of these design changes.
@@ -1282,7 +1344,7 @@ calls executions gets sets handlers initializations
 staticinitializations
 ____
 
-have been xref:porting.adoc#1.0a1-plural-to-singular[changed] to be
+have been xref:porting.adoc#_1_0a1-plural-to-singular[changed] to be
 singular rather than plural nouns
 
 ____
@@ -1297,18 +1359,18 @@ mean "and".
 You'll notice that `receptions` doesn't appear on the table as being
 shortened to `reception`. That's because call and reception join points
 have been merged, and the `receptions` pointcut declaration has been
-xref:porting.adoc#1.0a1-remove-receptions[eliminated]. Now, `call` join
+xref:porting.adoc#_1_0a1-remove-receptions[eliminated]. Now, `call` join
 points describe the action of making a call, including both the caller
 and callee. Eliminating reception join points makes AspectJ much simpler
 to understand (reception join points were a commonly misunderstood
 feature) without giving up expressive power.
 
-We have xref:porting.adoc#1.0a1-fixing-state-access[changed the
+We have xref:porting.adoc#_1_0a1-fixing-state-access[changed the
 mechanism for accessing state] at join points, which has the benefit of
 making our treatment of signatures
-xref:porting.adoc#1.0a1-no-subs-in-sigs[cleaner] and easier to read. As
+xref:porting.adoc#_1_0a1-no-subs-in-sigs[cleaner] and easier to read. As
 a part of this, the `instanceof` pointcut designator has now been
-xref:porting.adoc#1.0a1-fixing-instanceof[split into two different
+xref:porting.adoc#_1_0a1-fixing-instanceof[split into two different
 pointcut designators], `this` and `target`, corresponding to a join
 point's currently executing object and target object, respectively.
 
@@ -1321,18 +1383,18 @@ object.
 
 AspectJ's notion of object construction and initialization, a
 complicated process in Java, has been clarified. This affects some uses
-of the xref:porting.adoc#1.0a1-initializations[initializations pointcut]
-and xref:porting.adoc#1.0a1-constructor-calls[constructor calls]
+of the xref:porting.adoc#_1_0a1-initializations[initializations pointcut]
+and xref:porting.adoc#_1_0a1-constructor-calls[constructor calls]
 pointcut.
 
-The little-used pointcuts xref:porting.adoc#1.0a1-hasaspect[`hasaspect`]
-and xref:porting.adoc#1.0a1-withinall[`withinall`] have been removed.
+The little-used pointcuts xref:porting.adoc#_1_0a1-hasaspect[`hasaspect`]
+and xref:porting.adoc#_1_0a1-withinall[`withinall`] have been removed.
 
-The `returns` keyword is xref:porting.adoc#1.0a1-user-defined-returns[no
+The `returns` keyword is xref:porting.adoc#_1_0a1-user-defined-returns[no
 longer necessary] for user-defined pointcuts.
 
 Pointcuts may now be declared `static`, and
-xref:porting.adoc#1.0a1-static-pointcuts[only static pointcuts] may be
+xref:porting.adoc#_1_0a1-static-pointcuts[only static pointcuts] may be
 declared in classes and referred to with qualified references (such as
 `MyAspect.move()`).
 
@@ -1343,34 +1405,34 @@ We have finally added an extremely general pointcut,
 
 ==== Type patterns
 
-Our treatment of xref:porting.adoc#1.0a1-new-wildcards[* and ..] in type
+Our treatment of xref:porting.adoc#_1_0a1-new-wildcards[* and ..] in type
 patterns is cleaner.
 
 Type patterns now have the ability to include array types, and there is
 a new wildcard, +, to pick out all subtypes of a given type. Previously,
 the subtypes operator was only allowed in introduction, and was
-xref:porting.adoc#1.0a1-subtypes-to-plus[spelled differently].
+xref:porting.adoc#_1_0a1-subtypes-to-plus[spelled differently].
 
 ==== Advice
 
 Around advice is treated much more like a method, with a
-xref:porting.adoc#1.0a1-around-returns[return value] and an optional
-xref:porting.adoc#1.0a1-around-throws[throws clause].
+xref:porting.adoc#_1_0a1-around-returns[return value] and an optional
+xref:porting.adoc#_1_0a1-around-throws[throws clause].
 
 The advice precedence rules have been
-xref:porting.adoc#1.0a1-advice-precedence[changed]. Now, for example, a
+xref:porting.adoc#_1_0a1-advice-precedence[changed]. Now, for example, a
 piece of after advice that appears lexically later than another piece of
 after advice will run later, as well. Previously, the relationship was
 the other way around, which caused no small amount of confusion.
 
 After returning advice has lost a
-xref:porting.adoc#1.0a1-after-returning[useless set of parentheses] when
+xref:porting.adoc#_1_0a1-after-returning[useless set of parentheses] when
 not using the return value.
 
 The `thisStaticJoinPoint` reflective object has been
-xref:porting.adoc#1.0a1-this-static-join-point[renamed], and the
+xref:porting.adoc#_1_0a1-this-static-join-point[renamed], and the
 `thisJoinPoint` object hierarchy has been
-xref:porting.adoc#1.0a1-this-join-point[simplified].
+xref:porting.adoc#_1_0a1-this-join-point[simplified].
 
 ==== Introduction and static crosscutting
 
@@ -1378,7 +1440,7 @@ On the static side of the language, introduction hasn't changed, but
 there is now a new keyword, `declare`, that is used to declare various
 statically-crosscutting properties. One of these properties is
 subtyping, so we've
-xref:porting.adoc#1.0a1-plus-implements-extends[gotten rid of] the ugly
+xref:porting.adoc#_1_0a1-plus-implements-extends[gotten rid of] the ugly
 keywords `+implements` and `+extends`.
 
 We have provided two new forms, `declare error` and `declare warning`,
@@ -1389,13 +1451,13 @@ AspectJ's interaction with checked exceptions is now firmly on the side
 of static crosscutting, since Java treats such exceptions at
 compile-time. A new form, `declare soft`, can be used to "soften"
 checked exceptions into an unchecked form. This may affect some uses of
-xref:porting.adoc#1.0a1-now-use-soft[around advice] that previously
+xref:porting.adoc#_1_0a1-now-use-soft[around advice] that previously
 mucked with the exception checking system.
 
 ==== Aspects
 
 The "of each" modifiers have been
-xref:porting.adoc#1.0a1-aspects[renamed]. Apart from the spelling, the
+xref:porting.adoc#_1_0a1-aspects[renamed]. Apart from the spelling, the
 main interesting difference is the splitting up of `of eachobject` into
 two different modifiers, parallel with the split of `instanceof` into
 `this` and `target`.
@@ -1405,7 +1467,8 @@ This allows an aspect A, for example, to declare that its advice should
 dominate the advice of another aspect B as well as its subtypes, with
 the new + subtypes operator: `aspect A dominates B+`.
 
-=== [#1.0alpha1compiler]#Compiler#
+[[_1_0alpha1compiler]]
+=== Compiler
 
 The most important change in the compiler is that it supports the new
 language. In addition, all reported bugs in the last release have been
@@ -1428,7 +1491,8 @@ Many semantic errors are not caught by ajc but fall through to javac.
 Moreover, some errors regarding the initialization of final fields might
 never show up when using ajc. This will be fixed shortly.
 
-=== [#1.0alpha1documentation]#Documentation#
+[[_1_0alpha1documentation]]
+=== Documentation
 
 Although we spent much of our time this release cycle updating the
 documentation to the new language rather than improving its content, we
@@ -1438,7 +1502,8 @@ Environment Guide, covering the develompent tools. In addition,
 printable versions of both guides (in PDF) are finally included in the
 documentation package.
 
-=== [#1.0alpha1ajdoc]#Ajdoc#
+[[_1_0alpha1ajdoc]]
+=== Ajdoc
 
 Ajdoc was rewritten to conform with the language changes and provide
 support for other AspectJ/Java compilers. Our doclet is used by default
@@ -1446,18 +1511,21 @@ creating AspectJ-specific documentation, or Sun's standard doclet can be
 used by passing the '-standard' flag to Ajdoc to produce regular Javadoc
 documentation (excluding AspectJ-specifics).
 
-=== [#1.0alpha1ant]#Ant#
+[[_1_0alpha1ant]]
+=== Ant
 
 An Ajdoc task is now available. The Ajc ant task was improved to be
 completely back-compatible with the Javac task.
 
-=== [#1.0alpha1ajbrowser]#AJBrowser#
+[[_1_0alpha1ajbrowser]]
+=== AJBrowser
 
 The "AspectJ Browser" is a new standalone source code browsing
 application. It will let you compile ".lst" files, view the structure
 for those files and navigate the corresponding source code.
 
-=== [#1.0alpha1ajde]#AJDE#
+[[_1_0alpha1ajde]]
+=== AJDE
 
 ==== AJDE for JBuilder
 
diff --git a/docs/dist/doc/examples/spacewar/README.adoc b/docs/dist/doc/examples/spacewar/README.adoc
index 624dd0ffc..9991867a3 100644
--- a/docs/dist/doc/examples/spacewar/README.adoc
+++ b/docs/dist/doc/examples/spacewar/README.adoc
@@ -1,10 +1,9 @@
-© Copyright 1997-2001 Xerox Corporation. All rights reserved.
+[[_5]]
+== Exploring the Spacewar Example
 
-*Last updated*: January 10, 2001
+_© Copyright 1997-2001 Xerox Corporation. All rights reserved._
 
-
-
-== [#5]#Exploring the Spacewar Example#
+_Last updated: January 10, 2001_
 
 The code in this directory is an implementation of the classic video
 game Spacewar.
@@ -19,12 +18,14 @@ version of AspectJ correctly installed. If you're not sure you do, try
 the helloworld example first by following the instructions in
 xref:../doc/primer/default.html[Primer] section Getting Started.
 
-=== [#5.1]#Compiling Spacewar#
+[[_5_1]]
+=== Compiling Spacewar
 
 * Change to the `examples` directory.
 * Type `ajc -argfile spacewar/demo.lst` to compile the system.
 
-=== [#5.2]#Running Spacewar#
+[[_5_2]]
+=== Running Spacewar
 
 * In the examples directory, type `java spacewar.Game`
 
@@ -40,7 +41,8 @@ focus so that your keystrokes are recognized.
 
 You can quit the game with ctl-Q.
 
-=== [#5.3]#Exploring the Code#
+[[_5_3]]
+=== Exploring the Code
 
 There is one other built-in configurations for the Spacewar game. Try it
 by typing `ajc @spacewar\debug.lst`. This compiles in an elaborate
diff --git a/docs/dist/doc/index.adoc b/docs/dist/doc/index.adoc
index cfde98826..6e9c0196f 100644
--- a/docs/dist/doc/index.adoc
+++ b/docs/dist/doc/index.adoc
@@ -1,9 +1,8 @@
-[#top]##
-
+[[top]]
 == AspectJ Documentation and Resources
 
-AspectJ ^[.small]#tm#^ is a seamless aspect-oriented extension to
-Java^[.small]#tm#^. The compiler and development tools are available
+AspectJ^TM^ is a seamless aspect-oriented extension to
+Java^TM^. The compiler and development tools are available
 under an open-source license, require Java 1.3 to run, and produce code
 that runs in JDK 1.1 and later VM's. For the latest materials, see
 http://eclipse.org/aspectj. Not all of these materials have been updated
@@ -13,9 +12,9 @@ for AspectJ 5.
 |===
 |+++Section+++ |+++Contents+++
 
-|xref:#documentation[docs] |link:faq.html[FAQ], link:quick5.pdf[Quick
+|xref:#documentation[docs] |xref:../../faq/faq.adoc#faq[FAQ], link:quick5.pdf[Quick
 Reference (AspectJ 5)], link:quick.pdf[Quick Reference (1.2.1)],
-link:adk15notebook/index.html[AspectJ 5 Developer's Notebook],
+xref:../../adk15ProgGuideDB/adk15notebook.adoc[AspectJ 5 Developer's Notebook],
 link:progguide/index.html[programming],
 link:devguide/index.html[development] and
 link:pdguide/index.html[problem diagnosis] guides,
@@ -35,8 +34,7 @@ mailto:aspectj-dev@eclipse.org[developers].
 |xref:#paths[paths] |for those new to AspectJ
 |===
 
-[#documentation]##
-
+[[documentation]]
 === AspectJ documentation
 
 [width="100%",cols="50%,50%",options="header",]
@@ -48,7 +46,7 @@ reference for the AspectJ 5 language.
 |link:quick.pdf[AspectJ Quick Reference] |This is a two-page quick
 reference for the AspectJ language.
 
-|link:adk15notebook/index.html[AspectJ 5 Developer's Notebook]
+|xref:../../adk15ProgGuideDB/adk15notebook.adoc[AspectJ 5 Developer's Notebook]
 (printable link:adk15notebook/printable.html[html]) |This describes the
 changes to the AspectJ language and tools introduced in the AspectJ 5
 Development Kit. These changes are additive, and are not yet reflected
@@ -87,33 +85,33 @@ team.
 runtime classes. JoinPoint shows the state automatically available at
 each join point. See also the link:weaver-api/index.html[Weaver API]
 
-|link:faq.html[FAQ] |Frequently-asked questions about the AspectJ
+|xref:../../faq/faq.adoc#faq[FAQ] |Frequently-asked questions about the AspectJ
 language, tools, and project.
 
 |README's |Changes and porting guide for AspectJ
-link:README-197.html[1.9.7], link:README-196.html[1.9.6],
-link:README-195.html[1.9.5], link:README-194.html[1.9.4],
-link:README-193.html[1.9.3], link:README-192.html[1.9.2],
-link:README-191.html[1.9.1], link:README-190.html[1.9.0],
-link:README-1811.html[1.8.11], link:README-1810.html[1.8.10],
-link:README-189.html[1.8.9], link:README-188.html[1.8.8],
-link:README-187.html[1.8.7], link:README-186.html[1.8.6],
-link:README-185.html[1.8.5], link:README-184.html[1.8.4],
-link:README-183.html[1.8.3], link:README-182.html[1.8.2],
-link:README-181.html[1.8.1], link:README-180.html[1.8.0],
-link:README-174.html[1.7.4], link:README-173.html[1.7.3],
-link:README-172.html[1.7.2], link:README-171.html[1.7.1],
-link:README-170.html[1.7.0], link:README-1612.html[1.6.12],
-link:README-1611.html[1.6.11], link:README-1610.html[1.6.10],
-link:README-169.html[1.6.9], link:README-168.html[1.6.8],
-link:README-167.html[1.6.7], link:README-166.html[1.6.6],
-link:README-165.html[1.6.5], link:README-164.html[1.6.4],
-link:README-163.html[1.6.3], link:README-162.html[1.6.2],
-link:README-161.html[1.6.1], link:README-160.html[1.6.0],
-link:README-154.html[1.5.4], link:README-153.html[1.5.3],
-link:README-152.html[1.5.2], link:README-151.html[1.5.1],
-link:README-150.html[1.5.0], link:README-121.html[1.2.1],
-link:README-12.html[1.2.0], link:README-11.html[1.1], and
+xref:README-197.adoc[1.9.7], xref:README-196.adoc[1.9.6],
+xref:README-195.adoc[1.9.5], xref:README-194.adoc[1.9.4],
+xref:README-193.adoc[1.9.3], xref:README-192.adoc[1.9.2],
+xref:README-191.adoc[1.9.1], xref:README-190.adoc[1.9.0],
+xref:README-1811.adoc[1.8.11], xref:README-1810.adoc[1.8.10],
+xref:README-189.adoc[1.8.9], xref:README-188.adoc[1.8.8],
+xref:README-187.adoc[1.8.7], xref:README-186.adoc[1.8.6],
+xref:README-185.adoc[1.8.5], xref:README-184.adoc[1.8.4],
+xref:README-183.adoc[1.8.3], xref:README-182.adoc[1.8.2],
+xref:README-181.adoc[1.8.1], xref:README-180.adoc[1.8.0],
+xref:README-174.adoc[1.7.4], xref:README-173.adoc[1.7.3],
+xref:README-172.adoc[1.7.2], xref:README-171.adoc[1.7.1],
+xref:README-170.adoc[1.7.0], xref:README-1612.adoc[1.6.12],
+xref:README-1611.adoc[1.6.11], xref:README-1610.adoc[1.6.10],
+xref:README-169.adoc[1.6.9], xref:README-168.adoc[1.6.8],
+xref:README-167.adoc[1.6.7], xref:README-166.adoc[1.6.6],
+xref:README-165.adoc[1.6.5], xref:README-164.adoc[1.6.4],
+xref:README-163.adoc[1.6.3], xref:README-162.adoc[1.6.2],
+xref:README-161.adoc[1.6.1], xref:README-160.adoc[1.6.0],
+xref:README-154.adoc[1.5.4], xref:README-153.adoc[1.5.3],
+xref:README-152.adoc[1.5.2], xref:README-151.adoc[1.5.1],
+xref:README-150.adoc[1.5.0], xref:README-121.adoc[1.2.1],
+xref:README-12.adoc[1.2.0], xref:README-11.adoc[1.1], and
 xref:porting.adoc[1.0].
 
 |link:changes.html[Changes] |Changes between the latest releases.
@@ -124,7 +122,7 @@ tracing library, and a game application where aspects handle display
 updating.
 |===
 
-[#distributions]##
+[[distributions]]
 
 === AspectJ distributions
 
@@ -151,7 +149,7 @@ available under the Apache Software License from the java.net project
 site https://jdeveloperaop.dev.java.net/
 |===
 
-[#resources]##
+[[resources]]
 
 === Other AspectJ resources
 
@@ -190,8 +188,7 @@ workshops, conferences, and technology releases. Use discuss@aosd.net
 for general AOSD discussions.
 |===
 
-[#paths]##
-
+[[paths]]
 === Suggested paths for those new to AspectJ
 
 To learn the AspectJ language, read the
@@ -215,12 +212,12 @@ code the compiler controls.)
 
 To plan how to adopt AspectJ into a project, read the
 link:progguide/index.html[Programming Guide] on development- and
-production-time aspects and the link:faq.html[FAQ] entries for
-faq.html#q:startUsingAJ[How should I start using AspectJ?],
-link:faq.html#adoption[Deciding to adopt AspectJ], the Development tools
-sections (faq.html#q:integrateWithDevTools[one],
-link:faq.html#devtools[two], link:faq.html#ltw[Load-time weaving] ), and
-faq.html#q:opensource[AspectJ as open-source].
+production-time aspects and the FAQ entries for
+xref:../../faq/faq.adoc#howToStartUsing[How should I start using AspectJ?],
+xref:../../faq/faq.adoc#adoption[Deciding to adopt AspectJ], the Development tools
+sections (xref:../../faq/faq.adoc#integrateWithDevTools[How does AspectJ integrate with existing Java development tools?],
+xref:../../faq/faq.adoc#devtools[Integrating AspectJ into your development environment], xref:../../faq/faq.adoc#ltw[Load-time weaving]), and
+xref:../../faq/faq.adoc#opensource[AspectJ as open-source].
 
 Enjoy the language!
 
diff --git a/docs/dist/doc/porting.adoc b/docs/dist/doc/porting.adoc
index 809f85b4f..bc95dc5c7 100644
--- a/docs/dist/doc/porting.adoc
+++ b/docs/dist/doc/porting.adoc
@@ -3,18 +3,19 @@
 
 == AspectJ Porting Notes
 
-* xref:#pre-1.2[Pre-1.2 code]
-* xref:#pre-1.1[Pre-1.1 code]
-* xref:#pre-1.0.4[Pre-1.0.4 code]
-* xref:#pre-1.0rc1[Pre-1.0rc1 code]
-* xref:#pre-1.0beta1[Pre-1.0beta1 code]
-* xref:#pre-1.0alpha1[Pre-1.0alpha1 code]
+* xref:#pre-1_2[Pre-1.2 code]
+* xref:#pre-1_1[Pre-1.1 code]
+* xref:#pre-1_0_4[Pre-1.0.4 code]
+* xref:#pre-1_0rc1[Pre-1.0rc1 code]
+* xref:#pre-1_0beta1[Pre-1.0beta1 code]
+* xref:#pre-1_0alpha1[Pre-1.0alpha1 code]
 * xref:#pre08b3[Pre-0.8beta3 code]
 * xref:#pre08b1[Pre-0.8beta1 code]
 * xref:#pre07b11[Pre-0.7beta11 code]
 * xref:#pre07b10[Pre-0.7beta10 code]
 
-=== [#pre-1.2]#Porting pre-1.2 code to AspectJ 1.2#
+[[pre-1_2]]
+=== Porting pre-1.2 code to AspectJ 1.2
 
 README-12.html contains a discussion of the changes between 1.1 and 1.2.
 The key points are:
@@ -185,7 +186,8 @@ For more information, see bugs including
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=60389[60389],
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=59921[59921].
 
-=== [#pre-1.1]#Porting pre-1.1 code to AspectJ 1.1#
+[[pre-1_1]]
+=== Porting pre-1.1 code to AspectJ 1.1
 
 README-11.html contains a discussion of the language changes from 1.0 to
 1.1. The high points:
@@ -196,14 +198,14 @@ the callee side. So in 1.0 if you compiled a pointcut using `call(..)`
 but only passed the compiler the code for the target of the call, the
 pointcut could be implemented. This is not true for 1.1. To fix this,
 use `execution(..)` in place of `call(..)`, or include all calling
-clients in the compile. (link:README-11.html#NO_CALLEE_SIDE_CALL[more
+clients in the compile. (xref:README-11.adoc#NO_CALLEE_SIDE_CALL[more
 info])
 
 Type-patterns are no longer permitted for the defining type of
 inter-type declarations. Replace the pattern with a type. In many cases,
 you can declare members on an interface type, and then declare that the
 types picked out by the type-pattern implement have the interface as
-their parent. (link:README-11.html#SINGLE_INTERCLASS_TARGET[more info])
+their parent. (xref:README-11.adoc#SINGLE_INTERCLASS_TARGET[more info])
 
 Type-patterns are no longer permitted when specifying `declare soft`.
 Replace the pattern with a literal type.
@@ -211,7 +213,7 @@ Replace the pattern with a literal type.
 Wildcards patterns (`foo..*`) are no longer permitted for `this()`,
 `target()`, or `args()`. Replace the pattern with a literal type or with
 a subtype wildcard (`Type+`).
-(link:README-11.html#INSTANCEOF_ON_WILD[more info])
+(xref:README-11.adoc#INSTANCEOF_ON_WILD[more info])
 
 Conflicts will be reported for no-argument constructors generated by
 compilers when no constructor is defined for a class. That means the
@@ -228,14 +230,14 @@ One fix is to declare a non-conflicting constructor by adding arguments
 (or defining a constructor in the target class); a better fix might be
 to do the work of the declared constructor in advice on the
 initialization join point for the object.
-(link:README-11.html#DEFAULT_CONSTRUCTOR_CONFLICT[more info])
+(xref:README-11.adoc#DEFAULT_CONSTRUCTOR_CONFLICT[more info])
 
 The pointcut designators `within()` and `withincode()` will not pick out
 code within the lexical extent of method-local and anonymous inner types
 (because these are not represented as such in bytecode form). Because
 `within` forms specify staticly-determinable pointcuts, they might be
 used in declare error or declare warning statements, which might produce
-different results. (link:README-11.html#WITHIN_MEMBER_TYPES[more info])
+different results. (xref:README-11.adoc#WITHIN_MEMBER_TYPES[more info])
 
 The compiler will report an error that the form
 `aspect {name} dominates {list}...` is no longer supported. It has been
@@ -245,19 +247,20 @@ replaced by a new declare statement:
 declare precedence : {name} {list}...
 ....
 
-(link:README-11.html#ASPECT_PRECEDENCE[more info])
+(xref:README-11.adoc#ASPECT_PRECEDENCE[more info])
 
 The field set join point now has a return type of `void`. Compiling
 programs using around advice on these join points might cause errors
 unless the return type of the around advice and the result of any
 proceed() call is `Object` or `void`.
-(link:README-11.html#VOID_FIELD_SET[more info])
+(xref:README-11.adoc#VOID_FIELD_SET[more info])
 
 The compiler cannot implement after or around advice for the handler PCD
 because the end of exception handlers is ambiguous in bytecode. Try to
-use before advice. (link:README-11.html#AFTER_HANDLER[more info])
+use before advice. (xref:README-11.adoc#AFTER_HANDLER[more info])
 
-=== [#pre-1.0.4]#Porting pre-1.0.4 code#
+[[pre-1_0_4]]
+=== Porting pre-1.0.4 code
 
 In versions of AspectJ prior to 1.0.4, the compiler was not correctly
 implementing the AspectJ-1.0 language design for some uses of after
@@ -307,7 +310,8 @@ Uses of both of these forms are highleted with compiler warnings in the
 
 '''''
 
-=== [#pre-1.0rc1]#Porting pre-1.0rc1 code#
+[[pre-1_0rc1]]
+=== Porting pre-1.0rc1 code
 
 Aspects can no longer be declared to implement the `Serializable` or
 `Cloneable` interfaces. If you previously used serializable or cloneable
@@ -316,7 +320,8 @@ serialize or clone in objects associated with the aspects.
 
 '''''
 
-=== [#pre-1.0beta1]#Porting pre-1.0beta1 code#
+[[pre-1_0beta1]]
+=== Porting pre-1.0beta1 code
 
 The `static` modifier is no longer allowed on pointcut declarations
 anywhere. Porting is simple; just remove the static declarations when
@@ -329,21 +334,24 @@ now. If you used this feature, now is the right time to remove the
 
 '''''
 
-=== [#pre-1.0alpha1]#Porting pre-1.0alpha1 code#
+[[pre-1_0alpha1]]
+=== Porting pre-1.0alpha1 code
 
 The release of AspectJ 1.0alpha1 involved sweeping cleanups of the
 language to bring it to 1.0 status.
 
-* xref:#1.0a1-pointcuts[Pointcuts]
-* xref:#1.0a1-type-patterns[Type patterns]
-* xref:#1.0a1-advice[Advice]
-* xref:#1.0a1-introduction-and-static[Introduction and static
+* xref:#_1_0a1-pointcuts[Pointcuts]
+* xref:#_1_0a1-type-patterns[Type patterns]
+* xref:#_1_0a1-advice[Advice]
+* xref:#_1_0a1-introduction-and-static[Introduction and static
 crosscutting]
-* xref:#1.0a1-aspects[Aspects]
+* xref:#_1_0a1-aspects[Aspects]
 
-==== [#1.0a1-pointcuts]#Pointcuts#
+[[_1_0a1-pointcuts]]
+==== Pointcuts
 
-===== [#1.0a1-plural-to-singular]#Removing the "s" from pointcuts#
+[[_1_0a1-plural-to-singular]]
+===== Removing the "s" from pointcuts
 
 One of the most pervasive changes in porting code written before
 1.0alpha1 is the change in some of the pointcut names from plural to
@@ -388,7 +396,8 @@ pointcut publicCall(): call(public * *(..));
 Of course, your naming conventions are your own, but throughout these
 porting notes we will be making these changes in our example ports.
 
-===== [#1.0a1-remove-receptions]#Removing the receptions pointcut#
+[[_1_0a1-remove-receptions]]
+===== Removing the receptions pointcut
 
 Perhaps the largest semantic change in the 1.0 language is the removal
 of receptions join points. They have been merged with call join points
@@ -421,7 +430,7 @@ pointcut fooCallees(Foo f): receptions(void f.m());
 pointcut fooCallee(Foo f): target(f) && call(void m());
 ....
 
-Like xref:#1.0a1-fixing-state-access[other pointcuts], receptions
+Like xref:#_1_0a1-fixing-state-access[other pointcuts], receptions
 pointcuts that exposed one or more arguments should be rewritten to use
 the `args` pointcut:
 
@@ -436,7 +445,7 @@ pointcut intPasser(int i, int j):
 
 There are two issues with constructor receptions in particular.
 
-Like xref:#1.0a1-constructor-calls[constructor calls], constructor
+Like xref:#_1_0a1-constructor-calls[constructor calls], constructor
 receptions pointcuts had a dynamic character, in that
 `receptions(C.new())` would capture constructions of not only C classes,
 but also of classes that extended C.
@@ -450,7 +459,7 @@ receptions(C.new())
 call(C+.new())
 ....
 
-Also like xref:#1.0a1-constructor-calls[constructor calls], constructor
+Also like xref:#_1_0a1-constructor-calls[constructor calls], constructor
 receptions allowed access to the constructed object in the same way as
 any other object. Since the only advice possible on constructor
 receptions join points was `after returning` advice, the object was
@@ -479,7 +488,8 @@ after(Point p) returning (): receptions(p.new(int, int)) { ... }
 after() returning (Point p): call(Point+.new(int, int)) { ... }
 ....
 
-===== [#1.0a1-fixing-state-access]#Fixing state access#
+[[_1_0a1-fixing-state-access]]
+===== Fixing state access
 
 In previous versions of AspectJ, state such as the currently executing
 object or a particular argument of a method call could be accessed from
@@ -636,14 +646,15 @@ pointcut usesFoo(Foo f): within(f);
 pointcut usesFoo(Foo f): this(f) && within(Foo);
 ....
 
-===== [#1.0a1-no-subs-in-sigs]#Understanding signatures#
+[[_1_0a1-no-subs-in-sigs]]
+===== Understanding signatures
 
 Now that we have `this`, `target`, and `args` pointcuts, all of our
 signatures are composed of just types, names, and wildcards; there are
 no more parameters.
 
 Also, now that we have the `+` wildcard to pick out
-xref:#1.0a1-subtypes-to-plus[subtypes], we can make signature matching
+xref:#_1_0a1-subtypes-to-plus[subtypes], we can make signature matching
 much more uniform.
 
 Previously, some signatures matched based on subtypes, some based on
@@ -670,7 +681,8 @@ behaviour, simply convert to
 call(void m(Object+))
 ....
 
-===== [#1.0a1-fixing-instanceof]#Removing the instanceof pointcut#
+[[_1_0a1-fixing-instanceof]]
+===== Removing the instanceof pointcut
 
 The intanceof pointcut has been split into two different pointcuts,
 `this` and `target`.
@@ -703,7 +715,8 @@ pointcut setup(Client c): instanceof(c) && calls(Remote Naming.lookup(String));
 pointcut setup(Client c): this(c) && calls(Remote Naming.lookup(String));
 ....
 
-===== [#1.0a1-initializations]#Rewriting the initializations pointcut#
+[[_1_0a1-initializations]]
+===== Rewriting the initializations pointcut
 
 Object initialization join points are now more complicated, and more
 true to Java's execution model. Now they bracket all of the
@@ -721,7 +734,8 @@ initializations(A)
 initialization(A.new(..)) && !execution(A.new(..))
 ....
 
-===== [#1.0a1-constructor-calls]#Understanding constructor calls#
+[[_1_0a1-constructor-calls]]
+===== Understanding constructor calls
 
 Previously, constructor call join points were matched by subtypes, so
 `calls(Foo.new())` would match both calls to create new `Foo` objects,
@@ -736,7 +750,8 @@ So the old `executions(Foo.new())` is now represented by
 In both of these cases, think before using the + operator; it may be
 that you didn't intend subtype matching in the first place.
 
-===== [#1.0a1-hasaspect]#Removing the hasaspect pointcut#
+[[_1_0a1-hasaspect]]
+===== Removing the hasaspect pointcut
 
 The `hasaspect` pointcut is no longer defined, but you can get the same
 behaviour using the new `if` pointcut.
@@ -778,10 +793,11 @@ before(): if(A.hasAspect()) {
 }
 ....
 
-===== [#1.0a1-withinall]#Removing the withinall pointcut#
+[[_1_0a1-withinall]]
+===== Removing the withinall pointcut
 
 The withinall poinctut is no longer defined. You can use a combination
-of within and the xref:#1.0a1-subtypes-to-plus[new subtypes operator],
+of within and the xref:#_1_0a1-subtypes-to-plus[new subtypes operator],
 +, instead. You'll save two characters and be using a simpler and more
 orthogonal language.
 
@@ -791,7 +807,8 @@ withinall(Foo)
 within(Foo+)
 ....
 
-===== [#1.0a1-user-defined-returns]#Removing returns modifier from pointcuts#
+[[_1_0a1-user-defined-returns]]
+===== Removing returns modifier from pointcuts
 
 The returns keyword is no longer necessary for user-defined pointcuts.
 Simply remove it when you find it.
@@ -802,7 +819,8 @@ pointcut publicIntCalls() returns int: calls(public int *(..));
 pointcut publicIntCall(): call(public int *(..));
 ....
 
-===== [#1.0a1-static-pointcuts]#Making some pointcuts static#
+[[_1_0a1-static-pointcuts]]
+===== Making some pointcuts static
 
 In Java, only static members may be accessed by their declaring type
 name, like the static method `Math.max()` can be accessed.
@@ -819,9 +837,11 @@ Porting should be straightforward; just make all your pointcuts in
 classes `static`, and make any pointcut with a qualified reference
 static.
 
-==== [#1.0a1-type-patterns]#Type patterns#
+[[_1_0a1-type-patterns]]
+==== Type patterns
 
-===== [#1.0a1-new-wildcards]#Understanding * and .. in type patterns#
+[[_1_0a1-new-wildcards]]
+===== Understanding * and .. in type patterns
 
 Previous versions of AspectJ treated * and .. too cleverly in type
 patterns, placing restrictions based on what is a package and what is a
@@ -850,7 +870,8 @@ pointcut unaryVoidMethods(): call(void *(*..*));
 pointcut unaryVoidMethod(): call(void *(*));
 ....
 
-===== [#1.0a1-subtypes-to-plus]#Fixing subtypes in introduction#
+[[_1_0a1-subtypes-to-plus]]
+===== Fixing subtypes in introduction
 
 The new + operator is used to normalize the many places you want to use
 subtypes of some types.
@@ -871,9 +892,11 @@ public void (Target0+ || Target1+).accept(Visitor v) {
 }
 ....
 
-==== [#1.0a1-advice]#Advice#
+[[_1_0a1-advice]]
+==== Advice
 
-===== [#1.0a1-around-returns]#Moving the return type of around#
+[[_1_0a1-around-returns]]
+===== Moving the return type of around
 
 The returns keyword is no longer used for around advice. Instead, the
 return type is declared as it is for methods. So,
@@ -884,7 +907,8 @@ around(Point p) returns void: setters(p) { ... }
 void around(Point p): setter(p) { ... }
 ....
 
-===== [#1.0a1-around-throws]#Adding a throws clause to around#
+[[_1_0a1-around-throws]]
+===== Adding a throws clause to around
 
 Around advice must now declare the checked exceptions it throws with a
 `throws` clause, much like a method.
@@ -901,7 +925,8 @@ char around(char c) throws java.io.CharConversionException: converter(c) {
 }
 ....
 
-===== [#1.0a1-advice-precedence]#Understanding advice precedence#
+[[_1_0a1-advice-precedence]]
+===== Understanding advice precedence
 
 In previous versions of AspectJ, advice precedence within an aspect was
 simple: if a piece of advice appeared before another piece, it was more
@@ -954,7 +979,8 @@ aspect A {
 Advice in _different_ aspects is ordered by the normal aspect precedence
 rules of subtyping and the `dominates` modifier.
 
-===== [#1.0a1-after-returning]#Fixing after returning#
+[[_1_0a1-after-returning]]
+===== Fixing after returning
 
 If you use after returning advice and do not need to expose the return
 value, you no longer need to write an empty set of parentheses to
@@ -973,13 +999,15 @@ do not care what `Throwable` is thrown.
 after(Formals) throwing: Pointcut { ... }
 ....
 
-===== [#1.0a1-this-static-join-point]#Renaming thisStaticJoinPoint#
+[[_1_0a1-this-static-join-point]]
+===== Renaming thisStaticJoinPoint
 
 `thisStaticJoinPoint` has been renamed `thisJoinPointStaticPart`, to
 reflect that it is now exactly the static part of `thisJoinPoint`: It
 will return the same object as `thisJoinPoint.getStaticPart()`.
 
-===== [#1.0a1-this-join-point]#Converting access to thisJoinPoint#
+[[_1_0a1-this-join-point]]
+===== Converting access to thisJoinPoint
 
 The `JoinPoint` object hierarchy has been folded into a single class,
 `org.aspectj.lang.JoinPoint`. A common pattern in logging, for example,
@@ -1008,9 +1036,11 @@ before() executions(* myMethod()) {
 
 Some of the method names of `JoinPoint` have been reorganized, as well.
 
-==== [#1.0a1-introduction-and-static]#Introduction and static crosscutting#
+[[_1_0a1-introduction-and-static]]
+==== Introduction and static crosscutting
 
-===== [#1.0a1-plus-implements-extends]#Removing +implements and +extends#
+[[_1_0a1-plus-implements-extends]]
+===== Removing +implements and +extends
 
 The keywords `+implements` and `+extends` no longer exist. Instead,
 AspectJ uses the `declare` form for exactly the same functionality.
@@ -1027,7 +1057,8 @@ MyButton +extends ButtonAdaptor;
 declare parents: MyButton extends ButtonAdaptor;
 ....
 
-===== [#1.0a1-now-use-soft]#Using declare soft#
+[[_1_0a1-now-use-soft]]
+===== Using declare soft
 
 Around advice advice no longer effects the static exception checking of
 Java. This means that the following code previously compiled:
@@ -1072,7 +1103,8 @@ declare soft: IOException:
     withincode(void noExceptionDeclared());
 ....
 
-==== [#1.0a1-aspects]#Aspects#
+[[_1_0a1-aspects]]
+==== Aspects
 
 The syntax of "of each" modifiers has changed. For `of eachcflow` and
 `of eachcflowbelow`, you can simply replace "of each" with "per". So,
@@ -1125,7 +1157,8 @@ object at such join points.
 
 '''''
 
-=== [#pre08b3]#Porting pre-0.8beta3 code#
+[[pre08b3]]
+=== Porting pre-0.8beta3 code
 
 * xref:#cflowTerminology[Changing cflow terminology]
 * xref:#abstractPointcuts[Overriding abstract pointcuts]
@@ -1134,7 +1167,8 @@ object at such join points.
 The following changes are only required when porting code written prior
 to the 0.8beta3 release of AspectJ.
 
-==== [#cflowTerminology]#Changing cflow terminology#
+[[cflowTerminology]]
+==== Changing cflow terminology
 
 Changing pre-0.8beta3 code that uses AspectJ's control-flow-based
 features only requires rewriting occurrences of `eachcflowroot`,
@@ -1190,7 +1224,8 @@ Though in most cases the following is sufficient
 cflow(Pointcut && ! cflowbelow(Pointcut))
 ----
 
-==== [#abstractPointcuts]#Overriding abstract pointcuts#
+[[abstractPointcuts]]
+==== Overriding abstract pointcuts
 
 In previous versions of AspectJ, a concrete aspect would implicitly
 override all of its abstract pointcuts with an empty pointcut. AspectJ
@@ -1228,7 +1263,8 @@ aspect B {
 }
 ----
 
-==== [#recursiveAdvice]#Limiting recursive advice#
+[[recursiveAdvice]]
+==== Limiting recursive advice
 
 Previously, the compiler silently refrained from applying a piece of
 advice to join points within its own advice body. So, for example, in
@@ -1298,7 +1334,8 @@ aspect A {
 
 '''''
 
-=== [#pre08b1]#Porting pre-0.8beta1 code#
+[[pre08b1]]
+=== Porting pre-0.8beta1 code
 
 * xref:#introSyntax[Rewriting introductions]
 * xref:#staticAdvice[Removing static advice]
@@ -1308,7 +1345,8 @@ aspect A {
 The following changes are only required when porting code written prior
 to the 0.8beta1 release of AspectJ.
 
-==== [#introSyntax]#Rewriting introductions#
+[[introSyntax]]
+==== Rewriting introductions
 
 ===== Syntax
 
@@ -1441,7 +1479,8 @@ member onto a class in order to override a protected member that was
 inherited from a superclass, you will have to make this introduction
 public.
 
-==== [#staticAdvice]#Removing static advice#
+[[staticAdvice]]
+==== Removing static advice
 
 Static advice has been removed from the language. Now, every piece of
 advice is non-static, meaning that it will run in the context of an
@@ -1503,7 +1542,8 @@ aspect ComplexTracing of eachobject(cflow(executions(void Main.main(..)))) {
 }
 ----
 
-==== [#aspect-aspect]#Fixing aspect-aspect inheritance#
+[[aspect-aspect]]
+==== Fixing aspect-aspect inheritance
 
 Aspects can now only extend abstract aspects. This restriction may cause
 some redesign of aspect hierarchies. You will probably find that for the
@@ -1560,7 +1600,8 @@ depended on the `SpaceObjectDA` aspect hierarchy exactly mirroring the
 A better way to implement this kind of design aspect is to use private
 introduction, a new feature of AspectJ.
 
-==== [#usingPrivateIntroduction]#Using private introduction#
+[[usingPrivateIntroduction]]
+==== Using private introduction
 
 A common pattern for AspectJ programs that need to associate some state
 with every object of a particular type has been to use aspects that are
@@ -1611,7 +1652,8 @@ association may capture the crosscutting concern best.
 
 '''''
 
-=== [#pre07b11]#Porting pre-0.7beta11 code#
+[[pre07b11]]
+=== Porting pre-0.7beta11 code
 
 * xref:#twoArgumentCalls[Removing two-argument calls]
 * xref:#adviceInClasses[Removing advice from Class declarations]
@@ -1619,7 +1661,8 @@ association may capture the crosscutting concern best.
 The following changes are only required when porting code written prior
 to the 0.7beta11 release of AspectJ.
 
-==== [#twoArgumentCalls]#Removing two-argument calls#
+[[twoArgumentCalls]]
+==== Removing two-argument calls
 
 In AspectJ 0.7beta11, the two-argument `calls` primitive pointcut
 designator was deprecated. Removing these designators will require
@@ -1709,7 +1752,8 @@ This will capture all call join points of methods with signature
 It will also denote any join points if the Thread type does not define
 (possibly abstractly) some `int getPriority()` method, though.
 
-==== [#adviceInClasses]#Removing advice from Class declarations#
+[[adviceInClasses]]
+==== Removing advice from Class declarations
 
 The simplest way to remove an advice declaration from a class is to
 simply define the advice declaration in an inner aspect. So, instead of
@@ -1756,21 +1800,24 @@ appropriate.
 
 '''''
 
-=== [#pre07b10]#Porting pre-0.7beta10 code#
+[[pre07b10]]
+=== Porting pre-0.7beta10 code
 
 * xref:#joinPoints[Changing access to thisJoinPoint]
 
 The following changes are only required when porting code written prior
 to the 0.7beta10 release of AspectJ.
 
-==== [#joinPoints]#Changing access to thisJoinPoint#
+[[joinPoints]]
+==== Changing access to thisJoinPoint
 
 In AspectJ 0.7beta10, access to the reflective object `thisJoinPoint`
 substantially changed. The two parts of this change were the elimination
 of the `runNext()` static method, and the use of an interface hierarchy
 represent the join point object.
 
-===== [#proceed]#`thisJoinPoint.runNext()` to `proceed()`#
+[[proceed]]
+===== `thisJoinPoint.runNext()` to `proceed()`
 
 The elimination of the `runNext()` static method requires almost no
 porting work. An automatic replacement of the string
@@ -1792,7 +1839,8 @@ around advice should be made explicit (prefixing the reference with the
 aspect name or "`this`", depending on whether the field is static or
 not).
 
-===== [#thisJoinPoint]#Using `thisJoinPoint`#
+[[thisJoinPoint]]
+===== Using `thisJoinPoint`
 
 While access to reflective information through `thisJoinPoint` is more
 powerful and regular through its interface hierarchy, the previous uses
diff --git a/docs/faq/faq.adoc b/docs/faq/faq.adoc
index 288870f40..903406d48 100644
--- a/docs/faq/faq.adoc
+++ b/docs/faq/faq.adoc
@@ -1,3 +1,4 @@
+[[faq]]
 = AspectJ FAQ
 
 _Copyright (c) 1997-2001 Xerox Corporation, 2002 Palo Alto Research
@@ -156,6 +157,7 @@ keep. On Windows, no registry settings were added or changed, so nothing
 needs to be undone. Do not install over prior versions, which might have
 different files. Delete the prior version first.
 
+[[howToStartUsing]]
 *Q:* How should I start using AspectJ?
 
 *A:* Many users adopt AspectJ in stages, first using it to understand
@@ -186,6 +188,7 @@ builds.
 This adoption sequence works well in practice and has been followed by
 many projects.
 
+[[integrateWithDevTools]]
 *Q:* How does AspectJ integrate with existing Java development tools?
 
 *A:* AspectJ products are designed to make it easy to integrate AspectJ
@@ -2583,7 +2586,7 @@ JBuilder, and NetBeans through a common API, AJDE.
 *Q:* What are the new features of AspectJ 5?
 
 *A:* All the new features are documented in the
-link:adk15notebook/index.html[AspectJ 5 Developer's Notebook] and the
+xref:../adk15ProgGuideDB/adk15notebook.adoc[AspectJ 5 Developer's Notebook] and the
 link:devguide/index.html[AspectJ Development Environment Guide]. To
 summarize:
 
@@ -2639,6 +2642,7 @@ compilable by Javac, but you can't use the full AspectJ language, and
 you don't enjoy the same level of IDE support for viewing crosscutting
 structure.
 
+[[ltw]]
 *Q:* What's new about the load-time weaving support in AspectJ 5?
 
 *A:* While the AspectJ weaver could be used at load-time in previous
@@ -3289,6 +3293,7 @@ white papers?]
 [[project]]
 == About the AspectJ Project
 
+[[opensource]]
 *Q:* What does the fact that AspectJ is an Open Source Project mean to
 me?
 
diff --git a/docs/pdGuideDB/messages.adoc b/docs/pdGuideDB/messages.adoc
index 087a78de4..ba0ca116a 100644
--- a/docs/pdGuideDB/messages.adoc
+++ b/docs/pdGuideDB/messages.adoc
@@ -73,7 +73,7 @@ version and build date (same as `-verbose` option).
 `-showWeaveInfo` option).
 
 |`org.aspectj.weaving.messages` |Set this system property to enable
-tracing of all compiler messages. See xref:#trace-configuration[???].
+tracing of all compiler messages. See xref:trace.adoc#trace-configuration[Configuring Tracing].
 |===
 
 [cols=",",options="header",]
@@ -93,7 +93,7 @@ warnings associated with the next line of code.
 ===== Advice not woven
 
 This means that the pointcut for the advice did not match, and it should
-be debugged as described in xref:#pointcuts[???].
+be debugged as described in xref:pointcuts.adoc#pointcuts[Debugging Pointcuts].
 
 [[messages-scenarios-ltw]]
 ==== Load-time weaving scenarios
diff --git a/docs/progGuideDB/gettingstarted.adoc b/docs/progGuideDB/gettingstarted.adoc
index 0930d2e44..0dbb85056 100644
--- a/docs/progGuideDB/gettingstarted.adoc
+++ b/docs/progGuideDB/gettingstarted.adoc
@@ -23,7 +23,8 @@ examples illustrate the kinds of aspects programmers may want to
 implement using AspectJ and the benefits associated with doing so.
 Readers who would like to understand the examples in more detail, or who
 want to learn how to program examples like these, can find more complete
-examples and supporting material linked from the https://www.eclipse.org/aspectj/:[AspectJ web site].
+examples and supporting material linked from the
+https://www.eclipse.org/aspectj/[AspectJ web site].
 
 A significant risk in adopting any new technology is going too far too
 fast. Concern about this risk causes many organizations to be
@@ -38,7 +39,7 @@ testing and performance tuning of applications. And, in the section
 following, xref:#starting-production[Production Aspects], we present
 aspects that implement crosscutting functionality common in Java
 applications. We will defer discussing a third category of aspects,
-reusable aspects, until xref:#language[???].
+reusable aspects, until xref:language.adoc[The AspectJ Language].
 
 These categories are informal, and this ordering is not the only way to
 adopt AspectJ. Some developers may want to use a production aspect right
@@ -945,8 +946,8 @@ are also highly modular, making it possible to develop plug-and-play
 implementations of crosscutting functionality.
 
 AspectJ provides more functionality than was covered by this short
-introduction. The next chapter, xref:#language[???], covers in detail
+introduction. The next chapter, xref:language.adoc[The AspectJ Language], covers in detail
 more of the features of the AspectJ language. The following chapter,
-xref:#examples[???], then presents some carefully chosen examples that
+xref:examples.adoc[Examples], then presents some carefully chosen examples that
 show you how AspectJ might be used. We recommend that you read the next
 two chapters carefully before deciding to adopt AspectJ into a project.
diff --git a/docs/progGuideDB/language.adoc b/docs/progGuideDB/language.adoc
index 44f17dcb5..f48cc4290 100644
--- a/docs/progGuideDB/language.adoc
+++ b/docs/progGuideDB/language.adoc
@@ -4,7 +4,7 @@
 [[language-intro]]
 === Introduction
 
-The previous chapter, xref:#starting[???], was a brief overview of the
+The previous chapter, xref:gettingstarted.adoc[Getting Started with AspectJ], was a brief overview of the
 AspectJ language. You should read this chapter to understand AspectJ's
 syntax and semantics. It covers the same material as the previous
 chapter, but more completely and in much more detail.
@@ -187,7 +187,7 @@ In object-oriented programs, there are several kinds of "things that
 happen" that are determined by the language. We call these the join
 points of Java. Join points consist of things like method calls, method
 executions, object instantiations, constructor executions, field
-references and handler executions. (See the xref:#quick[???] for a
+references and handler executions. (See the xref:quickreference.adoc#quick[AspectJ Quick Reference] for a
 complete listing.)
 
 Pointcuts pick out these join points. For example, the pointcut
@@ -415,7 +415,7 @@ aspect A  {
 The `!within(A)` pointcut above is required to avoid the `printPC`
 pointcut applying to the `System.out.println` call in the advice body.
 If this was not present a recursive call would result as the pointcut
-would apply to its own advice. (See xref:#pitfalls-infiniteLoops[???]
+would apply to its own advice. (See xref:pitfalls.adoc#pitfalls-infiniteLoops[Infinite loops]
 for more details.)
 
 ==== Pointcut Parameters
diff --git a/docs/progGuideDB/semantics.adoc b/docs/progGuideDB/semantics.adoc
index 5a3e7fb00..1943aa609 100644
--- a/docs/progGuideDB/semantics.adoc
+++ b/docs/progGuideDB/semantics.adoc
@@ -2487,7 +2487,7 @@ a join point picked out by <Pointcut> where there is no associated
 aspect of type A.
 
 Both `perthis` and `pertarget` aspects may be affected by code the
-AspectJ compiler controls, as discussed in the xref:#implementation[???]
+AspectJ compiler controls, as discussed in the xref:implementation.adoc#implementation[Implementation Notes]
 appendix.
 
 ===== Per-control-flow aspects