Always use ":leveloffset: +1" with ":doctype: book"

Headlines per ADOC file should start at level 1, not 2. Adjusting the
level offset for books helps to avoid warnings when including book
chapters, but still allows to also use the chapters as stand-alone
documents.

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

1 files changed, 35 insertions, 31 deletions

diff --git a/docs/developer/compiler-weaver.adoc b/docs/developer/compiler-weaver.adoc
index ba1b28260..373a67c05 100644
--- a/docs/developer/compiler-weaver.adoc
+++ b/docs/developer/compiler-weaver.adoc
@@ -1,4 +1,8 @@
-== Guide for Developers of the AspectJ Compiler and Weaver
+= Guide for Developers of the AspectJ Compiler and Weaver
+:doctype: book
+:leveloffset: +1
+
+= Guide for Developers of the AspectJ Compiler and Weaver
 
 _Latest (non-license) content update: 2004-02-20 by jhugunin_
 
@@ -36,7 +40,7 @@ weaving API which can be used to implement ClassLoaders that will weave
 advice into classes dynamically as they are loaded by the virtual
 machine.
 
-=== Compiler front-end (org.aspectj.ajdt.core)
+== Compiler front-end (org.aspectj.ajdt.core)
 
 The front-end of the AspectJ compiler is implemented as an extension of
 the Java compiler from eclipse.org. The source-file portion of the
@@ -61,7 +65,7 @@ binding and some AspectJ augmentation
 . For each source file do a deep parse, annotation/analysis, and then
 code generation
 
-==== Top-level parse tree
+=== Top-level parse tree
 
 Let's trace the following example program through the compiler.
 
@@ -96,7 +100,7 @@ When parsed, this program will produce the following tree.
 
 image:images/top-tree.png[image]
 
-==== PointcutDeclaration processing
+=== PointcutDeclaration processing
 
 Let's look more closely at the pointcut declaration:
 
@@ -112,7 +116,7 @@ declaration. The actual pointcut is parsed by the weaver module. This
 parsing happens as part of the shallow parse phase. This is because this
 information might be needed to implement a declare soft.
 
-==== AdviceDeclaration processing
+=== AdviceDeclaration processing
 
 Next we look at the processing for an advice declaration:
 
@@ -138,13 +142,13 @@ advice is still null. This field is not filled in until the second stage
 of the compiler when full parsing is done on each source file as a
 prelude to generating the classfile.
 
-==== Overview of the main classes in org.aspectj.ajdt.core
+=== Overview of the main classes in org.aspectj.ajdt.core
 
 The main classes in this module are shown in the following diagram:
 
 image:images/ajdt-uml.png[image]
 
-=== Weaving back-end (weaver)
+== Weaving back-end (weaver)
 
 This provides all of the weaving functionality. It has very few
 dependencies to keep the code as small as possible for deployment in
@@ -174,7 +178,7 @@ static shadow. If it could match, it inserts a call to the advice’s
 implementation method guarded by any dynamic testing needed to ensure
 the match.
 
-=== Runtime support library (runtime)
+== Runtime support library (runtime)
 
 This library provides classes that are used by the generated code at
 runtime. These are the only classes that must be redistributed with a
@@ -191,7 +195,7 @@ There are also several packages all under the header org.aspectj.runtime
 that are considered private to the implementation and may only be used
 by code generated by the AspectJ compiler.
 
-=== Mappings from AspectJ language to implementation
+== Mappings from AspectJ language to implementation
 
 [cols=",,",]
 |===
@@ -222,7 +226,7 @@ patterns.DeclareErrorOrWarning
 |pcd |ast.PointcutDesignator |patterns.Pointcut hierarchy
 |===
 
-== Tutorial: implementing a throw join point
+= Tutorial: implementing a throw join point
 
 This tutorial will walk step-by-step through the process of adding a new
 join point to AspectJ for the moment when an exception is thrown. In
@@ -237,14 +241,14 @@ size of your actual code changes will likely be smaller, but you are
 likely to need to be familiar with all of the pieces of the
 implementation described below.
 
