As an answer to the original concerns. yes.
When it comes to a specific implementation, I just don't want us to go
down a path that limits our options later.
- Joakim
Brett Porter wrote:
I think we are in agreement then. I was expecting that we'd build both
types off of an abstract base type, and we can certainly make the ids
unique across both.
I do think the remote and managed repositories will be separate in the
configuration file, but in the database they'd be the same and the id
remains unique.
Have I read your concern correctly?
- Brett
On 15/08/2007, at 10:46 AM, Joakim Erdfelt wrote:
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
