You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Brett Porter <br...@apache.org> on 2007/08/13 08:52:36 UTC
MRM-462: configuring different types of repositories differently
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
Re: MRM-462: configuring different types of repositories differently
Posted by Maria Odea Ching <oc...@exist.com>.
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?
+1 to this.. there have been some confusion to users about the remote
and managed repositories, I think most especially with the Scannable
field for the remote repositories.
>
> Cheers,
> Brett
>
Thanks,
Deng
Re: MRM-462: configuring different types of repositories differently
Posted by Brett Porter <br...@apache.org>.
I'll keep that in mind :)
On 15/08/2007, at 12:01 PM, Joakim Erdfelt wrote:
> 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
>>>>
>>
Re: MRM-462: configuring different types of repositories differently
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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
>>>
>
Re: MRM-462: configuring different types of repositories differently
Posted by Brett Porter <br...@apache.org>.
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
>>
Re: MRM-462: configuring different types of repositories differently
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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
>