-=== Part 1: Adding the join point and corresponding pcd
+== Part 1: Adding the join point and corresponding pcd
 
 The first part of this tutorial will implement the main features of the
 throw join point. We will create a new join point shadow corresponding
 to the athrow instruction and also create a new pointcut designator
 (pcd) for matching it.
 
-==== Step 1. Synchronize with repository and run the existing test suite
+=== Step 1. Synchronize with repository and run the existing test suite
 
 Do a Team->Synchronize With Repository and make sure that your tree is
 completely in sync with the existing repository. Make sure to address
@@ -261,7 +265,7 @@ Run the existing test suite. I currently do this in four steps:
 There should be no failures when you run these tests. If there are
 failures, resolve them with the AspectJ developers before moving on.
 
-==== Step 2. Write a proto test case
+=== Step 2. Write a proto test case
 
 {empty}a. Create a new file in tests/design/pcds/Throw.java
 
@@ -315,7 +319,7 @@ about to execute: call(java.lang.RuntimeException(String))
 PASS Suite.Spec(c:\aspectj\eclipse\tests) 1 tests (1 passed) 2 seconds
 ....
 
-==== Step 3. Implement the new join point shadow kind
+=== Step 3. Implement the new join point shadow kind
 
 Modify runtime/org.aspectj.lang/JoinPoint.java to add a name for the
 Throw shadow kind.
@@ -362,7 +366,7 @@ Shadow.Kind.
 case 12: return Throw;
 ....
 
-==== Step 4. Create this new kind of joinpoint for the throw bytecode
+=== Step 4. Create this new kind of joinpoint for the throw bytecode
 
 Modify weaver/org.aspectj.weaver.bcel/BcelClassWeaver.java to recognize
 this new joinpoint kind. In the method
@@ -450,7 +454,7 @@ we used Member.HANDLER for the kind of the signature of this join point.
 That's clearly not correct. We'll fix that at the end of the lesson as
 part of the clean-up. For now, let's go on with the interesting parts.
 
-==== Step 5. Extend our proto-test to use a pointcut designator for matching
+=== Step 5. Extend our proto-test to use a pointcut designator for matching
 
 Add a second piece of before advice to the test aspect A:
 
@@ -481,7 +485,7 @@ any existing programs that use throw as the name for a user-defined PCD.
 Fortunately because throw is a Java keyword this particular change is
 very safe.
 
-==== Step 6. Extend the PCD parser to handle this new primitive PCD
+=== Step 6. Extend the PCD parser to handle this new primitive PCD
 
 Modify the parseSinglePointcut method in
 weaver/org.aspectj.weaver.patterns/PatternParser.java to add one more
@@ -526,7 +530,7 @@ Make sure that you see the 'about to throw' printed before moving on.
 This shows that the throw PCD is now successfully matching the throw
 join point shadow we added earlier.
 
-==== Step 7. Check that we're properly providing the single thrown argument (and clean-up the test)
+=== Step 7. Check that we're properly providing the single thrown argument (and clean-up the test)
 
 Now that we have a valid pcd for this advice, we can simplify our test
 case. Modify our test aspect A to be the following. In addition to
@@ -557,7 +561,7 @@ a new join point to the AspectJ language and a corresponding PCD to
 match it. This is a good time to take a break before moving on to part
 two.
 
-=== Part 2: Getting the signature of this new join point right
+== Part 2: Getting the signature of this new join point right
 
 We know that throw(catch(Throwable)) is not the right thing to be
 printing for the signature at this join point. What is the correct
@@ -601,7 +605,7 @@ allow dynamic matching in args to select more specific types. In
 general, good AspectJ code should use this dynamic matching anyway to
 correspond to good OO designs.
 
-==== Step 1. Change the signature of the throw pcd
+=== Step 1. Change the signature of the throw pcd
 
 Since we aren't going to recover the static type of the exception
 thrown, we need to fix the parser for the throw pcd to remove this
@@ -683,7 +687,7 @@ passing:
 PASS Suite.Spec(c:\aspectj\eclipse\tests) 1 tests (1 passed) 2 seconds
 ....
 
