ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Thoughts about properties
Date Fri, 01 Feb 2002 09:59:28 GMT
This is really a topic for ant-dev, but I'll reply here for now...

----- Original Message -----
From: <>
> I would like to suggest two extensions to ant's use of .properties files
> (maybe ant can already do these things, but between reading the doc
> and experimenting I didn't see how):
>      1) Add a '-properties <filename>' to specify a properties file
>           which in effect "globally" for a single ant run.  Obviously
>           it's possible to obtain something close to this functionality
>           by inserting the <properties file=.../> tag at the top of my
>           build file, but if I have my build.xml files set up in a
>           cascading manner (as I do) and want the flexibility to build
>           against any build file in any directory, I have to include the
>           <properties> tag in every single build file.  And I believe that
>           ant will reload that same properties file with each build.xml
>           it parses, which seems like kind of a waste.

This particular case could be implemented by doing this:

<property file="${}"/>

and then:

    ant<path to properties file>

And if that property is not supplied, <property file> will not fail, it just
ignores it.

As for it having to be in every build file... nope.  Look at the FAQ and
using entity reference includes.

>      2) Support cascading .properties files.  That is, define some
>           distinguished string (like 'INCLUDE_PROPERTIES=<filename>'
>           or something) to indicate that once you're done loading the
>           current properties file, then go out and load the specified one
> as
>           well.

I'm not fond of this one - it takes control out of the build files hands and
allows properties to be loaded from all over the place.  While it seems
useful, it doesn't really give you anything that you cannot already
accomplish and opens up the door for properties to be overridden in ways
that the build file does not desire.  The -D provides sufficient power to
allow the user to override things already.

> I think my reasons for requesting (1) are pretty clear.  My reason for
> requesting (2)
> is simply that my project has some properties which need to be constant
> across
> a given development environment (so all builds would reference a single,
> environment-specific .properties file), and other properties which may
> change from
> one build to the next, and need to be configurable by the end user (and
> thus
> driven off a file in ${user.home}).  If suggestions (1) and (2) are both
> implemented,
> then it would be quite easy to slurp up both sets of propeties exactly
> for a
> single build, no matter where in my source tree I'm building.  All it
> require
> (once the .properties files are defined) is a slight modification to the
> ant wrapper.

Its easy enough to use XML entity references to include a common build piece
in all your build files that handles property loading - in the included
fragment you'd put <property file="..."/>'s in whatever order you desire.

> Furthermore, the properties defined in the "parent" .properties file could
> act as
> defaults for properties defined in the "child" .properties file, in case a
> certain user
> doesn't want to/doesn't know about the user-specific .properties file in
> their home
> directory.
> Just a suggestion.

Interesting, and good, suggestions.  Given that these capabilities already
exist in some form already, its unlikely that this would be implemented in
Ant 1.x.

Could you provide a simple concrete use-case for why you'd need this and how
the current mechanisms are insufficient to accomplish what you'd want?


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

View raw message