tags:

views:

291

answers:

3

I have a number of file/executable locations that are likely to be different depending on which computer I am running them on, and I would like to abstract these out through ant properties somehow. What's the best way to do this? Is there a system-wide ant setup script that gets called? Or can I make such a script?

+1  A: 

Setup an ant build file called properties.xml, in which you should define the properties that you want to customize.

Here is properties.xml boilerplate I am using for my projects ( I've adapted it from one of the books on Ant ):

<?xml version="1.0" encoding="UTF-8"?>
<project
  name="workspace-properties"
>
  <dirname
    property="workspace-properties.basedir"
    file="${ant.file.workspace-properties}"
  />

  <!--
    ==========================================================
    Load Environment Variables
    ==========================================================
  -->
  <!-- #Load environment variables -->
  <property environment="env" />

  <!-- this is here to deal with the fact that an IntelliJ IDEA build
    has no ant home
  -->
  <property
    name="ant.home"
    value="${env.ANT_HOME}"
  />

  <!-- get Unix hostname, and set to Windows comparable name -->
  <!-- #Trick to get host name x-platform -->
  <property
    name="env.COMPUTERNAME"
    value="${env.HOSTNAME}"
  />

  <!--
    ==========================================================
    Load property files
    Note: the ordering is VERY important.
    ==========================================================
  -->
  <!-- #Allow even users property file to relocate -->
  <property
    name="user.properties.file"
    location="${user.home}/.build.properties"
  />

  <!-- Load the application specific settings -->
  <!-- #Project specific props -->
  <property file="build.properties" />

  <!--
    ==========================================================
    Define your custom properties here.
    You can overwrite them through build.properties and
    ${user.home}/.build.properties
    ==========================================================
  -->

  <property name="myexec1" location="/usr/bin/myexec1"/>
  <property name="myexec2" location="/usr/bin/myexec2"/>

</project>

Important thing here is to come up with as many useful default property values as possible, then you may even never come up with custom build.properties files.

Then you just <import> this file in your project's build.xml.

<project
  name="my-project"
>
  <!-- this is done, so you may import my-project somewhere else -->
  <dirname
    property="my-project.basedir"
    file="${ant.file.my-project}"
  />

  <import file="${my-project.basedir}/relative/path/to/properties.xml"/>

  <target name="using.myexec1">
    <echo message="myexec1=${myexec1}"/>
  </target>
</project>

If you want a custom value for myexec1 in my-project, just drop a custom flat build.properties file in the same directory where build.xml is located.

The build.properties file may look like this:

myexec1=c:/custom/path/to/myexec1.exe
Alexander Pogrebnyak
+3  A: 

I use the more or less standard build.properties and build-local.properties files.

The first contains default values, common to all environments, the second only the exceptions. The first one is checked into subversion while the other is not.

EDIT : copy/pasting Akr's excellent idea

In addition you might have a default properties file for each of the OS or other you might deploy your build system on. These files can be checked in into your version control system as well.

The Ant script would then include all the files as follow (remember: in Ant the first definition wins):

<property file="build-local.properties"/>
<property file="build.properties"/>
<property file="build-${os.name}.properties">
Vladimir
+2  A: 

In addition to Vladimir's solution you might have a default properties file for each of the OS or other you might deploy your build system on. Use the ${os.name} (and other Java system properties) to set up a path. For example

<property file="build-${os.name}.properties">

These files can be maintained and checked in into your version control system as well.

akr
+1 good idea. I have had some trouble with `file:///` and `file://` on different systems and your proposition would nicely handle this case.
Vladimir