archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject absconding GET from webdav - was ( Re: service layer API proposal )
Date Tue, 05 Jun 2007 19:56:52 GMT
Second is the assumption that "GET" requests are not webdav requests.

Some WebDav client implementations improperly use the "GET" request to 
obtain file/folder information. (they should be using the various 
xml/propget requests to obtain that list.)

We could likely make it work, but in the process would reduce our 
already limited list of webdav clients down further.

/me glares at OSX.

(OSX's webdav client cannot be used against Archiva, due to bugs in the 
client)

- Joakim

Brett Porter wrote:
> I agree. Any reason we can't use detection?
>
> Also, any reason why the handler for downloading from the /repository/ 
> can't be this get servlet instead of dav servlet? We probably don't 
> want to add new ways to download from the repository for the same 
> reason we removed /proxy/. I realise you can only map one servlet, but 
> the servlet could delegate all operations other than get() to the dav 
> implementation.
>
> Anyway, not really sure of the implementation, just don't like 'get' 
> as a name :)
>
> I also don't agree on the repository storage format. I don't see any 
> reason this can't be configurable, and I think it's useful to be able 
> to run on an existing repo, or should we ever change the m2 format in 
> future.
>
> - Brett
>
> On 06/06/2007, at 4:18 AM, nicolas de loof wrote:
>
>> The "/get/{implementation-id}/{layout-path}" is an interesting option.
>>
>> Where would you place the target managed repository in such an URL ?
>>
>> The only thing I don't like in this solution is that it doesn't work 
>> based
>> on an auto-detection of the requested format. I'd prefer the servlet to
>> search for an implementation that accepts the requested path, so that 
>> the
>> current "/repository/id/{layout}" would be valid for any supported 
>> layout.
>>
>>
>> 2007/6/5, Joakim Erdfelt <joakim@erdfelt.com>:
>>>
>>> We have 2 concepts that are co-mingled right now.
>>>
>>> 1) Getting an artifact from Archiva.
>>> 2) Deploying an artifact to Archiva.
>>>
>>> This proposal should focus on #1, Getting an artifact from Archiva.
>>> (As for #2, that can remain the realm of the current DavServlet
>>> implementation)
>>>
>>> I always pictured this as a new GetArtifactServlet.
>>>
>>> Lets say we have it mapped to the "/get" servlet mapping.
>>> The following urls would all point to the same artifact.
>>>
>>> : Basic Format for maven 1 clients.
>>>
>>> http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar

>>>
>>> : Basic Format for maven 2 clients.
>>>
>>> http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar

>>>
>>>
>>> : (Advanced / Future Use) apt/deb serving.
>>>
>>> http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb

>>>
>>> : (Advanced / Future Use) yum/rpm serving.
>>>
>>> http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm

>>>
>>>
>>> Using a new servlet, would essentially decouple the filesystem
>>> format/layout as a requirement.
>>> Archiva can assume maven 2 format for the filesystem, and serve the
>>> artifact to the client in the way that is requested.  After all the 
>>> artifact
>>> information is now in the database.  It makes sense to me to do it 
>>> this way.
>>>
>>> The idea with the URL format is that
>>> "/get/{implementation-id}/{artifact-reference-implementation-format}"
>>>
>>> The implementation id can be a plexus role-hint on the 
>>> implementation of
>>> this GetArtifactServlet.
>>>
>>> What do you think?
>>>
>>> - Joakim
>>>
>>> nicolas de loof wrote:
>>>
>>> Hello,
>>>
>>> To enhance archiva-1.0 support for maven1, I'd like to introduce a 
>>> layer
>>> between DavServlet and repository proxies connectors.
>>> As Joakim suggested, this is the scope of the Dynamic Artifact Serving
>>> Layer
>>> in archiva roadmap.
>>>
>>> I propose this API :
>>>
>>> public interface ArtifactServingLayer
>>> {
>>>    /**
>>>     * Retrieve an artifact path in the repository based on the resource
>>> string.
>>>     */
>>>    public String getResourcePath( String resource );
>>> }
>>>
>>> The serving layer is responsible of finding the resource in the managed
>>> repository, with any required logic or temporary content, and to give a
>>> repository-related path back to the DavServer.
>>>
>>> The default implementation could simply use proxies-connectors to 
>>> find the
>>>
>>> resource, and some interceptors / proxies could add features, like
>>> converting on-the-fly from a layout format to the managedRepository
>>> layout,
>>> handle artifact relocation when a non-POM artifact is requested, or
>>> anything
>>> we discover to be usefull.
>>>
>>> What's your opinion ?
>>>


Mime
View raw message