I'd suggest to keep the existing "/repository/<repo-id>/path" as get URL, so
that existing archiva user (as I am) that have configured maven clients to
point to this URL don't have to make changes on developpers PCs when
upgrading...
Having a distinct webdav URL "/webdav//<repo-id>/path" is OK as this is set
in the POM for projects that use it for deployment, so required changes are
limited.
That beeing said, I don't understand the "technical reasons to not do"
auto-discovery of repository path based on the requested resource, when
possible. I understand there may be some conflicts, and that a determinist
URL has to be supported to avoid them (/repository/<repo-id>/maven/<path>
for maven1, /repository/<repo-id>/maven2/<path> for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository/<repo-id>/<path>" that ask any registered layout for support on
the requested <path>. If multiple are found, request may be rejected. The
idea here is to allow support for maven1/maven2 request on the same get URL
root, as supported by archiva-0.9.
To avoid any URL conflict, we could :
- use /webdav/<repo-id>/<path> as webdav URL
- use /get/<repo-id>/<layout>/<path> as deterministic get URL
- use /repository/<repo-id>/<path> as auto-discovery, for backward
compatibility with archiva-0.9
Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
>
> Joakim,
>
> Did we ever reach agreement on the format of these URLs? It'd be
> great to get it nailed down before beta-1 rolls out :)
>
> Cheers,
> Brett
>
> On 04/07/2007, at 11:28 AM, Brett Porter wrote:
>
> > So, last time this topic came up, there was disagreement on the /
> > get/ interface.
> >
> > Regarding using /get/ instead of just /repository/ URL as is, I
> > said (<[EMAIL PROTECTED]>)...
> > "Ok, while I'd definitely prefer to make it work, if it can't then
> > I'd prefer we made the change in the other direction (the default
> > repository URL is get only, we have /repository-id/webdav/ as the
> > webdav exposure point)."
> > to which Nicolas agreed.
> >
> > We then diverged into discussing auto-discovery of the getId from
> > the path which there were technical reasons to not do.
> >
> > However, I do not want all repositories to look like /archiva/
> > repository/releases/get/maven2/. Yikes.
> >
> > Cheers,
> > Brett
> >
> > On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
> >
> >> Design.
> >>
> >> 1) Create DynamicGetServlet which parses ....
> >> /get/${getId}/${getResource}
> >> 2) Create Maven1GetProvider which has an id "maven1", and serves
> >> artifacts / poms to it.
> >> 3) Create Maven2GetProvider which has an id "maven2", and serves
> >> artifacts / poms / metadata to it.
> >> 4) Test
> >> 5) Done.
> >>
> >> - Joakim
> >>
> >> Brett Porter wrote:
> >>> Sounds good. With the M1 client support, can you post a small
> >>> design proposal first since last I remember we didn't reach
> >>> consensus on how it should be implemented?
> >>>
> >>> - Brett
> >>>
> >>> On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
> >>>
> >>>> I agree.
> >>>>
> >>>> I view 1.0-beta-1 as feature complete.
> >>>>
> >>>> The current missing features ...
> >>>> * Reporting (about 80% there right now, just some UI pieces left
> >>>> to hook up)
> >>>> * Maven 1 Client Support (about 40% complete. need to hook up
> >>>> DynamicGetServlet)
> >>>> * Live documentation. (present in archiva.war)
> >>>>
> >>>> - Joakim
> >>>>
> >>>> Brett Porter wrote:
> >>>>>
> >>>>> On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
> >>>>>
> >>>>>> Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-
> >>>>>> beta-1
> >>>>>> seems reasonable, but /topic in #archiva says "coming soon, the
> >>>>>> Archiva 1.0 (the "Ship It" release)".
> >>>>>
> >>>>> I was kidding (but that should be the focus from now on. Get it
> >>>>> done.) I agree 1.0-beta-1 is next - it should be feature complete.
> >>>>>
> >>>>>> - Brett
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> - Joakim Erdfelt
> >>>> [EMAIL PROTECTED]
> >>>> Open Source Software (OSS) Developer
> >>>
> >>
> >>
> >> --
> >> - Joakim Erdfelt
> >> [EMAIL PROTECTED]
> >> Open Source Software (OSS) Developer
>
