Message-ID: <588073772.299026.1368962280210.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_299025_1994701927.1368962280209" ------=_Part_299025_1994701927.1368962280209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The current local repository is a single file structure, stored typicall= y in an individual user's home directory.
The suffers from the following problems:
Related proposals: Maven 2.1 Artifact Resolution Specification
This solution aims to not change the current behaviour, other than to ma= ke it easier/possible to correct things considered known bugs as documented= above. Resolution behaviour should not otherwise be affected and any such = changes should be in the related proposal.
This proposal simply alters the storage of the artifacts.
Locking should be implemented at the individual artifact level. This can= be done with a lockfile in the artifact top level directory (rather than t= he individual version), locking both the metadata and artifact.
An artifact operation should be done with files in a temporary location,= and moved to the final location in one operation, wrapped by the creation = of the lockfile. This makes the duration of the lock relatively short, so t= hat Maven can simply block on the existence of a lockfile (both read and wr= ite operations), and remove it after a short period of time.
The structure of the local repository should become:
The purposes of these directories are as follows:
cache (snapshots, releases)
immutable artifacts downloaded from a remote= repository. No metadata is stored in this directory tree. Snapshots are st= ored separately by default to make it easier to remove them periodically. <= /p>
contains a directory for each remote reposit=
ory (by repository identifier). This contains the metadata and mutable arti=
facts from that repository. Metadata files will return to the format
contains a directory for each local workspac=
e, with the primary one being
Under each of these locations, the standard layout remains as it is now:=
As current behaviour is to be retained when correct, the solution should= aim to merge the metadata across the current workspace and active remote r= epositories to decide what artifact to use. The artifact can then be utilis= ed from either the workspace, remote, or cache repositories.
Existence in the
cache directory is not a decision point fo=
r using an artifact - this must be achieved and the artifact from there use=
d if possible. This will help enable better utilising the remote repository=
metadata for tracking the source of an artifact in the future to resolve s=
ome of the problems listed in the context section of this proposal.
A CLI parameter
--workspace should be added to allow switch=
ing workspaces. This is just a small portion of a more complete workspace p=
roposal, but the identifier can later be reused if this is implemented firs=
t so is compatible. It may also be added to settings.xml in the future, tho=
ugh out of scope for this proposal.
Content will be deployed from the workspace directory, but will not be m= erged to other sections - there should be no need to migrate any data among= the repository sections.
While this would be a separate feature, and not the default behaviour, i= t would now be possible to use a temporary workspace to build artifacts dur= ing a reactor build and merge them into another workspace on completion, ma= king an entire reactor build "atomic" with respect to the local r= epository.
A best practice should be to change your Maven 2.0.x configuration to us=
~/.m2/repository/cache/releases as the local repository, and=
move the existing content, as this will co-exist properly with Maven 2.1. =
And share content for all releases (though snapshots will be installed in d=
There is no need to upgrade existing local repositories - first use of M= aven 2.1 will only mean users need to rebuild any local software, as remote= artifacts will be redownloaded (however see above for the minimisation of = this).
Though locking will now make this possible, it is still not a recommende=
d practice to share the local repository. However, this structure will allo=
w people to share the
cache location safely to reduce disk usa=
ge if desired.
The above structure is a default, stored in the
localRepository setting. However,
workspacesDirectory settings will be added to =
allow flexible location of those directories.
It is worth reviewing whether JSR-170 could be used to assist in managin= g the content, particularly in regard to locking - however it should not be= used unless it can be mapped to the directory structure and individual fil= es as laid out above.