ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Thoughts about properties
Date Mon, 04 Feb 2002 13:54:28 GMT

As for (1), it seems to me that using an entity reference include doesn't
buy that much.
Won't I still have to put a string (like '&properties') in every build
file?  Won't ANT
still parse the .properties file once for every build file it encounters,
and tell me
'Override ignored for property . . . .". for all but the first build file?
Maybe I
misunderstand what you're saying (I don't know that much about how XML

As for a concrete use case, let me explain what I'm doing.  I've modified
the default
ant wrapper extensively to suit our needs.  In particular, it defines a
number of
-D<name>=<value> pairs.

Other Java projects in the company have cribbed my work (this is the
essence of
software development).  The problem is that these other projects need to
the properties differently.  They could copy my script and change the
values in the
-D<name>=<value> pairs, but this would mean a lot of variations of the ant
floating around in the source tree.  Or we could put a big old 'switch'
statement in
the wrapper, but no one wants that.

So it seems the correct solution is to tell each project to maintain its
own .properties
file.  This way, a single ANT wrapper still works for the entire company.
But this
would be a better solution if it didn't mean that each project must now
modify all
of its build.xml files (either to add the <property> tag or to add a
entity reference).  This can easily be done with a script, but it would
certainly be
slicker if we could simply specify at the command line which .properties
file to use
and be done with it.

Finally, request (2) is simply asking to make properties-handling more
In the same way that different projects need to define their properties
different users will WANT to custom-define certain properties.  So it would
be nice
if we could either pass a '-userpref' option to tell ANT to check for a
.properties file
in ${user.dir}, or by daisy-chaining the .properties files so that ANT
could read one
.properties files and see that it needs to go read another.

The key to dealing with complexity is to add more layers of indirection.


                    "Erik Hatcher"                                                       
                    <jakarta-ant@ehatchersolu       To:     "Ant Users List" <>
          >                      cc:                               
                                                    Subject:     Re: Thoughts about properties
                    02/01/2002 03:59 AM                                                  
                    Please respond to "Ant                                               
                    Users List"                                                          

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
>           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
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
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
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
> act as
> defaults for properties defined in the "child" .properties file, in case
> 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
the current mechanisms are insufficient to accomplish what you'd want?


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

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

View raw message