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 Sun, 18 Nov 2001 02:16:55 GMT

----- Original Message -----
From: "Curt Arnold" <>

> > 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)
> > use that property to control whether the rest of the get should take
> place.
> If the local copies don't exist, there isn't a recovery scenario.  So
> knowing if the the network is unavailable and skipping the <get>'s, just
> will result in unrelated failure downstream if the files weren't there.
> Adding a static attribute seems the cleanest approach to me.
> > In the meantime, why not make the 'fetch remote files' a target which is
> not
> > part of the default build path, huh?
> I've already got about 10 or so different targets in the build file.  That
> would require that I double that with an equivalent "-no-net" target for
> each.  The downstream tasks really do depend on the <get> tasks and so
> creating targets that don't express their true dependencies seems
> undesirable.  Definitely, it can be worked around, but a simple attribute
> with very minimal supporting code would eliminate a whole lot of kludging.

Now I'm getting confused. Lets see if I get this straight
1. You have these <get> tasks which are an essential part of your build tree
because they get stuff
2. You are trying to build off-line
3. You have observed that it doesnt work.
4. We have proposed a forthcoming solution
4. You dont want to use it because it complicates your build

Imagine there is a way to probe for a remote server being accessible,
setting a property.

You then have a target

<target name="fetch-remote-files" if="remote.server.accessible"
 <get ... >

which depends on the probe (which can be overrideen with an offline flag to
not even probe if you know you are offline)

<target name="probe-remote-server" unless="system.offline">
 <httphead url="http://myserver/"

but your work target doesnt explicitly do so

<target name="build" depends="fetch-remote-files" >
    //.. do the work

So, with a connectivity test you should not take a hit when you are off line
(well, the overhead of a HEAD round trip), can turn the thing off when you
know you dont need it, and let it work it out for itself.


Now, what you seem to want instead is an option to only fetch a file if it
doesnt exist locally, not doing timestamp polling. Is that right?

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

View raw message