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]>
