archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Re: MRM-462: configuring different types of repositories differently
Date Wed, 15 Aug 2007 02:01:18 GMT
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
>>>
>

Mime
View raw message