When I was talking to Sam Ruby during an IRC session, he alluded that
this is not the best approach. However, I haven't seen or heard any
constructive criticism on this. Please, point me to the previous
discussions we all had on the subject of installations. It is important
to me--and I would like to see the competition my proposal had.
Berin Loritsch wrote:
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
