ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Ray <>
Subject RE: init
Date Thu, 10 Jan 2002 00:37:10 GMT
I do most of mine like Diane.  But I usually have an init target for some
things like <tstamp> and I have a script that converts SunOS to Solaris and
changes the 5.* version numbers to the public ones (2.6, 2.7, 8).  

But I usually include "depends=init" in most of the targets.  

I think it's more of a personal preference thing.  


-----Original Message-----
From: Diane Holt [] 
Sent: Wednesday, January 09, 2002 4:23 PM
To: Ant Users List
Subject: Re: init

--- Joe Cheng <> wrote:
> Is there something wrong with this:
> <target name="init">
>     ... set some properties ...
> </target>
> <target name="compile" depends="init">
>     ... some tasks ...
> </target>
> as opposed to doing the init tasks outside of any target, which is 
> what most examples seem to do?  I moved all that stuff to an init 
> target because now an "available" task needs to be part of it.

The main difference is in when the <property> tasks are evaluated -- before
you added your "init" target, they'd have been evaluated before any targets
were run, so if there are targets other than "compile" that were referencing
the properties you used to set outside of your "init" target, they will now
need to include a 'depends="init"' as well (unless they depend on

For example, if one of the properties you're defining is your build-output
directory (eg., ${out.dir}), and you have, say, a target that copies your
support files into ${out.dir}, that target will now need to depend on
"init", even though "init" may do additional things that your copy target
doesn't need to have happen before it can run (eg., your <available> task).

> I've been working with Ant for a while now but I'm no release 
> engineer, so it's been a struggle trying to figure out what the Ant 
> developers consider the Right way to do a buildfile.

I don't know that there actually is a consensus on "Right". For myself, even
though Ant doesn't really have a "scope" for properties (although the new
"inheritAll" for <ant>/<antcall> sort of introduces that a bit), I still
tend to put what I think of as "global" property-settings in a block at the
top of my build-file, outside of any target. For example:

<!-- ================================================================ -->
<!--                   ProjectFoo build file                          -->
<!-- ================================================================ -->

<project name="Foo" default="all" basedir=".">

<!-- ================================================================ -->
<!--                         Set properties                           -->
<!-- ================================================================ -->

  <property name="properties.dir" value="${ant.home}/lib/properties"/>

  <!-- User settings -->
  <property file="${user.home}/"/>

  <!-- Significant dirs -->
  <property file="${properties.dir}/"/>

  <!-- Compiler settings -->
  <property file="${properties.dir}/${build.compiler}.properties"/>

  <!-- Compile-time classpath properties files -->
  <property file="${properties.dir}/"/>
  <property file="${properties.dir}/"/>

  <!-- Test run-time classpath properties files -->
  <property file="${properties.dir}/${jdk}.properties"/>
  <property name="classpath" value="${codeline.classpath}"/>

  <!-- Product names and release info -->
  <property file="${properties.dir}/"/>
  <property file="${properties.dir}/"/>




Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message