ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Ant task and output attribute
Date Thu, 07 Mar 2002 12:08:07 GMT
 --- Conor MacNeill <>
wrote: > > From: Jose Alberto Fernandez
> []
> >
> > From: "Conor MacNeill"
> <>
> >
> > > I have just written a facade for the Ant task in
> mutant and noticed
> > > something odd in the Ant 1.x source. The output
> attribute for the Ant
> > > task is specified as a String. As far as I can
> tell it is never
> > resolved
> > > to the project's base directory. Do you think
> this should be fixed by
> > > changing the parameter to a File. Such a change
> would a minor backward
> > > compatability break but could be considered a
> bug fix.
> > >
> >
> > I think we should just add an additional method
> with the file signature
> > and do the resolving in the method passing a
> String.
> >
> > That way we keep Backward compatibility and fix
> the bug, like we
> > have done before.
> >
> >     public void setOutput(File out) { .... }
> >
> >     public void setOutput(String out) {
> >         setOutput(resolveFile(out));
> >     }
> >
> Jose Alberto,
> What you have proposed is not backward compatible.
> That isn't to say this
> should not be fixed. The above changes the behaviour
> of setOutput(String) to
> resolve the file, which is what it does not do
> currently.

The behaviour must be changed because what it does
today is a bug. It is very clear in ANT that all file
name definitions are supposed to be resolved relative
to ${basedir}. This task is not doing its job because
if I run ant from a directory other than where the
buildfile is I get a file in a different place.

There is no way you can convince me that this is other
than a bug that must be fix.

> Also I don't know which way Introspection would
> choose to go. I have to look
> at the code but I think Magesh added code so it
> would prefer the File
> version over the String version. Therefore even at
> the build file level this
> too would be incompatible. The only way to be
> backward compatible would be
> to have

The way Introspector resolves the methods is
irrelevant. It does not matter if it calls the File or
the String the end result is that the File will be
called with the correct resolution for the filename.
We have done this over and over in the last 4 releases
of the product.

The backward compatibility issue is that there has to
continue to be a method "setOutput(String)" because
someone may be calling that method programmatically
from the code of other tasks. That is the real
backward compatibility issue. And that is solved by
the change as I have described.

> public void setResolvedOutput(File out).
> Pretty ugly. I'd probably lean to saying current
> implementation is incorrect
> and should be fixed, incurring a slight
> compatibility problem.

Ugly indeed and unnecessary. We do not want to pollute
<ant> with a new attribute, we just want the corrent
attribute to do the correct thing.

Jose Alberto

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message