maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jdca...@apache.org
Subject cvs commit: maven-components/maven-core/src/site/apt offline-mode.apt
Date Fri, 08 Apr 2005 19:53:04 GMT
jdcasey     2005/04/08 12:53:04

  Modified:    maven-core/src/site/apt offline-mode.apt
  Log:
  Just adding some detail, from my thoughts over lunch...
  
  Revision  Changes    Path
  1.2       +53 -2     maven-components/maven-core/src/site/apt/offline-mode.apt
  
  Index: offline-mode.apt
  ===================================================================
  RCS file: /home/cvs/maven-components/maven-core/src/site/apt/offline-mode.apt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- offline-mode.apt	8 Apr 2005 16:28:58 -0000	1.1
  +++ offline-mode.apt	8 Apr 2005 19:53:04 -0000	1.2
  @@ -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
   
  
  
  

Mime
View raw message