From 0128ae27583b4a0e447c7c0a6b21078e0de25e1e Mon Sep 17 00:00:00 2001 From: John Dennis Casey Date: Fri, 8 Apr 2005 19:53:04 +0000 Subject: [PATCH] Just adding some detail, from my thoughts over lunch... git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163886 13f79535-47bb-0310-9956-ffa450edef68 --- maven-core/src/site/apt/offline-mode.apt | 51 ++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/maven-core/src/site/apt/offline-mode.apt b/maven-core/src/site/apt/offline-mode.apt index 60e5556c34..17504bec70 100644 --- a/maven-core/src/site/apt/offline-mode.apt +++ b/maven-core/src/site/apt/offline-mode.apt @@ -1,3 +1,13 @@ + --- + Offline Mode Design + --- + John Casey + --- + 08-April-2005 + --- + +Offline Mode Design + * Assumptions: What is Offline? For the purposes of determining the areas sensitive to offline status, @@ -22,8 +32,44 @@ * Not all "remote" repositories will fail. Specifically, if the remote repo uses the file:// protocol, and it doesn't refer to a shared filesystem, it will continue to be available. + + The question remaining is: Which level of offline mode will we support? It + seems reasonable to assume that users will be able to tell when localhost is + not active (in most cases, localhost should be available, even if the rest of + the network is not). Therefore, let's concentrate on the state where no + network exists, and leave the more extreme state to users + to diagnose and correct as necessary. +* Why is Offline Mode Important? + Offline mode is essential for breaking the requirement that m2 operate in a + network-connected environment. It means legitimizing a development environment + in which there is no network connection, and providing a robust m2 service + offering in such circumstances. Introduction of offline mode allows m2 to + anticipate the inevitable network failures that accompany being physically + disconnected from the network, and adjust it's behavior accordingly. + + It is more than simply understanding that m2 cannot go and check for the + latest version of some snapshot artifact. If m2 is offline, SCM operations cannot + succeed; no artifact downloads can take place, regardless of whether they are + snapshot versions; artifact deployment cannot take place; certain types of + tests cannot be setup, since the container used to run them cannot be reached + or started. + + All of these operations will produce their own unique errors in the absence of + a coordinated offline strategy. In addition, efforts to unite these failing + behaviors behind a consistent user interface is much, much more difficult if + the system can't tell whether it has access to the network required by these + operations. + + Offline mode really means anticipating a lack of network connectivity, and as + a result turning off certain services provided by m2 and providing a coherent + way of predicting and reporting when network-related failures will take place. + It means warning users that since the network is missing, certain features and + operations will be unavailable, rather than simply waiting for those operations + to fail, then trying to help users decipher the error messages they get as a + result. + * Implications for Resolution ** Dependency Resolution @@ -53,6 +99,11 @@ This can be a problem if the tests are more than simple unit tests; that is, if they require configuration of a server process, and subsequent testing in-container. + + Since we're only going to concern ourselves with states where localhost is + still active, we only need to worry about this case when the server container + is <> installed on localhost. This allows the popular pattern of starting + a server container in-JVM, running tests against it, and shutting it down. ** SCM mojos