ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: better <get> behavior when disconnected
Date Sat, 17 Nov 2001 18:39:44 GMT
Ah, you have noticed a failure of the 'deskto' versions of java -that they
all make the assumption that a client is always on line, and there is no
library call to check if the network is available. Yet studies have shown
[Loughran, Secret Life of Notebooks, 2000] that network connectivity on a
desktop replacement notebook varies wildly through the day. We really need
an x-platform library to check for network status, maybe power levels too,
but that would be a JCP project, not an apache one.

Later on this weekend I will put into the CVS sandbox (I have to create that
first) an early iteration of an extended set of http tasks; one key feature
being that you can set a property when GET, HEAD or POST succeed. So you can
have target probe for the web site being reachable (take the 30s hit) and
use that property to control whether the rest of the get should take place.

In the meantime, why not make the 'fetch remote files' a target which is not
part of the default build path, huh?


----- Original Message -----
From: "Curt Arnold" <>
To: <>
Sent: Friday, November 16, 2001 22:40
Subject: better <get> behavior when disconnected

I have a build script that uses extensive <get> tasks to download static
resource files from a web site ( in preparation for building.  Since
I know the web site content should not change (since I'm using version
specific URI's), as long as I have a local copy. I know its good.

If I use usetimestamp="yes" then things move very quickly on successive
builds, as long as there is a network connection and not in an airplane.  In
that case, the build becomes painful since every attempt to download files
takes forever even though you already have the right files on your machine.

If should be fairly trivial to add an attribute to <get> that would indicate
that the content is static and that if a local copy exists there is no need
to attempt to connect to the source.  "static" seems to be the most
descriptive and unambiguious term that I could think of.

Any thoughts?

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

View raw message