Experimentally change image links

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

6 files changed, 19 insertions, 19 deletions

diff --git a/docs/modules/ROOT/pages/developer/compiler-weaver.adoc b/docs/modules/ROOT/pages/developer/compiler-weaver.adoc
index ba1b28260..f5784a983 100644
--- a/docs/modules/ROOT/pages/developer/compiler-weaver.adoc
+++ b/docs/modules/ROOT/pages/developer/compiler-weaver.adoc
@@ -21,7 +21,7 @@ for AspectJ-1.2.
 runtime and must be redistributed with any system built using AspectJ.
 This module has no external dependencies and produces a tiny ~30KB jar.
 
-image:images/overview.png[image]
+image:overview.png[image]
 
 The AspectJ compiler accepts both AspectJ bytecode and source code and
 produces pure Java bytecode as a result. Internally it has two stages.
@@ -94,7 +94,7 @@ aspect A {
 
 When parsed, this program will produce the following tree.
 
-image:images/top-tree.png[image]
+image:top-tree.png[image]
 
 ==== PointcutDeclaration processing
 
@@ -105,7 +105,7 @@ Let's look more closely at the pointcut declaration:
 pointcut entries(Main o): execution(void doit()) && this(o);
 ....
 
-image:images/pointcut-dec.png[image]
+image:pointcut-dec.png[image]
 
 The pointcut declaration is implemented as a subtype of a method
 declaration. The actual pointcut is parsed by the weaver module. This
@@ -131,7 +131,7 @@ postParse, the selector is filled in and several additional arguments
 are added for the special thisJoinPoint forms that could be used in the
 body.
 
-image:images/advice-dec.png[image]
+image:advice-dec.png[image]
 
 At this point the statements field which will hold the body of the
 advice is still null. This field is not filled in until the second stage
@@ -142,7 +142,7 @@ prelude to generating the classfile.
 
 The main classes in this module are shown in the following diagram:
 
-image:images/ajdt-uml.png[image]
+image:ajdt-uml.png[image]
 
 === Weaving back-end (weaver)
 
diff --git a/docs/modules/progguide/pages/examples.adoc b/docs/modules/progguide/pages/examples.adoc
index caa74a620..392db2606 100644
--- a/docs/modules/progguide/pages/examples.adoc
+++ b/docs/modules/progguide/pages/examples.adoc
@@ -287,7 +287,7 @@ aspects, though simple, are not totally trivial.
 The diagram below gives an overview of the aspects and their interaction
 with the class `Point`.
 
-image:images/aspects.png[image]
+image:aspects.png[image]
 
 ===== The `CloneablePoint` aspect
 
@@ -1314,7 +1314,7 @@ is used to connect them. Conference calls between more than two
 customers will involve more than one connection. A customer may be
 involved in many calls at one time.
 
-image:images/telecom.png[image]
+image:telecom.png[image]
 
 ===== The `Customer` class
 
diff --git a/docs/modules/progguide/pages/gettingstarted.adoc b/docs/modules/progguide/pages/gettingstarted.adoc
index b7de29e59..2806d4cad 100644
--- a/docs/modules/progguide/pages/gettingstarted.adoc
+++ b/docs/modules/progguide/pages/gettingstarted.adoc
@@ -60,7 +60,7 @@ The features are presented using a simple figure editor system. A
 is also a `Display`. Most example programs later in this chapter are
 based on this system as well.
 
-image:images/figureUML.png[ UML for the `FigureEditor` example ]
+image:figureUML.png[ UML for the `FigureEditor` example ]
 
 The motivation for AspectJ (and likewise for aspect-oriented
 programming) is the realization that there are issues or concerns that
diff --git a/docs/modules/release/pages/README-1.2.adoc b/docs/modules/release/pages/README-1.2.adoc
index 5aa96f30e..9aa8503d8 100644
--- a/docs/modules/release/pages/README-1.2.adoc
+++ b/docs/modules/release/pages/README-1.2.adoc
@@ -31,7 +31,7 @@ Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler...
 
 * xref:#WEAVE_TIME[Is faster], with weaving completing in less than half
 the time it used to take in many cases.
-[[WEAVE_CHART]]image:images/AspectJ11v12.JPG[image].
+[[WEAVE_CHART]]image:AspectJ11v12.JPG[image].
 * Supports the xref:#LAZY_TJP[-XlazyTjp option] which produces code that
 runs faster and uses less memory in some common cases.
 * Has xref:#INCREMENTAL[much better support for incremental
@@ -453,11 +453,11 @@ everything in the Spacewar example run: +
 
 `ajdoc` sample output for an aspect source file:
 
-image:images/ajdoc1.JPG[image]
+image:ajdoc1.JPG[image]
 
 `ajdoc` sample output for advised methods:
 
-image:images/ajdoc2.JPG[image]
+image:ajdoc2.JPG[image]
 
 [[LTW]]
 ==== A sample script is supplied that supports load-time weaving from the command-line
diff --git a/docs/modules/release/pages/README-1.6.1.adoc b/docs/modules/release/pages/README-1.6.1.adoc
index 5a9009cc8..a59e3b0bb 100644
--- a/docs/modules/release/pages/README-1.6.1.adoc
+++ b/docs/modules/release/pages/README-1.6.1.adoc
@@ -43,7 +43,7 @@ sample piece of source code).
 . 1100 source files, insane aspect (before(): within(*) \{}) (203000
 join points)
 
-image:images/perfSourceCompile_161.jpg[image]
+image:perfSourceCompile_161.jpg[image]
 
 ==== Binary weaving
 
@@ -60,7 +60,7 @@ aspect (121000 join points)
 . Binary weaving rt.jar (~12000 classes) with an insane aspect
 (before(): within(*) \{}) (352000 join points)
 
-image:images/perfBinaryWeave_161.jpg[image]
+image:perfBinaryWeave_161.jpg[image]
 
 ==== Loadtime weaving
 
@@ -73,7 +73,7 @@ aspect
 . Binary weaving tools.jar (~1900 classes) with an insane aspect
 (before(): within(*) \{})
 
-image:images/perfLTW_161.jpg[image]
+image:perfLTW_161.jpg[image]
 
 The refactoring work has also reduced the amount of unnecessary garbage
 created on the heap during the weaving process. The next comparison
@@ -87,7 +87,7 @@ during a weave of tools.jar with a code style trace aspect
 . Second, another run of the same thing
 . Third, this time using the insane aspect
 
-image:images/heapContents_161.jpg[image]
+image:heapContents_161.jpg[image]
 
 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
@@ -113,11 +113,11 @@ discarded.
 First, AspectJ 1.6.0, in which memory was never correctly recovered and
 so an OutOfMemory problem would always occur eventually.
 
-image:images/memLtwStress_160.jpg[image]
+image:memLtwStress_160.jpg[image]
 
 And now AspectJ 1.6.1:
 
-image:images/memLtwStress_161.jpg[image]
+image:memLtwStress_161.jpg[image]
 
 === Incremental compilation
 
diff --git a/docs/modules/release/pages/README-1.6.7.adoc b/docs/modules/release/pages/README-1.6.7.adoc
index ad2769e41..e1abc246f 100644
--- a/docs/modules/release/pages/README-1.6.7.adoc
+++ b/docs/modules/release/pages/README-1.6.7.adoc
@@ -94,9 +94,9 @@ 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.
 
-image:images/167speed.png[image]
+image:167speed.png[image]
 
-image:images/167Memory.png[image]
+image:167Memory.png[image]
 
 === Annotation binding