ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kent Larsson" <>
Subject Re: Do something if <get ... usetimestamp="true"/> downloads file
Date Fri, 16 Jan 2009 11:00:56 GMT
On Sat, Jan 10, 2009 at 4:50 PM, Brian Stephenson <> wrote:

> Let me talk from a conceptual point of view. In case number 2, big question
> is if you need to save the existing older local file if there is a newer
> source file, before trying to get the newer one, in case you want to use
> the
> old one if the download fails.

I'm willing to take the risk of a download failure, as I think that it's
quite small in my specific case.

In my case, as I do use "usetimestamp" in my <Get> task it has already made
a HTTP connection to retrieve the remote file time stamp when it's time to
overwrite my local copy. I get the Ivy.jar from the Maven repository (using
the <Get> task as I can't connect to the Maven repository using Ivy yet
[moment 22]). If the Maven repository is down for some reason I won't be
able to build anyway as it's where I get my dependencies (using Ivy) too.
:-) So for my case, I'm willing to take that added risk, as I find it to be

> If you put a "DELETE ${destination.file}"
> action in your target prior to the get, then if the download fails, the
> local dest file will not exist, and will not pass the Available task. But
> now you have no local copy and need to re-run the ANT project to try to
> re-download (but I suspect your process will have to do that anyway in case
> of download failure, but not sure of your specific situation there).

I don't want to delete it first, as I'm using the "usetimestamp" of my <Get>
task to compare the local file time stamp with the remote one, and only
download if a newer remote version exists. If I delete it, I can't compare
the local and remote files any more and have to download it every time.

> You can also use the RENAME task on the existing local file
> ("${destination.file}.SAV") before the GET (us the UpToDate task to tell
> you
> if you are going to run the Get, and need to rename the original dest
> file),

I can't run the <UpToDate> task to determine if I need to run the <Get> task
or not. The reason is that the <UpToDate> task only works with local files
while the <Get> task has a sophisticated way of retrieving the time stamp of
a remote file (without actually downloading it). I went to the source
(sometimes better than the manual) and it says:
private File sourceFile;
private File targetFile;
 upToDate = targetFile.lastModified() >= sourceFile.lastModified();

In the UpToDate class of Ant. That's how I can be sure. :-)

I also went to the source of the <Get> task and as fas as I can tell it has
no way of indicating that a download actually took place (which is
consistent with the lack of such a feature mentioned in the manual), which I
find odd. So I'll have to check if a download took place myself, in some

> and DELETE the renamed original file if the download is succesful (if the
> Available task sets the property because the dowloaded file exists), or
> RENAME it back to the original name if the download fails (if the Available
> task fails to set the property because the dowloaded file does not exist).
> Let me know if you need some specific ANT code example of what I am talking
> about, or if I am making no sense whatsoever, which is always
> possible....Good Luck.

I understood your line of thought, but as far as I see it's not a possible
solution (see above).

What I do need is something like this:
1. Store the timestamp of the local file in a property named
2. Perform the <Get> using "usetimestamp" as I do now. It may or may not
download and overwrite the local file.
3. Check the timestamp of the local file now, if it has changed and is
different from "localfiletimestamp" then the <Get> task downloaded the file
and I need to perform a couple of operations.

Is there something in Ant which allows me to do that? :-)

> Brian
> On Fri, Jan 9, 2009 at 2:44 PM, Kent Larsson <<>>
> wrote:
> > Hi Brian,
> >
> > Thanks for trying to help, but the key to my problem is that I use
> > usetimestamp="true" in my get task. It means that the file will be
> > downloaded for two cases: 1) The file isn't there to begin with and 2)
> > The file is there but has a time stamp going back further in time than
> > the remote file. Your example handle [1] but not [2], and I really
> > need to handle them both.
> >
> > More ideas? :-)
> >
> >
> > On Fri, Jan 9, 2009 at 7:00 PM, Brian Stephenson
> > <<>>
> wrote:
> > > Kent,
> > >   There may be a more direct way to do this, but I accomplish a similar
> > > thing this way (I munged my code to match yours):
> > >
> > > <available file="${destination.file}" type="file"
> > > property="dest.file.present"/>
> > >
> > > Then the targets following can have the "if" attribute in the target:
> > >
> > > <target name="Do_When_File_Is_There" depends="download-ivy"
> > > if="dest.file.present">
> > > ...
> > > </target>
> > >
> > > With "available", the designated property is not set if the file does
> not
> > > exist.  With the "if", the target is only executed if the property is
> > > actually set, which it won't be if the destination file does not exist
> > after
> > > attempted download.
> > >
> > > Brian
> > >
> > >
> > > On Jan 9, 2009, at 11:58 AM, Kent Larsson wrote:
> > >
> > >> In a target I download a remote file if it's newer than the current
> > >> local one or if no local copy exists. I do it using the following code
> > >> and it works as it's supposed to:
> > >>
> > >> <target name="download-ivy" unless="">
> > >>  <mkdir dir="${destination.dir}"/>
> > >>  <get src="" dest="${destination.file}"
> > >> usetimestamp="true"/>
> > >> </target>
> > >>
> > >> Now to my problem:
> > >>
> > >> I would like to do something if the remote file is actually
> > >> downloaded. If the remote file is not downloaded I don't want to do
> > >> these tasks.
> > >>
> > >> I've looked through the manual and done some Googling without finding
> > >> my answer. I'm quite new to Ant so this may still be an easy problem
> > >> for someone more experienced.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message