Re: service layer API proposal

[Joakim Erdfelt]

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 ?