ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Curt Arnold" <carn...@houston.rr.com>
Subject Re: better <get> behavior when disconnected
Date Sun, 18 Nov 2001 00:44:57 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.

I guess the same would occur for desktop systems on dial-up, launching an
annoying connection dialog.

> 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.

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.



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message