> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
