We all commonly understand that the build processes for the Apache
Java projects are not as mature as the processes for several C-based
GNU projects. Their build process includes a number of scripts that
are very UNIX based--but there are still some things we can learn from
them.
The first is the concept of installation. The Java projects really
assume that all project directories are self contained. That means
that there is no real installation. I have a road map (beyond the
initial build standardization I proposed that got more reaction outside
this list) that can assist.
The GNU standard:
-----------------
Configure script--checks to see if all necessary components are installed.
if not it sets some properties used in generating the make
files. Finally it builds the make files.
Make files--Standard format everyone either knows or learns quickly.
Property scripts--part of the install are scripts whose sole purpose are to
let other build scripts know where a library is, how
to link to it, and what version it is.
The configure script and make files can be comfortably merged into Ant. It
does a wonderful job and is much more elegant than the GNU/Unix style approach.
However, if we use the concept of installation, we have to ensure that we can
handle version matching and library locations.
Now, this can be done with standard property names for Apache project libraries.
A rising convention among Apache projects is aliasing the jar name in the build
script. Kind of like looking for Xerces with the property ${xerces.jar}. This
works well for the library. A simple extension would be to have a "xerces.ver"
property for version checking.
Ant allows the including of property files into the build process, because you
can't really use environment variables. You can either install the necessary
entries in the users .ant.properties file, or create ant scripts that are called
to check set your properties for your jars. The entry would look something like
this:
<ant file="${build.registry}/${xerces.entry}" target="init">
<property name="ver.macro" value="1"/>
<property name="ver.mini" value="4"/>
<property name="ver.micro" value="*"/>
</ant>
The build registry (where all these external files belong) will house
a xerces.xml file with one target in it ("init"). The target will work
like this example:
<project default="init">
<property name="xerces.macro" value="1"/>
<property name="xerces.mini" value="4"/>
<property name="xerces.micro" value="4"/>
<property name="xerces.jar" value="/usr/local/apache/jars/xerces.jar"/>
<target name="init">
<compare fail="true">
<lte>
<option1 value="${xerces.macro}"/>
<option2 value="${ver.macro}"/>
</lte>
<lte>
<option1 value="${xerces.mini}"/>
<option2 value="${ver.mini}"/>
</lte>
<lte>
<option1 value="${xerces.micro}"/>
<option2 value="${ver.micro}"/>
</lte>
<on-fail message="Installed version of Xerces is
${xerces.macro}.${xerces.mini}.${xerces.micro}."/>
</target>
</project>
At least that gives the general idea.
The <compare> function would be new functionality. An alternative would be to
simply provide a version checking function to Ant. It would parse a three part
version and compare something like this:
<target name="init">
<property name="xerces.jar" value="/usr/local/apache/jars/xerces.jar"/>
<property name="xerces.version" value="1.4.4"/>
<property name="xerces.name" value="Xerces"/>
<version-check current="${xerces.version}"
required="${version}"
project="${xerces.name}"/>
</target>
If ${version} contained the value "1.4.*" or "1.4" then the version checker
would pass (the micro position in both of those are unspecified so any would
work). If the required version were higher than the installed version, it
would display a message like this:
"The installed version of ${project} is ${current}.
You need to upgrade to version ${version} or higher."
Where the properties above are replaced with the values in the attributes above.
In our example it would be:
"The installed version of Xerces is 1.4.4.
You need to upgrade to version 1.4 or higher."
This will assist all Apache projects to automatically find and use the desired
jars--and even be able to transform the start scripts to build the classpath
with the installed jars.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
