> > But that doesn't solve problems of Windows vs. Unix builds, because
> > directory paths are significantly different. Environment variables
> > ensure path references are homogeneous across platforms, whereas a
> > build.properties file that specify paths is system
> dependent thing and
> > is generally a bad idea....
>
> eh - say what ?
>
> Ant handle all that!
> If you just make a build.properties and uses thoese from within ant -
> then you have platform independence out of the box! No
> problem with it!
>
The problem I saw with a common build.properties file is that if a user changes it for their particular workstation, and they do a cvs update of the whole tree, it will be overwritten (flagging their local file to be checked against the updated version). Environment variables do not have this problem, since a cvs checkout/update doesn't overwrite environment variables.
That being said (as my initial rationale), I see a smart checking system for properties files (as you said). First I will load a default.build.properties file, then a ${basedir}/build.properties file (if it exists, to override any values that were in the default file), and finally a ${user.home}/hibernate.build.properties (if it exists, to override any values read in so far).
I think this will accomplish what I usually use environment variables for, and it won't have any problems of overwriting their locally modified properties files (because those won't be in cvs as they are machine dependent)...
So basically, I'm trying to say that the properties "smart checking" approach will work in the same way that env vars work, so the env var discussion is now mute ;)
Les
