ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdef s
Date Thu, 21 Feb 2002 10:25:10 GMT

> -----Original Message-----
> From: Jon Skeet []
> Sent: Thursday, 21 February 2002 8:11 PM
> To: Ant Developers List
> Subject: RE: cvs commit:
> jakarta-ant/src/main/org/apache/tools/ant/taskdef s
> > > and is
> > >   concerned that users will not look kindly
> > >   upon us getting rid of it.
> > 
> > Changes to task that is exposed to a large group of people 
> > (which ant1.5 has been) negatively effect users experience of 
> > ant. I got people bitching at me 
> > on other lists when ant updated from jarfile -> file, I think 
> > these people would be even more pissed if that was silently removed 
> > again ;)
> This seems to be as good a post as any to put my tuppence-worth 
> in. I'm thinking about Ant2 here - I have no particular views on 
> 1.5. Obviously there are merits to both sides of the 
> deprecation/removal/whatever argument:
> (I'm assuming a build-file conversion utility.)
> Leaving stuff in:
> o Gives more familiarity for users when it comes to recognising 
> their converted files and adding to them
> o Means we don't need a single preferred name
> o Adds to the complexity of the code (in terms of extra methods 
> which are essentially of no use)
> o Adds to the difficulty of reading someone else's build file if 
> they're using undocumented names
> o Keeps existing code which uses varying method calls
> Taking stuff out completely has almost entirely the opposite 
> effects. Deprecating stuff seems to go half way on almost everything.
> It strikes me that aside from the part about choosing a single 
> preferred name, a dedicated alias facility in taskdefs would get 
> round a lot of this. We'd still end up potentially breaking 
> 3rd-party code, but I suspect this is a given for Ant2 anyway. 
> I'd like a taskdef to be able to specify aliases for attributes. 
> The manual could then list those aliases along with the preferred 
> name, and an optional parameter could tell you if you were using 
> any aliases instead of preferred names (along with what the 
> preferred name is). The code could then be cleaned up, and anyone 
> with a "foreign" build file could easily find out what's going on.

Good idea.

One potential problem, though.  One of the problems in Ant 1.x is the fact that once a setter/adder
method has been added to a task/type, it cannot be removed because other tasks/types may be
directly using it.

So, an alias facility would only be feasible if we can prevent that happening in Ant 2 (which
I think we should).  We can deal with that with a decent antlib versioning/dependency story,
or by limiting visibility of types across antlibs.  But certainly not do-able in Ant 1.


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

View raw message