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.
