db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: Gump now builds derby
Date Mon, 14 Feb 2005 23:24:15 GMT
On Fri, 11 Feb 2005 15:10:07 -0800, Daniel John Debrunner
<djd@debrunners.com> wrote:
> I see from the top-level build.xml file that gump required some changes.
> Can you provide an overview of what was required, so that future changes
> to the build files won't break gump.

Hi Dan,

Gump achieves it's cross-project integration by having Ant ignore the
classpath set in a project's <javac> tasks and putting the latest
build of the dependencies listed in the gump project file into the
classpath for each compile, and the Java 1.4 runtime classes are put
onto the bootclasspath as well. For most projects, that is not a
problem, as they expect the JDK 1.4 runtime classes to be available
during the entire build. We are the only project to also need the JDK
1.3 runtime classes (for JDBC 2 support), and selectively at that, so
some tweaks had to be made to our build and to the gump environment in
order to get Derby building there. The main change for us was to
isolate the classes that implement the JDBC 2 interfaces from the rest
of the build. That required splitting the build into seven pieces,
each of which has a separate target in the top-level build file:

gump_split_1: builds everything up to internal api JDBC 2 interfaces
gump_split_2: builds internal api JDBC 2 interfaces
gump_split_3: builds implementation classes up to the JDBC 2 interfaces
gump_split_4: builds implementations of JDBC 2 interfaces
gump_split_5: builds external api up to JDBC 2 interfaces
gump_split_6: builds external api classes for JDBC 2
gump_split_7: builds everything else

In order to build the JDBC 2 classes, it is necessary for Gump to use
Jikes for splits 2, 4, and 6 in order to avoid putting the Java 1.4
classes on the bootclasspath for Javac. Then, it required setting the
property "empty" (currently used to keep Ant from putting the Ant JRE
runtime classes onto Jikes' classpath) to the location of the Java 1.3
runtime classes so that we could get them into the classpath, as the
classpath that we set in our buildfiles is ignored by Ant during the
Gump build, but the bootclasspath value is not. At that point, it
required working around a couple of bugs in Jikes 1.22 to get it to
build, but after that the gump build was successful.

As for preventing future changes from breaking the build, the method
that I used to test was to keep two copies of ant.properties in my
home directory, one which pointed both of the properties j13lib and
j14lib to the 1.3 runtime classes (called ant13.properties), and
another which pointed them both to the jdk1.4 classes (called
ant14.properties). This simulates the gump environment of only having
one version of the runtime classes on the classpath at a time. I then
wrote a simple script that copies the correct version over
ant.properties and runs the appropriate Ant target. While I haven't
investigated it thoroughly, my instinct is that because Ant does not
allow overriding properties once they are set, there is not currently
a way to test the split gump build entirely within Ant without major
changes to the current build. But, here's that simple script,
buildgump.ksh, which works just as well:

#!/bin/ksh
cp ~/ant.properties ~/ant.properties.save
cp ~/ant14.properties ~/ant.properties
ant gump_split_1 && {
  cp ~/ant13.properties ~/ant.properties
  ant gump_split_2
} && {
  cp ~/ant14.properties ~/ant.properties
  ant gump_split_3
} && {
  cp ~/ant13.properties ~/ant.properties
  ant gump_split_4
} && {
  cp ~/ant14.properties ~/ant.properties
  ant gump_split_5
} && {
  cp ~/ant13.properties ~/ant.properties
  ant gump_split_6
} && {
  cp ~/ant14.properties ~/ant.properties
  ant gump_split_7
} 
cp ~/ant.properties.save ~/ant.properties


andrew

Mime
View raw message