archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: What is Archiva.NEXT ?
Date Tue, 31 Jul 2007 02:43:24 GMT
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 

- 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 <>:
>>>> 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 (<>)...
>>>>> "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
  Open Source Software (OSS) Developer

View raw message