archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: MRM-462: configuring different types of repositories differently
Date Wed, 15 Aug 2007 01:49:04 GMT
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

View raw message