ok, clear enough.
I'll look into the source code of the ftp task and play around with it a
bit.
Another suggestion for that task is to allow retry-in-case-of-failure,
not just abort or ignore as in the current version. But I'll take those
issues up on Ant list.
My use case is simple: I'm using ant ftp task to deploy Velocity scripts
to several front-end machines (7 in total).
And it is really annoying to change one file and to discover that
instead of just uploading one file, it will upload a whole bunch of them...
I actually need some more customized behaviour, so I will most probably
write a separate task and see if there are any more interested parties
in Ant community.
Rgds,
Neeme
Steve Cohen wrote:
> Sorry I didn't read far enough.
>
> This is more properly a discussion for the Ant list. All we handle
> here is the raw FTP. Ant's FTP task depends on commons-net, though,
> and until we release the timezone-using version of commons-net, ant
> will not have the tools to do what you need.
>
> I may be speaking out of turn here, but I doubt that that Ant
> developers will be receptive to your suggestion. The ant <ftp> task
> has been designed as a fairly simple wrapper around raw <ftp>. The
> "newer" attribute of the <ftp> task offers just a simple date-time
> comparison within the general dependency framework of ant.
>
> It sounds like what you are asking for is something much more,
> basically a version-control system. Ant supports several of these and
> my guess is that they will tell you to use cvs or one of the
> proprietary version control systems that ant supports in order to
> accomplish this logic. Have you considered using the <cvs> task of
> ant? I programmed one of the version-control systems that ant
> supports and your issues sound very familiar to me.
>
> But I could be wrong, also. If you outline your use case on the ant
> list, you may find more interest in supporting it than I expect. If
> you do, I suspect that would be implemented in a new task that perhaps
> sits on top of <ftp>, because there are still many use cases for using
> the <ftp> task as is.
>
> In any case, the timezone feature of commons-net-ftp will be part of
> any possible solution.
>
|