ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: references: backwards compatibility
Date Tue, 17 Oct 2006 15:15:59 GMT
On 10/17/06, Dominique Devienne <> wrote:
> > Ok, I will get my id reference stuff ready.
> > I do not think that we need a commandline arg or a property, the
> > only thing that is needed is a warning like DD's
> >
> > Warning: Reference y has not been set at runtime, but was found during
> > build file parsing, attempting to resolve. Future versions of Ant may support
> > referencing ids defined in non-executed targets.
> I'm confused... Are you saying we'll leave the loophole of accessing
> refs from non-executed targets, and just print a warning?
> Ant should fail by default in this situation. If someone wants to run
> in full BC mode, perpetuating the old broken ref handling, they *must*
> explicitly say so to Ant, and it should not be the default mode. Since
> Steve says he doesn't want to fix these other builds, then it has to
> be something specified out the build, use a CLI switch or the setting
> of a user property as proposed by Stefan.

I am proposing not complete BC, it is more a fall-back behaviour,
if a reference is requested *and* not found, then the id references are
checked and if found there, a copy of the UE will be executed and
the "real" object will be given to the caller along with an ugle
warning explaining
what is happening. This will mean that the reference bugs found in
Ant 1.6.5 will be fixed (especially the ones triggered by <script>
and <*ant*>), the nasty fall-back behaviour is clearly indicated to the user
by the warning message, and old scripts will still work.

I think that we cannot remove behaviour if we can at all avoid it.
The Ant 1.6.5 reference behaviour has causes a number of tricky bugs,
so it has to be modified, the solution I am proposing will allow fix
the behaviour but allow old scripts that (by accident) rely on
the old behaviour to still work.

I do not like the idea of a *magic* property or command line
option to do this - there are too many already (-noproxy, -noclasspath,

> 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!


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

View raw message