Apache
/
maven
mirror of https://github.com/apache/maven.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
This commit is contained in:
John Dennis Casey 2005-04-08 19:53:04 +00:00
parent 232139d910
commit 0128ae2758
1 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
maven-core/src/site/apt/offline-mode.apt
View File

@ -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 <beyond localhost> 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 <<not>> 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