-==== Part 2. Make a real test case
+=== Part 2. Make a real test case
 
 The pass result from running our test should worry you. Unlike previous
 runs, this test run doesn't show the output from our System.out.println
@@ -734,7 +738,7 @@ we're not matching the throw join point anymore.
 FAIL Suite.Spec(c:\aspectj\eclipse\tests) 1 tests (1 failed) 1 seconds
 ....
 
-==== Step 3. Fix signature matching again
+=== Step 3. Fix signature matching again
 
 In org.aspectj.weaver.patterns.SignaturePattern.matches, we need to
 handle throw signature matching the same way we handle advice signature
@@ -777,7 +781,7 @@ Member.THROW. This problem only shows up when we try to print
 thisJoinPoint. It's showing that we haven't updated the reflection API
 to understand this new signature kind.
 
-==== Step 4. Extend org.aspectj.lang.reflect to understand throw signatures
+=== Step 4. Extend org.aspectj.lang.reflect to understand throw signatures
 
 We need to add a couple of classes to the reflection API to implement
 the throw signature. Because we decided at the beginning of this section
@@ -906,7 +910,7 @@ about to throw: 'java.lang.RuntimeException: expected exception' at throw(throw)
 PASS Suite.Spec(c:\aspectj\eclipse\tests) 1 tests (1 passed) 1 seconds
 ....
 
-==== Step 5. Extend the test for automated coverage of reflection
+=== Step 5. Extend the test for automated coverage of reflection
 
 Modify the before advice to include at least minimal checks of the new
 reflective information:
@@ -927,14 +931,14 @@ working version of the throw join point and there are no obvious pieces
 that we've skipped. Take a break before proceeding to the final phase of
 tests.
 
-=== Part 3: More serious testing
+== Part 3: More serious testing
 
 Now it's time to get a decent testing story. The test work that we will
 do here is probably too little for adding a new join point to the
 aspectj language; however, it should at least give you a sense of what's
 involved.
 
-==== Step 1. Run the test suite again
+=== Step 1. Run the test suite again
 
 Rerun the tests you ran at the beginning of part 1. Any failures that
 occur should be resolved at this point. At the time of writing this
@@ -972,7 +976,7 @@ noted in the release notes for any AspectJ release. Since we're not
 writing documentation in this tutorial, we will move on an fix the test
 case.
 
-==== Step 2. Fix the failing test case
+=== Step 2. Fix the failing test case
 
 Now we need to fix this failing test case. The first step is to copy the
 test specification into our local myTests.xml file. The easiest way to
@@ -1001,7 +1005,7 @@ new expected event between these two:
 
 Run the test suite again to see that this test now passes.
 
-==== Step 3. Extend test coverage to after advice
+=== Step 3. Extend test coverage to after advice
 
 There is a lot we should do now to extend test coverage for this new
 kind of join point. For the purpose of this tutorial, we're just going
@@ -1060,7 +1064,7 @@ property of the orthogonality of the implementation of join points and
 advice. We never had to do any implementation work to make our new join
 point kind work for before and all three kinds of after advice.
 
-==== Step 4. Look at around advice on throw join points
+=== Step 4. Look at around advice on throw join points
 
 Let's create a new test case to see how this new join point interacts
 with around advice.
@@ -1120,7 +1124,7 @@ best design. For the purpose of this tutorial we're once again going to
 make the language design choice that is easiest to implement and press
 on.
 
-==== Step 5. Prohibit around advice on this new join point kind
+=== Step 5. Prohibit around advice on this new join point kind
 
 The easiest solution to implement is to prohibit around advice on throw
 join points. There are already a number of these kinds of rules
@@ -1169,7 +1173,7 @@ following specification:
 
 Run myTests.xml one last time to see both tests passing.
 
-==== Step 6. Final preparations for a commit or patch
+=== Step 6. Final preparations for a commit or patch
 
 You probably want to stop here for the purposes of this tutorial. We've
 pointed out several language design decisions that would need to be