maven-m2-dev mailing list archives

-----BEGIN PGP SIGNED MESSAGE-----
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 (127.0.0.1) 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
mode.
> ** 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
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCVqlmK3h2CZwO/4URApgFAKCXVu3P1Z3TOJA+BKWKhnTkneAKnACfXKII
cwDBBY8pyD1Ix2LCvZuBeic=
=pjwd
-----END PGP SIGNATURE-----