ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Quail <>
Subject Re: Un"bat"ing development: how to realize a forked ant
Date Thu, 27 Feb 2003 22:28:56 GMT
I have had a similar problem to you; I'm sure many people do.

One approach I have used successfully is to have an ant target that generates 
your ".sh" and ".bat" files. I've always put that target inside my main 
build.xml file, but you could put it in a "meta" file if you like.

So, when I do a "fresh checkout", I do this:

$ ant setup

This produces two files; ./build.bat and ./ And then I never call 
"ant" again, I do this:

$ ./ code

So, ./build.bat might look like this (it sets up paths and calls Ant):

@echo off
call ant.bat -f new-build.xml %*

And the "setup" target may look like this:
> ---
>     <target name="setup"
>             description="Setup the build.bat front end script">
>         <pathconvert property="" targetos="windows">
>             <path>
>                 <pathelement location="${oracle.home}"/>
>             </path>
>         </pathconvert>
>         <pathconvert property="win32.clover.classpath" refid="clover.classpath"
>                      targetos="windows"/>
>         <echo file="./build.bat">@echo off
> @setlocal
> set PATH=${}\bin\${oci.version};%PATH%
> set CLASSPATH=${win32.clover.classpath}
> call ant.bat -f new-build.xml %*
> @endlocal
>         </echo>
>         <echo>Created ./build.bat</echo>
>     </target>
> ---

You can see that I've used previously defined properties to set up the PATH and 
CLASSPATH, and that I've made sure those properties are in "win32" mode. Those 
previously defined properties can be made developer-specific because we have 
this at the top of the build file:

     <property file="${user.home}/"/>

I'd be interested in what other ant users think of the scheme, and other 
schemes they have used.

On reason I find this scheme particularly useful is that it means I can avoid 
putting 3rd party tool-jars in my ANT_HOME/lib directory, since they are in the 
classpath instead. The reason I dislike putting things in ANT_HOME/lib is that 
I often get a version clash (for example, I might be working on two different 
projects that are using different version of clover.jar).

I also think this is somewhat easy to maintain, because it becomes part of the 
maintainance of the build.xml script... it's not some "extra" set of files. (I 
put build.bat and in the .cvsignore).


Stefan Schulz wrote:
> Hi,
> the goal of my actions is to have a set of scripts, so I can develop and
> deploy a java system with ant using windows as well as unix/linux.
> By now, I have batch files to set several environment variables and
> options for ant, jvm, and thirdparty java-tools. Of course, this is
> awful to maintain, as the environment setting is at least duplicated
> (.bat and .sh).
> Unfortunately, in ant one cannot reset properties or environment
> variables. Hence, I was going to use a "Meta"-build file, which sets the
> needed variables 
> and then calls the real build file by using the java-task with ant.
> Doing so, the new ant task does not find javac anymore. JAVA_HOME is
> incorrect, and setting JAVA_HOME with the java-task is ignored.
> What I would actually need is something like this:
> <ant fork="true" ...><env key="some" value="thing"/></ant>
> Has anyone tried to do something similar or has anyone an idea, why my
> approach fails?
> Hope this is somewhat understandable :)
> Thanks in advance
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message