"one such collision in naming is when a metadata.xml file is requested and
the path is detected as a
maven 1 resource"
Just surpised about this : would any maven 1.x client request for meta-datas
? AFAIK maven1 only request for artifacts (jars) and never for POMs or
meta-data.xml ?
just my 2 cents...
2007/7/31, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> I'm tired.
> I'm tired of the confusion.
> I'm tired of the lack of decision.
>
> The ability to serve the repository information to multiple clients is
> exactly the reason for splitting this logic out.
>
> It's nearly impossible to have dynamic paths to resources and be a
> managed repository at the same time.
> That is the first step. Separate the dynamic 'get' logic out from the
> webdav put/set layer.
>
> The next step is to allow the 4 identified clients to work on GET of
> resources contained within the repository.
>
> The 4 clients.
> * Apache Maven 2
> * Apache Maven 1.1
> * Apache Maven 1.0
> * Apache Ivy
>
> The 4 types of data that is fetched from the repository.
> * Artifacts
> * Versioned Metadata.xml
> * Project (unversioned) Metadata.xml
> * Checksum files
>
> Since we hit collisions on the auto-discovery technique for maven 1 to
> maven 2 requests (ie: legacy vs default), the need to have a different
> 'view' to the repository is crucial. (one such collision in naming is
> when a metadata.xml file is requested and the path is detected as a
> maven 1 resource. there are more, but addressing each 'special case'
> will just result in a piece of code horribly convoluted and ultimately
> doomed to maintenance hell)
>
> Now instead of talking about layouts (legacy vs default) and paths as
> the means to an end, the idea of access or client identifiers in the URL
> was discussed. /get/${accessor_id}/${repo_id}/${resource}
>
> I'm about to rip it apart and implement it as proposed, as I want to see
> it work, and no one has yet to propose a different viable solution to
> the issue.
>
> This support is important in archiva, and we are getting close to a 1.0
> release.
>
> - Joakim
>
> Brett Porter wrote:
> > We're not really getting towards an answer here, just more spinning
> > around the questions.
> >
> > Please correct me if I'm wrong - but I believe that the get vs put
> > separation is for reasons entirely separate from the client
> > identification.
> >
> > If that is the case, do we agree that /repository and /webdav are
> > appropriate markers for those two requests?
> >
> > Now, returning to the issue of identifying the client - sorry, I don't
> > really understand why we can't identify the format from the URL. It
> > used to do it just fine. We occasionally had a glitch, and the code to
> > do it for m1 was gruesome, but it worked. I also don't understand what
> > is special about m1.1 - was something added that helped in the
> > identification?
> >
> > If we are going to have to put some sort of identification in the URL
> > we need to start deciding how that is going to look and be configured.
> > I really wasn't happy with the long URLs proposed before. I can think
> > of a couple of alternatives, but would prefer to look at the necessity
> > for it first.
> >
> > - Brett
> >
> > On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
> >
> >> Both of those choices do not provide the ability for the client to
> >> identify itself.
> >> Maven doesn't do it.
> >> Wagon doesn't do it.
> >> Ivy doesn't do it.
> >>
> >> So we are left with having some identification of the client via the
> >> URL.
> >>
> >> The long term future direction of Archiva is to support as many
> >> clients as possible.
> >> It is myopic to assume that everyone is going to use Maven 2.
> >>
> >> Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
> >> (all Apache projects).
> >>
> >> Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we have
> >> problems supporting Maven 1.0 with the auto-discovery approach.
> >>
> >> I'm sure we have unit tests for auto-discovering the type of request.
> >> Currently needs to support
> >>
> >> * Artifact for layout of type default.
> >> * Metadata for type default.
> >> * Checksum request for type default.
> >> * Artifact for layout of type legacy.
> >> * Metadata for type legacy.
> >> * Checksum request for type legacy.
> >>
> >> - Joakim
> >>
> >> nicolas de loof wrote:
> >>> 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
> >>>>>>
> >>>>>>
> >
>
>
> --
> - Joakim Erdfelt
> [EMAIL PROTECTED]
> Open Source Software (OSS) Developer
>
>
