> -- which means that complex constructs have to be expressed *in* > Ant, rather than > through scripts or XSLT templates.
I totally agree - it isn't good to assume that the average Ant user has to learn XSLT just to perform some complex tasks. And you definitely can't expect other users of the build file to > > BTW, for its own reasons, I'm still fond of the idea of scoped > properties. As > well as answering the original problem in this discussion, it > would also solve > the problem of sub-builds changing the properties of their parent > builds. I > understand the problem that properties are substituted at parse > time. However, I > am all for changing this to run-time substitution. Why? Because > it's *much* > more intuitive. It behaves like procedural code, which we all > work with every > day. It's easier for beginners to learn, and easier for experts > to work with. > According to Stephan's description, we never need to include our > "init" targets > as dependencies, because they never actually "run". Just the > presence of the > properties makes the rest of the file work, since they're > substituted at parse > time anyway. I don't know about you guys, but this isn't at all > intuitive to me. Yes, the way properties behave is very unintuitive. One would expect a property to be available only if it was "declared" as a previous sibling element of the current task or sibling of one of its parent nodes.
