ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: references: backwards compatibility
Date Tue, 17 Oct 2006 16:24:48 GMT
> [...], 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...


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

View raw message