> 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, ken1 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
