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