1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
<html>
<title>AspectJ build</title>
<body>
<h1>AspectJ build</h1>
This build module contains taskdefs and resources for doing builds
and checking source licenses.
<h3>Usage</h3>
<h4>Running the build</h4>
To do a build, use Ant to run <a href="build.xml">build.xml</a>
from this directory. To run Ant, use <a href="../lib/ant">../lib/ant</a>
scripts and libraries.
Consider defining the following flag properties:
<p>
<table cellpadding="1" border="1">
<tr><th>Property</th><th>Meaning</th>
</tr>
<tr><td>module.name
</td><td>To build any module (esp. those not directly supported
by a target), use the "any-module" target and define
the module name.
</td></tr>
<tr><td>check.build.jar
</td><td>any value cause build to fail if
<code>lib/build/build.jar</code> is out of date. (This is a
built archive of the build module to avoid bootstrapping.)
</td></tr>
<tr><td>build.config
</td><td>override default configuration in build.xml.
Significant values include "verbose" for more output
and "useEclipseCompiles" to assume that Eclipse has
compiled modules into their bin directories, and just
assemble those classes.
</td></tr>
</table>
<p>
For example, to build everything into a release bundle,
with verbose logging
<pre>
cd modules/build
../lib/ant/bin/ant
</pre>
To build only the asm module (and any modules it requires):
<pre>
cd modules/build
../lib/ant/bin/ant -f build.xml any-module -Dmodule.name=asm
</pre>
<p>
<h5>Release builds</h5>
Release builds differ only in running
from a clean, up-to-date tree and with correct build version values
in <a href="build-properties.xml">build-properties.xml</a>, which
will update <code>org.aspectj.bridge.Version</code>.
See <a href="#version">Version synchronization</a> below
for more details on how the version is updated.
<p>Do a quick test of the release by running the examples build script:
<pre>
cd {aspect}/doc/examples
ant -f build.xml
</pre>
This should build and run the spacewar example.
To run all examples, use target <code>all</code>.
To run all the examples that do not require manual operation,
use target <code>nonGui</code>.
</p>
<p>
Finally, tag the tree so others can do diffs or create patches
based on the release code. E.g., from the command line:
<pre>
cd org.aspectj/
cvs tag -R -c v1_1_0
</pre>
<p>
<h4>Updating module dependencies and file locations</h4>
Because the BuildModule taskdef extracts dependencies from the Eclipse
<code>.classpath</code> file, there is no need to update build scripts when
adding or removing modules or changing their dependencies, so long
as they are all in the base modules directory (usually the base of
the eclipse workspace.
All required libraries are checked into the <code>lib</code> module.
<p>The BuildModule taskdef makes some assumptions about the naming,
position, and contents of module directories and files.
Understand those (documented in
<a href="src/org/aspectj/internal/tools/ant/taskdefs/BuildModule.java">
BuildModule.java</a>) before using non-standard module directories.
<p>
<h4>Running builds or built jars under Eclipse</h4>
When running Ant from eclipse,
do not use the default Eclipse Ant classpath; remove those jars and
add all the libraries in <a href="../lib/ant/lib">../lib/ant/lib</a>
as well as in <a href="../lib/junit">../lib/junit</a>.
<p>
<u>warning</u>: Jar files do not seem to be closed properly when running under eclipse.
This affects build products (e.g., installers) which are run under eclipse
(e.g., by opening with the "default system editor") and libraries used
when compiling under Javac (if not zip products or input). This problem
presents as files not being writable, i.e., deleted or modified.
Ant provides no notice of the problem when
deleting with quiet="on" (often used to avoid unnecessary errors caused
by trying to delete directories that do not exist).
<p>
Currently BuildModule tasks forks the Javac command to work around
this problem, but the Zip commands do not work around it.
If under Eclipse, you get strange behavior with Ant builds, clear
out everything and build from the command line. In some cases, you
have to exit Eclipse before files can be deleted. (*sigh*)
<h4>Running the test harness</h4>
The <code>build-testing-drivers</code> target builds a single jar with
the AspectJ binaries and a test harness as the main class.
It reads test suite files like
<a href="../tests/ajcTests.xml">../tests/ajcTests.xml</a>.
For more information, see
<a href="../tests/readme-tests-module.html">
../tests/readme-tests-module.html</a>.
<p>
JUnit tests may be run under eclipse or by using Ant to "build"
<a href="../tests/junitModules.xml">../tests/junitModules.xml</a>
(which uses the eclipse module bin directories as its classpath).
<h3>Development</h3>
<h4>BuildModule task</h4>
The
<a href="src/org/aspectj/internal/tools/ant/taskdefs/BuildModule.java">
BuildModule</a>
taskdef implements an integrated module or product build.
<u>Module builds</u> are based on the Eclipse <code>.classpath</code>
file, and can produce
a jar with the module classes, with two variations: (a) include only
the module classes, or assemble the jar complete with all antecedent
modules and libraries; and (b) compile the module(s) without any
testing source or libraries. If there is a file {moduleName}.mf.txt
in the module directory, it will be used as the manifest for the
module jar file.
<u>Product builds</u> are defined by introspection of a
<a href="products">products</a> subdirectory like
<a href="products/tools">products/tools</a> for the AspectJ tools installer.
These have an <code>install</code> directory for installer resources
and a <code>dist</code> directory containing all files belonging in
the distribution, including 0-length placeholders for the module build
results. These placeholder file names are mapped to the originating
module by the task itself (yes, an awful hack).
<h4>Build notes</h4>
<p>
<u>Directory names</u>: Top-level temporary build directories are prefixed "aj-",
so you can safely destroy any such directory or ignore it
in CVS or the Eclipse package explorer. By default the build script
puts them at the same level as other modules. In build scripts, property names
follow a similar convention; those prefixed "aj-" may be deleted at will, while
"aspectj-" names are source directories which should never be deleted.
<p>
<a name="version"></a>
<u>Version synchronization</u>:
Developers use the default "DEVELOPMENT" version unless doing or testing
release builds.
The build version is set in
<a href="build-properties.xml">build-properties.xml</a> and propogated
using Ant copy filters out to
the <a href="../runtime/runtime.mf.txt">aspectjrt.jar manifest</a>,
the <a href="../ajbrowser/ajbrowser.mf.txt">aspectjtools.jar manifest</a>
and to
<a href="../bridge/src/org/aspectj/bridge/Version.java">
../bridge/src/org/aspectj/bridge/Version.java</a>
which the <a href="build.xml">build.xml</a> <code>init-version</code> task
generates from a template
<a href="lib/BridgeVersion.java.txt">lib/BridgeVersion.java.txt</a>.
To avoid updating <code>Version.java</code> whenever
<code>build-properties.xml</code> changes, a task
<a href="src/org/aspectj/internal/tools/ant/taskdefs/VersionUptodate.java">
src/org/aspectj/internal/tools/ant/taskdefs/VersionUptodate.java</a>
determines whether Version.java has the same version by scanning the source file.
The scan is dim-witted; do not change the lines flagged in the template
without also changing the scanning code in the task.
<p>
<hr>
</body>
</html>
|
