Versions Compared

Old Version 1

changes.mady.by.user Brett Porter

Saved on

compared with

New Version Current

changes.mady.by.user Wendy Smoak

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

The structure of the local repository should become:

Code Block
.
|-- cache
|   |-- snapshots
|   `-- remotereleases
|-- repositories
|   |-- apache.snapshots
|   |-- central
|   |-- codehaus.snapshots
|   `-- ...
`-- workspace
    |-- default
    |-- workspace1
    `-- ...

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 stored separately by default to make it easier to remove them periodically.

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, however if you wish to store actual artifacts in this directory they will be used instead of the cache, allowing a simple way to rsync a remote repository and use it as a local repository (and vice-versa).

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

...

Code Block
.
|-- cache
|   |-- snapshots
|   |   |-- com
|   |   |   `-- example
|   |   |       `-- ...
|   |   `-- org
|   |       |-- apache
|   |       |   `-- ...
|   |       `-- codehaus
|   |           `-- ...
|   `-- releases
|       `-- org
|           `-- remoteapache
|               `-- ...
|-- repositories
|   |-- apache.snapshots
|   |   `-- org
|   |       `-- apache
|   |           `-- ...
|   |-- central
|   |-- codehaus.snapshots
|   |   `-- org
|   |       `-- codehaus
|   |           `-- ...
|   `-- ...
`-- workspace
    |-- default
    |   `-- com
    |       `-- example
    |           `-- ...
    |-- workspace1
    `-- ...

...

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.

Workspaces

A CLI parameter --workspace should be added to allow switching workspaces. This is just a small portion of a more complete workspace proposal, but the identifier can later be reused if this is implemented first so is compatible. It may also be added to settings.xml in the future, though out of scope for 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 any data among the repository sections.

Rolling back a reactor build

About rolling back a whole reactor build...
I think it's something that would be separately configurable. I don't think it would be the default. The individual artifacts, once built, should be useful whether the rest build or not - but it really depends on your projectWhile 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/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 different locations).

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

...

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.

Settings

The above structure is a default, stored in the localRepository setting. However, snapshotLocalCache, releaseLocalCache and workspacesDirectory settings will be added to allow flexible location of those directories.

Implementation Considerations

It is worth reviewing whether JSR-170 could be used to assist in managing the content, particularly in regard to locking - however it should not be used unless it can be mapped to the directory structure and individual files as laid out above.

Votes

+1

brett

0

 

-1

 

References