On Fri, 1 Feb 2002 20:59, Erik Hatcher wrote: > > 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="${commandline.properties.file}"/> > > and then: > > ant -Dcommandline.properties.file=<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.
I actually think this may be a good idea ;) We already allow users to define UserProperties on the command line but doing a bunch of them is cumbersome and unwieldy. On many occasions you don't always have nicely written build files who all load properties in a consistent and universsal manner. This is particularly painful when integrating multiple different projects built by different people. Essentially loading properties file from commandline would be a shortcut. So instead of goin ant -Da=1 -Db=2 -Dc=3 -Dd=4 ... -Dz=26 you just go ant -propertyfile project.properties and project.properties contains a=1 b=2 c=3 ... z=26 which is much easier to use I guess. -- Cheers, Pete ------------------------------------------ I just hate 'yes' men, don't you Smithers? ------------------------------------------ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>