ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [VOTE] include FTP task revisions in 1.6.4 release
Date Sun, 15 May 2005 19:24:38 GMT
Steve Cohen wrote:
> Steve Loughran wrote:
>> Steve Cohen wrote:
>>> Shall the newly added FTP task revisions be incorporated into release 
>>> 1.6.4?
>>> Motivation:
>>> I understand this comes in "under the wire" and may cause justifiable
>>> trepidation among some.  I still favor adding it to the release because:
>>> 1)  The tasks add some important new capabilities (in order of 
>>> importance):
>>>    a) the ability for the "newer" attribute to recognize timezone
>>> differences between client and server
>>>    b) the ability to handle the "all-numeric" timestamp format that
>>> some unixes (Debian for example) are now shipping with.
>>>    c) the ability to handle legacy systems that still use
>>> locale-specific timestamp formatting (becoming rare but still 
>>> encountered).
>>> Documentation of the new features has also been checked in.
>>> 2) Care has been taken to avoid adding new dependency requirements to
>>> Ant.  The new features require commons-net-1.4.0 and the task cannot be
>>> compiled without it, but users with an earlier version of commons-net
>>> can still use the task exactly as before.  Existing scripts will
>>> function exactly as before.
>>> 3) Just to reiterate - in spite of earlier postings the the contrary,
>>> including this in release 1.6.4 WOULD NOT REQUIRE USERS TO UPGRADE
>>> COMMONS-NET.  This has been tested against commons-net-1.2.2 (the
>>> previous recommended system) and all tests passed.
>>> My vote:
>> -1
>> I dont think I've -1'd anything before, at least not in recent memory. 
>> Here is my thinking
>> (a) 1.6.4 is an emergency release to fix some defects that didnt show 
>> up during beta testing
> Fair enough.
>> (b) any feature added now would go into the release without beta 
>> testing. It runs the risk of breaking.
> Fair enough, although it's worth repeating that existing tests that test 
> existing functionality do not break, either with the old commons-net lib 
> or the new.
>> (c) We'd be effectively obliged to maintain the API forever. Its good 
>> to use something in a few of your own build files first to see what 
>> works, and what doesnt.
> What is there about this API compared to any others that Ant is obliged 
> to maintain that you don't like?  This objection is meaningless and 
> insulting.  These features have been extensively tested in commons-net.

Sorry. I dont mean commons-net API changes. What I meant was "any new 
attributes/methods added to ant tasks need to be preserved for eternity, 
so its good to get them right".

> Commons-net is under the jakarta umbrella with an active team of 
> developers.  Meanwhile Ant "maintains" APIs adapting it to various 
> commercial products for which it has no serious maintainers.  I myself 
> maintained the <starteam> tasks for Ant for as long as I had a job that 
> gave me access to a StarTeam server. (late 2003).
> Looking back through CVS at the entire starteam package I find one 
> substantive change made in a year and a half (a NPE fix).  There have 
> been no enhancements, and nothing but boilerplate changes.  Okay, 
> there's probably not too much demand for those tasks and, at any rate, 
> no one has stepped forward.  But please don't put jakarta-commons-net 
> into that bag.

It wasnt intended to. ftp, telnet, rexec, are core, even though I think 
SSH is safer. FTP and telnet are far more common.

> If I sound a little resentful, it's because these changes were designed 
> by me specifically with Ant in mind.  I resisted suggestions from others 
> that would have implemented these changes in fashions that were less 
> compatible with Ant.  Now this effort seems to be being treated as an 
> unwanted intrusion.

No, no no, I am grateful for the changes. We get a lot of grief about 
<Ftp> not handling different countries/tz/platforms, and the stuff in 
there is welcome. Its just I think that an immediate relase of them to 
end users, just because we are doing a no-beta-test-planned release next 
week is too premature.


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

View raw message