While I can agree to the desire to separate the repository concepts from
a User experience / Admin Screens point of view, I strongly encourage
keeping the configuration / model / database pieces joined at the hip.
In a future version of Archiva (post 1.0) I was hoping for ...
* A report on all remote repositories defined in the various poms.
* A list of mirrors for each repository that is propagated via various
archiva instances.
* An ability to have a consumer that adjusts all pom embedded repository
definitions to the archiva server itself.
* An ability to auto-add pom embedded remote repositories as proxy
destinations.
Or some combination of above.
Example:
1) Pull up a report of all remote repositories defined in the poms.
2) Select one of them, and a managed repository.
3) A remote repository is added to the archiva configuration.
4) A proxy connector is added between the selected managed repo and the
new remote repository.
5) Then all embedded references to that remote repository now point to
the managed archiva repository URL.
6) A reference is added to the auto-convert consumer that all new
occurrences of this repository are converted.
With maven 2 depending on repository ids, this would standardize the
repository ids found in the managed repository.
I also don't want to see a repo id reused between a managed and remote
repository.
Reasoning behind that is a system I once saw used with maven-proxy.
Maven-proxy was installed to proxy local content on the filesystem, each
project team had their own login on a unix server, with a directory that
was used for their own repository.
[~fooWeb]$ ls -l
total 8
drwxr-xr-x 2 fooWeb fooWeb 4096 2007-08-14 20:42 repo/
drwxr-xr-x 2 fooWeb fooWeb 4096 2007-08-14 20:42 site/
[~fooRetail]$ ls -l
total 8
drwxr-xr-x 2 fooRetail fooRetail 4096 2007-08-14 20:42 repo/
drwxr-xr-x 2 fooRetail fooRetail 4096 2007-08-14 20:42 site/
Each project had their own repository to play with, and the corporation
as a whole had a maven-proxy that merged the views of all the project
team repositories into a single view.
This was all done via proxying of a file:// url.
I don't want to see duplicate repoIds either.
(disclaimer: writing this while on a post-dinner drowsy spell)
- Joakim
Brett Porter wrote:
Hi,
I'd like to schedule this one for beta-2, and can probably do the work
on it. I would probably run through the rest of the
admin/configuration screens and file other issues I find too.
It involves:
1) separate the forms/actions (or at least exclude the fields that are
not relevant when editing the remote repos)
2) treat the URL (remote) as a URL and the location (managed) as a
path. Don't munge anything.
3) I think we should consider separating them into different lists in
the configuration again.
It would fix:
- causing both subtle bugs (particularly in the URL handling), and
- a confusing user experience (settings appearing that are irrelevant
to remote repositories in the edit form).
I used to have this in the configuration as an abstract base class
containing the basic repository information (so much of the logic and
even pages can still be shared), but then extended differently for the
different types of repositories.
Does anyone have any thoughts on this?
Cheers,
Brett
