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
