ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Olving" <>
Subject RE: [PATCH] Support for default ProjectHelper to expand properties in attributes to project/target tags
Date Mon, 05 Jan 2004 13:41:26 GMT
> I feel unconfortable about this change. It introduces some sort of
> dynamic programming with I do notknow which consequences. What happens
> when people use <antcall/>?, what happens when depends lists contain
> such variables? I think it is a very bad can or worms, unless we first
> have a rational for it from ANT, the language, semantic point of view.

Hm, ok. My initial thought was mostly surprise that it didn't work - it seemed logical and
consistent to me that it should work in those attributes, just as in other attributes. Maybe
a wrong expectation from me; this may have been a conscious decision early on?

As to what happens...well, I think that it is up to the user to make it behave the way they
expect it to - 'they' have to make sure the property is correctly set or else it doesn't work
as they intended. If they don't want those dynamics, they don't have to use it. All expansions
would happen immediately/statically on parsing, so there are no slippery dynamics of interpreting
properties, in say, depends lists differently at different times during the same run.

Theoretically of course, it could collide with people who actually uses the $[...} construction
as actual target names, but that is most likely a low risk, at a guess?

> Kenneth, in your particular case, why can your particular tool just 
> call "ant bar", I see no reason for limiting to use the 
> default target.

I could but I prefer not to since I want to 'just start the build file' without requiring
that there are particular targets like that. I thought it was a neat way to simply 'jump'
to the right target if someone wanted to code it that way. OTOH, it's hardly critical - as
Steve pointed out, it can be just as simply done with an intermediate target (but I liked
the elegance of not needing that :-).

So the actual 'business case' may simply boil down to basic and added consistency coupled
with a very (?) low risk for backward compat problems? I'm in no position to state that this
couldn't open up other concerns, so I'd be very happy to defer to someone better informed
on possible problems.

Thank you,


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

View raw message