Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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.

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