From: wisberg Date: Sat, 29 Jan 2005 11:13:58 +0000 (+0000) Subject: initial support for building aspectj projects X-Git-Tag: Root_AspectJ5_Development~38 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=0c29b719fd084ca521bd2be20b8ce20ecb7b1f5e;p=aspectj.git initial support for building aspectj projects --- diff --git a/build/readme-build-module.html b/build/readme-build-module.html index 2e6897b4f..7309557ef 100644 --- a/build/readme-build-module.html +++ b/build/readme-build-module.html @@ -1,5 +1,7 @@ + AspectJ build module +

AspectJ build

@@ -15,7 +17,7 @@ on running builds and doing testing for the AspectJ project, see

Approach

The AspectJ project source files are broken into modules, the subdirectories of the modules directory. -(To eclipse users, each module is a Java project.) +(To eclipse users, each module is a Java or AspectJ project.) The modules are compiled independently and may be assembled by the build script into the release jar files. All required libraries are checked into the lib module. @@ -49,8 +51,8 @@ The scripts avoid bootstrapping by using a build library jar checked in to lib/build/build.jar. That means code updates in the build module are not reflected in -the build process until the

build.jar produced by 
-building this build module replaces that found in
+the build process until the build.jar produced by 
+building this build module replaces that found in
   lib/build/build.jar.  Once the module update is
   confirmed, the new lib/build/build.jar must be checked in
   to propogate the changes to other users.
@@ -62,7 +64,7 @@ The
 
    BuildModule
 taskdef implements an integrated module or product build.
-Module builds are based on the Eclipse .classpath
+
Module builds are based on the Eclipse .classpath
 file, and can produce
 a jar with the module classes, with two variations: 
 

@@ -77,7 +79,7 @@ If there is a file {moduleName}.mf.txt
 in the module directory, it will be used as the manifest for the
 module jar file.
 
-Product builds are defined by introspection of a 
+
Product builds are defined by introspection of a 
 products subdirectory like 
 products/tools for the AspectJ installer.
 
@@ -85,9 +87,9 @@ These have an install directory for installer resources
 and a dist 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).
+module by Builder.moduleAliasFor(String) (yes, an awful hack).
 
-

+

 
 
Version synchronization
 The version is expressed in the jar manifests, in the Version class, 
@@ -96,7 +98,7 @@ ensures all version expressions
 are aligned.  When not doing or testing release builds, 
 developers use the default "DEVELOPMENT" version.
 
-The build version is set in 
+
The build version is set in 
 build-properties.xml and propogated
 using Ant copy filters out to
 the aspectjrt.jar manifest,
@@ -117,7 +119,7 @@ The scan is dim-witted; do not change the lines flagged in the template
 without also changing the scanning code in the task.
 
 
Temporary aj-{name} and persistant aspectj-{name}
-
+

 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
@@ -131,7 +133,12 @@ When running Ant from eclipse,
 do not use the default Eclipse Ant classpath; remove those jars and
 add all the libraries in ../lib/ant/lib
 as well as in ../lib/junit.
-

+If the build is failing under eclipse or Ant and the problem appears
+to be in the build module, you can run the build directly in eclipse
+(not using the Ant script) by running the skipped JUnit tests in
+
+	testsrc/org/aspectj/internal/build/ModulesTests.java.
+

 
 
Why new or changed modules might not work
 The BuildModule taskdef makes some assumptions about the naming, 
@@ -148,7 +155,7 @@ 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.
-
+

 One workaround is to delete any existing build products 
 before re-creating them.  The problem with this is that Ant provides no 
 notice of that deletes fail when deleting with quiet="on", but when not
@@ -157,7 +164,7 @@ The workaround-workaround would be to create any required directories
 before trying to deleting any files, with the result of creating unused
 empty directories.
 
-

+

 Currently BuildModule tasks forks the Javac command to try to work around
 this problem, but the Zip commands do not work around it.
 
@@ -165,6 +172,6 @@ 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*)
 
-

+