[...], a copy of the UE will be executed and the "real" object [...]
I guess this is where the difference really is. The implementation on how the 'static' reference is resolve is now safer, yet at the user level, the behavior remains the same, with just a new warning thrown in. I wanted us to 'fix' it at the user-level. I can write a target which defines a property and an id'd fileset that depends on this property, so when it's resolve, the fileset will be 'correct' impl-wise but since the property is uses is not defined, because hasn't been executed, it's semantically wrong. The build will go on, and for example non pick up some files, because the property didn't expand in an <include>. Sorry you get a warning now, which is better, but the point of where the build doesn't behaved as expected by the user might be very different from the point when the warning is issued, so easily ignored. In my experience, few people can read error messages, and even fewer read warnings...
> BC is important to me, but when keeping BC means breaking my least > surprises motto, then BC is not my friend any more ;-) --DD I am afraid that ant has a lot of surprises!
And this is bad. That's why Ant is difficult to use for large builds, because the build becomes exponentially difficult to troubleshoot when something goes wrong. I think we need to move toward a policy system where Ant's behavior can be made safer and more deterministic, like forcing to fail on: - not-runtime-defined references - allow or not reference overriding - expansion of non-defined properties - allow or not the property immutability hole of Project.setProperty - etc... --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
