I would like to see the FTP task use the same connection if the user is executing several subsequent FTP tasks that use the same server, userid and password. For example, in my current project, I have one FTP task to delete all existing files beneath a given directory, another FTP task to delete the (now empty) subdirectories beneath that same directory, five separate FTP tasks to create five new subdirectories, and five FTP tasks to populate each of those new subdirectories. Each of those tasks needs to connect and disconnect which adds substantially to the elapsed time for these tasks yet all of these tasks are operating against the exact same server with the same userid and password. If these tasks shared the same connection, it would save a lot of time.
This is a very interesting suggestion and I am considering how best to implement it. I have an idea. I'd like some of the other ant developers to chime in on it. Suppose we had an <ftp-connection> data type, with an id, etc. Could we wrap that around a jakarta-commons-net FTPClient object, and keep its connection live? Then we could refer to it via refid in subsequent invocations of the <ftp> task within the same target. Some care would have to be taken to insure that the connection is closed within the target. So ant-dev's please chime in here. Is there any glaring flaw in this plan that would cause it not to work?
Should work fine. :-)
I'd in that case propose an ftp open and a close task, with the other ftp tasks not closing the connection when an id is given.
A better idea might be something like this: <ftp user="me" password="mypassword" server="ftp.big.server" port="21" systemTypeKey="UNIX" serverTimeZone="Asia/Tokyo" > <action name="mkdir" remotedir="public/private"/> <action name="put" remotedir="public/private" newer="true"> <fileset dir="mylocaldir"/> </action> <action name="get" .../> </ftp> This looks like a better plan. Question now is how to do it and still preserve backward compatibility.
or better yet: <ftp user="me" password="mypassword" server="ftp.big.server" port="21" systemTypeKey="UNIX" serverTimeZone="Asia/Tokyo" > <mkdir remotedir="public/private"/> <put remotedir="public/private" newer="true"> <fileset dir="mylocaldir"/> </put> <get .../> </ftp>
This would pretty nearly satisfy bug 33214 as well, wouldn't it?
of course, I didn't see any reason why the connection sharing would have to be all in one target. It seems that you could attempt to close the connection during finalization (worst case). Then the connection could be used across targets and the refid approach still has merit, with the nested action approach being an also-good-but-separate idea.
Do not forget that the ant script may be running in an IDE using one jvm - netbeans for example, so the connection will need to be closed by hand. The nested commands to the ftp task look nice.
(In reply to comment #8) > Do not forget that the ant script may > be running in an IDE using one jvm - netbeans for example, > so the connection will need to be closed by hand. I can't think of any other solution just now, but I still think it would be nice to orchestrate auto-closing of the connection per Ant "invocation" using task invalidation or some existing mechanism. :(
Failing that I suppose we could recommend using a final target as in the posted solution to bug 17973.
(In reply to comment #6) > This would pretty nearly satisfy bug 33214 as well, wouldn't it? Yes, I kind of had that in the back of my mind, too.
(In reply to Antoine Levy-Lambert from comment #2) > Should work fine. :-) In fact, no. Both old (1.4.1) and new (3.6) Commons Net FTPClient only support the Stream Transfer Mode which requires the connection being closed at the end of the transfer. As a consequence, reuse is not possible. The FTPClient doc is quite clear : "FTP.NON_PRINT_TEXT_FORMAT , FTP.STREAM_TRANSFER_MODE , and FTP.FILE_STRUCTURE are the only supported formats, transfer modes, and file structures. " As a conclusion, this bug cannot be solved and could maybe be closed.