> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 25, 2001 3:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Is this a desirable feature?
>
>
> Bryan Headley <[EMAIL PROTECTED]> wrote:
>
> > That would work, but I want all my properties in a single file, so I
> > can ensure that they stay in sync together.
>
> As something like your example is the only use case for recursive
> property resolution I've seen so far (and my answer to use property
> files instead is always the same as well 8-), I really want to explore
> the benefits of both approaches.
>
> My take so far has been "do we need recursive property resolution? If
> so, let's add it." - and yet I've not been convinced.
>
> So let's start out simple. I have two different build scenarios, DEV
> and STABLE with differing property sets. Let's assume we support
> recursive property resolution, then we have two options (passing in
> either DEV or STABLE as property TYPE):
>
> (a)
>
> <property name="myprop.DEV" value="foo" />
> <property name="myprop.STABLE" value="bar" />
>
> <property name="myprop" value="${myprop.${TYPE}}" />
>
> (b)
>
> <property file="${TYPE}.properties" />
>
> with
>
> [DEV.properties]
> myprop=foo
>
> [STABLE.properties]
> myprop=bar
>
>
> As I always argue that (b) has advantages over (a) I'll leave the
> arguments in favor of (a) to others. Yours is that you have all
> properties in one file and can make sure they stay in sync more
> easily. I'm not sure this is true in the light of my default values
> argument further down ...
>
I like the default properties; I wouldn't use them as a counter-argument to
my problem, but it's a nice feature. My situation is that I use template
files to create configuration scripts -- depending on where I deploy the
product, I have different database names/logins, root directory for weblogic
and my javaBeans, etc. I don't deploy on NT, thankfully, but if I did, I
might have to change config files to refer to "C:\aDirectory" versus
"/aDirectory". In terms of maintainability, here's a real trivial example
from my "global parameter" file,
product1.build.deployment.DEV.dir=${build.deployment.DEV.dir}/${product.prod
uct1.dir}
product2.build.deployment.DEV.dir=${build.deployment.DEV.dir}/${product.prod
uct2.dir}
product1.build.deployment.QA.dir=${build.deployment.QA.dir}/${product.produc
t1.dir}
product2.build.deployment.QA.dir=${build.deployment.QA.dir}/${product.produc
t2.dir}
and then..
product1.build.deployment.dir=${product1.build.deployment.${build.for}.dir}
<!-- Assuming ${build.for} is either "DEV" or "QA" -->
Here's the thing: If I state that the installation root directory, which is
"/opt/aPath", is now changed to "/opt/weblogic/myProducts/aPath", I have to
open several files (one for QA, DEV, PROD, maybe a deployment to NT) and
ensure I have all these settings right.
Personally, what I am seeting is,
product1.build.deployment.QA.dir
-versus-
product1.build.deployment.dir.QA
The former promotes a property name within another property name, hence a
need for a recursive parser. The other doesn't, perhaps at the cost of
clarity. Is the cost too high? No, but I didn't think of "...dir.QA" when
writing the code, nor when I originally posted. But it IS a way out of my
predictament.
>
> [ hack! ]
>
> Stefan
>
