ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: <property file=... problem
Date Wed, 20 Feb 2002 17:18:03 GMT
From: "Erik Hatcher" <>

> ----- Original Message -----
> From: "Magesh Umasankar" <>
> >
> > -1
> Lame.  Sorry.... its just such a globally
> beneficial thing but heck, what do I know.

I am not arguing the beneficiality of being
able to transform keys or values in a
property file before they are loaded in.

> > Though <property environment=.../> has set
> > a precursor of letting in a prefix, providing
> > prefix attribute to <property file=... prefix=.../>
> > is a very short-sighted implementation and
> > is not generic, IMHO.
> It isn't designed to be generic.  Its designed to
> prevent name clashes, that is what environment="env"
> does.  And that is what a prefix="..." would do.
> That is all.

What is it that stops you from designing
it in a generic way?

> requested.  If you want to morph the actual property file elsewhere that
> a different story and no doubt way out of scope for <property>.

Introducing prefixes to keys present in
a property file is morphing, according to

> > want to load only those properties in a
> > properties file that contain the key string
> > "Init" or something like that.
> Again, a really really contrived scenario, of which <property> is out of
> scope for and a very good use-case would have to be made for me to
> touching something like that.

There are quite a few property files
out there which have "sections" of
properties.  If I am interested
in loading just one section, is that
an unreasonable and contrived use-case?

Though this use-case doesn't exactly
address the 'prefix' issue, it shows
that having a generic implementation
opens up possibilites to users.

> > I have already proposed an alternative way to
> > implement this feature - that of transforming
> > keys & values present in a property file before
> > loading them in as Ant properties.
> Thats just a way too "complex" syntax and usage, IMHO.

What is so complex about it?  I agree
it is not as simple as introducing
a prefix attribute, but then, that
same argument can be applied to
most of the tasks that we support.
Anyway, along with its relative
complexity, comes flexibility.

> When you're a filter reader everything
> looks like a nail.

I am just proposing an implementation
like Unix pipes - I find it very useful.

> Sorry Magesh, no offense.... I'm just
> perplexed why this particular issue
> turned into a -1 and a far more complex
> and involved thing.
> Anyway, saved me a bit of coding! :)

If you think I have failed in my attempt
to get through my point of view,
I will degrade my vote to +0.  I can live
with a prefix attribute. And I can
always code up a <loadproperties> task
when I need one ;-)

>     Erik


*  Philosopher: A fool who torments himself  *
*  during life, to be spoken of when dead.   *

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message