ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Adams" <kad...@gfs.com>
Subject Re: over-riding properties and the concept of scope
Date Fri, 06 Jul 2001 13:19:24 GMT
The solution that I'm currently using is to look for a user properties file in the user's home
directory (${user.home}/build.user.properties).  This allows users to override certain settings.
 Ideally, I'd like to have that property file load AFTER the build.master.properties file
(the file with the default settings), but Ant doesn't allow me to do that.

My point is that I don't think the current behavior is the *correct* behavior for *Ant* build
infrastructures.  Even if lower property files override master settings, it's still simple
to build the entire project using a standard location, set of tools, etc.  The build engineer
just needs to set his build.user.properties so that it doesn't override any of the default
settings.

I personally like Pete's idea of being able to specify public and private properties.  Having
a way to enforce what properties developers could override in their personal property files
would be great.

Kyle

> I general, this behavior (first definition overrides all others) is
> the *correct* behavior for build infrastructures.  In the case where there
> are low-level buildfiles that are normally called by individual developers,
> while a "meta" buildfile is at the top level normally called by the 
> build/release engineer.  The top-level buildfile may define things to
> ensure everything is done with a consistent set of tools, etc. and possibly
> "publishes" the build to a standard location, while the lower-level
> buildfiles may have appropriate settings for developers.


Mime
View raw message