maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject m2 and offline mode
Date Fri, 08 Apr 2005 15:49:40 GMT
Hi Everyone,

I wanted to take a few minutes and submit some thoughts I've documented
regarding offline mode in m2. My hope is to start a discussion of what
parts of the m2 system can reasonably be assumed to be
offline-sensitive. The goal is to factor as much of this offline
sensitivity as possible into APIs for plugins, phases, etc. to use, so
that plugging new pieces into the offline mode will be as easy as possible.

Thanks for your patience in reading and responding to such a large
email. Now, having said all that :), here are the contents of an APT
document I've started on this topic:


* Assumptions: What is Offline?

  For the purposes of determining the areas sensitive to offline status,
  it is definitely useful to define what the offline state really means.

  [[1]] This is obvious, but the network/internet is unavailable.

  [[2]] Localhost ( may also be unavailable if the whole
        network stack is offline.

  [[3]] "Remote" repositories referenced using the file:// protocol may
        be available. However, if that file:// url references a
        file-share, as in the case of an NFS or SMB mount, that will
        be unavailable.

  So, offline mode has several implications, some of which may not be
  altogether obvious:

  * Localhost may be unavailable. Therefore, even locally installed
    server processes which work by conversing over a port may fail.

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

* Implications for Resolution

** Dependency Resolution

  This one is obvious...we only have access to the repositories using
  the file:// protocol and living on a truly local filesystem when

** Plugin Resolution

  This is similar to dependency resolution. Plugin repositories not
  using file:// or not residing on a local (not shared) filesystem will
  be unavailable.

* Implications for Mojo Execution

** Deployment mojos

  The concept of deployment is dependent on the availability of a some
  remote repository. Just as above, if that repository is not using
  file:// (which is highly likely to be the case), or the repository is
  not on a local filesystem, deployment will fail when offline.

** Testing mojos

  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.

* Implications for Subsystems

** Maven-Wagon

  Parts of Wagon will continue to function normally. These include:

  * The file wagon, provided the referenced location is on a local

    It is not possible to determine whether a file-based location will
    be available except on a case-by-case basis (or a root-url by
    root-url basis).

  * If not otherwise specified, all other wagons are assumed to be
    remote-only, and are therefore sensitive to offline mode.

** Maven-Artifact

  This is wholly dependent on Maven-Wagon, above.

** Maven-Core

  We'll examine the different parts of maven-core on a case-by-case
  basis, below:

*** DefaultLifecycleExecutor

  When binding goals to the project's configured lifecycle, each mojo
  descriptor should declare whether it requires online/offline status.
  This value should be a java.lang.Boolean, so it can implement 3VL
  (three value logic: yes, no, don't-care). The requiredConnectivity
  field in the mojo descriptor has the following semantics:

  [Boolean.TRUE] Online status is required for this mojo to function

  [Boolean.FALSE] Offline status is required for this mojo to function

  [null] Either status is acceptable for the mojo to execute. It doesn't

  The majority of mojos will leave the requiredConnectivity == null,
  since online/offline status will be irrelevant, provided they have
  access to their required artifacts and other classpath elements.




View raw message