ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Skeet" <>
Subject RE: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdef s
Date Thu, 21 Feb 2002 10:11:14 GMT
> > 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
o Adds to the difficulty of reading someone else's build file if they're using undocumented
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.

Apologies if this is an idea with grave flaws in or which has been brought up before.

View raw message