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