David,
I'm not sure if you are on ant-dev or not, but after our original e-mails
with Peter's reply that that -propertyfile would be a good idea, I have
implemented it. Its available in the nightly builds right now! :)
I won't argue that indirection is a good thing - I just think the "include"
idea for properties file loading is overkill and unnecessary given the many
options available for indirection in this area already (entity references,
clever use of properties and -D to override user preferences and define
another property file to load, refid trick to do property "nesting", and
probably a few others).
So, you get -propertyfile - its done and available. Property file includes
are a different story though, and I'm "-0" on it (meaning I don't support
it, but won't veto it if someone else wants to implement it).
Erik
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Ant Users List" <[EMAIL PROTECTED]>
Sent: Monday, February 04, 2002 8:54 AM
Subject: Re: Thoughts about properties
>
>
> As for (1), it seems to me that using an entity reference include doesn't
> buy that much.
> Won't I still have to put a string (like '&properties') in every build
> file? Won't ANT
> still parse the .properties file once for every build file it encounters,
> and tell me
> 'Override ignored for property . . . .". for all but the first build file?
> Maybe I
> misunderstand what you're saying (I don't know that much about how XML
> works).
>
> As for a concrete use case, let me explain what I'm doing. I've modified
> the default
> ant wrapper extensively to suit our needs. In particular, it defines a
> number of
> -D<name>=<value> pairs.
>
> Other Java projects in the company have cribbed my work (this is the
> essence of
> software development). The problem is that these other projects need to
> define
> the properties differently. They could copy my script and change the
> values in the
> -D<name>=<value> pairs, but this would mean a lot of variations of the ant
> script
> floating around in the source tree. Or we could put a big old 'switch'
> statement in
> the wrapper, but no one wants that.
>
> So it seems the correct solution is to tell each project to maintain its
> own .properties
> file. This way, a single ANT wrapper still works for the entire company.
> But this
> would be a better solution if it didn't mean that each project must now
> modify all
> of its build.xml files (either to add the <property> tag or to add a
> &properties
> entity reference). This can easily be done with a script, but it would
> certainly be
> slicker if we could simply specify at the command line which .properties
> file to use
> and be done with it.
>
> Finally, request (2) is simply asking to make properties-handling more
> flexible.
> In the same way that different projects need to define their properties
> differently,
> different users will WANT to custom-define certain properties. So it
would
> be nice
> if we could either pass a '-userpref' option to tell ANT to check for a
> .properties file
> in ${user.dir}, or by daisy-chaining the .properties files so that ANT
> could read one
> .properties files and see that it needs to go read another.
>
> The key to dealing with complexity is to add more layers of indirection.
>
> --dave
>
>
>
>
> "Erik Hatcher"
> <jakarta-ant@ehatchersolu To: "Ant Users
List" <[EMAIL PROTECTED]>
> tions.com> cc:
> Subject: Re:
Thoughts about properties
> 02/01/2002 03:59 AM
> Please respond to "Ant
> Users List"
>
>
>
>
>
>
> This is really a topic for ant-dev, but I'll reply here for now...
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> > I would like to suggest two extensions to ant's use of .properties files
> > (maybe ant can already do these things, but between reading the doc
> > and experimenting I didn't see how):
> >
> > 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.
>
> > 2) Support cascading .properties files. That is, define some
> > distinguished string (like 'INCLUDE_PROPERTIES=<filename>'
> > or something) to indicate that once you're done loading the
> > current properties file, then go out and load the specified
one
> > as
> > well.
>
> I'm not fond of this one - it takes control out of the build files hands
> and
> allows properties to be loaded from all over the place. While it seems
> useful, it doesn't really give you anything that you cannot already
> accomplish and opens up the door for properties to be overridden in ways
> that the build file does not desire. The -D provides sufficient power to
> allow the user to override things already.
>
> > I think my reasons for requesting (1) are pretty clear. My reason for
> > requesting (2)
> > is simply that my project has some properties which need to be constant
> > across
> > a given development environment (so all builds would reference a single,
> > environment-specific .properties file), and other properties which may
> > change from
> > one build to the next, and need to be configurable by the end user (and
> > thus
> > driven off a file in ${user.home}). If suggestions (1) and (2) are both
> > implemented,
> > then it would be quite easy to slurp up both sets of propeties exactly
> once
> > for a
> > single build, no matter where in my source tree I'm building. All it
> would
> > require
> > (once the .properties files are defined) is a slight modification to the
> > ant wrapper.
>
>
> Its easy enough to use XML entity references to include a common build
> piece
> in all your build files that handles property loading - in the included
> fragment you'd put <property file="..."/>'s in whatever order you desire.
>
> > Furthermore, the properties defined in the "parent" .properties file
> could
> > act as
> > defaults for properties defined in the "child" .properties file, in case
> a
> > certain user
> > doesn't want to/doesn't know about the user-specific .properties file in
> > their home
> > directory.
> >
> > Just a suggestion.
>
> Interesting, and good, suggestions. Given that these capabilities already
> exist in some form already, its unlikely that this would be implemented in
> Ant 1.x.
>
> Could you provide a simple concrete use-case for why you'd need this and
> how
> the current mechanisms are insufficient to accomplish what you'd want?
>
> Erik
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
