maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: m2 and offline mode
Date Fri, 08 Apr 2005 15:55:18 GMT
Hash: SHA1

Addendum in-line:

John Casey wrote:
> 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
>   offline.
> ** 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.

** SCM mojos

  See below for discussion on SCM-related operations. Any mojo which
  carries out some analysis or other interaction with a SCM system
  will likely be unavailable when in offline mode.

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

  In all but trivial examples, SCM operations cannot complete without
  having access to the versioning server. Therefore, it is assumed that
  any SCM-related activity will be unavailable when m2 is in offline

> ** 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
>                  correctly.
>   [Boolean.FALSE] Offline status is required for this mojo to function
>                   correctly.
>   [null] Either status is acceptable for the mojo to execute. It doesn't
>          care.
>   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.
> -------------------------------------------------------------------------
> Regards,
> John
Version: GnuPG v1.2.6 (GNU/Linux)


View raw message