Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and project artifacts.
The separation isn't clear in maven itself - repo's get mixed up,
wrong repo's consulted; build artifacts interfering with plugin artifacts.
Having a separate directory containing information on what build artifacts
are used makes it easy to freeze a maven environment, and see what
was used runtime.
Also see [1], which you, Brett, weren't in favour of back then. Perhaps
now this can be taken into consideration with this proposal.
[1] http://jira.codehaus.org/browse/MNG-724
Brett Porter wrote:
See: http://docs.codehaus.org/display/MAVEN/Local+repository+separation
Text included below for inline comments (which I'll feed back into the
document as needed).
Context
The current local repository is a single file structure, stored
typically in an individual user's home directory.
The suffers from the following problems:
* there is no locking, so if multiple Maven instances attempt to run on
the same machine they can corrupt each other's metadata
* it serves multiple purposes - it is both a cache of remote repository
artifacts, and a place to locally install artifacts that you build.
Because of this, it is possible that the local cache does not always
accurately reflect the state of the remote repository
** downloading a snapshot from a remote repository also writes the
chosen version out as -SNAPSHOT, meaning that continues to get used even
if the snapshot repository is removed
** downloading an artifact from a remote repository with a fixed version
does not write metadata, so if that repository is later removed the
artifact is still used though a clean build would fail. This
particularly affects testing staged releases
* it can be different to isolate differences in the local repository
without deleting the entire cache, requiring time consuming downloads.
* it isn't possible have multiple checkouts of the same development
version and build them independently (particularly important for CI
servers).
* it isn't possible to easily clean out a subsection of the repository
* the artifact code is over-complicated to implement the logic for
sharing the storage
Solution
General Considerations
This solution aims to not change the current behaviour, other than to
make 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
Locking should be implemented at the individual artifact level. This can
be done with a lockfile in the artifact top level directory (rather than
the 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 that Maven can simply block on the existence of a lockfile
(both read and write operations), and remove it after a short period of
time.
Local repository separation
The structure of the local repository should become:
.
|-- cache
|-- remote
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
`-- workspace
|-- default
|-- workspace1
`-- ...
The purposes of these directories are as follows:
* cache: immutable artifacts downloaded from a remote repository. No
metadata is stored in this directory tree.
* remote: contains a directory for each remote repository (by repository
identifier). This contains the metadata and mutable artifacts from that
repository. Metadata files will return to the format
{{maven-metadata.xml}} instead of the current
{{maven-metadata-<id>.xml}} file format. Files in these repositories
will typically be snapshots and metadata for releases, since actual
releases are not mutable and can be stored in the {{cache}} directory
* workspace: contains a directory for each local workspace, with the
primary one being {{default}}. This contains the metadata and files for
any artifact built by maven (both snapshots, and releases).
Under each of these locations, the standard layout remains as it is now:
.
|-- cache
| |-- com
| | `-- example
| | `-- ...
| `-- org
| |-- apache
| | `-- ...
| `-- codehaus
| `-- ...
|-- remote
| |-- apache.snapshots
| | `-- org
| | `-- apache
| | `-- ...
| |-- central
| |-- codehaus.snapshots
| | `-- org
| | `-- codehaus
| | `-- ...
| `-- ...
`-- workspace
|-- default
| `-- com
| `-- example
| `-- ...
|-- workspace1
`-- ...
Search sequence
As current behaviour is to be retained when correct, the solution should
aim to merge the metadata across the current workspace and active remote
repositories to decide what artifact to use. The artifact can then be
utilised from either the workspace, remote, or cache repositories.
Existence in the {{cache}} directory is not a decision point for using
an artifact - this must be achieved and the artifact from there used if
possible. This will help enable better utilising the remote repository
metadata for tracking the source of an artifact in the future to resolve
some of the problems listed in the context section of this proposal.
Deployment and Merging
Content will be deployed from the workspace directory, but will not be
merged to other sections - there should be no need to migrate and data
among the repository sections.
Rolling back a reactor build
While this would be a separate feature, and not the default behaviour,
it would now be possible to use a temporary workspace to build artifacts
during a reactor build and merge them into another workspace on
completion, making an entire reactor build "atomic" with respect to the
local repository.
Co-existence with Maven 2.0.x
A best practice should be to change your Maven 2.0.x configuration to
use {{~/.m2/repository/cache}} as the local repository, and move the
existing content, as this will co-exist properly with Maven 2.1.
Upgrade path
There is no need to upgrade existing local repositories - first use of
Maven 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).
Shared Local Repositories
Though locking will now make this possible, it is still not a
recommended practice to share the local repository. However, this
structure will allow people to share the {{cache}} location safely to
reduce disk usage if desired.
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
