archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Re: service layer API proposal
Date Tue, 05 Jun 2007 16:18:42 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We have 2 concepts that are co-mingled right now.<br>
<br>
1) Getting an artifact from Archiva.<br>
2) Deploying an artifact to Archiva.<br>
<br>
This proposal should focus on #1, Getting an artifact from Archiva.<br>
(As for #2, that can remain the realm of the current DavServlet
implementation)<br>
<br>
I always pictured this as a new GetArtifactServlet.<br>
<br>
Lets say we have it mapped to the "/get" servlet mapping.<br>
The following urls would all point to the same artifact.<br>
<br>
: Basic Format for maven 1 clients.<br>
<a
 href="http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar">http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar</a><br>
: Basic Format for maven 2 clients.<br>
<a
 href="http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar">http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar</a><br>
<br>
: (Advanced / Future Use) apt/deb serving.<br>
<a
 href="http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb">http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb</a><br>
: (Advanced / Future Use) yum/rpm serving.<br>
<a
 href="http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm">http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm</a><br>
<br>
Using a new servlet, would essentially decouple the filesystem
format/layout as a requirement.<br>
Archiva can assume maven 2 format for the filesystem, and serve the
artifact to the client in the way that is requested.&nbsp; After all the
artifact information is now in the database.&nbsp; It makes sense to me to
do it this way.<br>
<br>
The idea with the URL format is that
"/get/{implementation-id}/{artifact-reference-implementation-format}"<br>
<br>
The implementation id can be a plexus role-hint on the implementation
of this GetArtifactServlet.<br>
<br>
What do you think?<br>
<br>
- Joakim<br>
<br>
nicolas de loof wrote:
<blockquote
 cite="mid:4c39e3030706050838n3b87e16dqb1d8843109f0d6ea@mail.gmail.com"
 type="cite">Hello,
  <br>
  <br>
To enhance archiva-1.0 support for maven1, I'd like to introduce a
layer
  <br>
between DavServlet and repository proxies connectors.
  <br>
As Joakim suggested, this is the scope of the Dynamic Artifact Serving
Layer
  <br>
in archiva roadmap.
  <br>
  <br>
I propose this API :
  <br>
  <br>
public interface ArtifactServingLayer
  <br>
{
  <br>
&nbsp;&nbsp; /**
  <br>
&nbsp;&nbsp;&nbsp; * Retrieve an artifact path in the repository based on the
resource
  <br>
string.
  <br>
&nbsp;&nbsp;&nbsp; */
  <br>
&nbsp;&nbsp; public String getResourcePath( String resource );
  <br>
}
  <br>
  <br>
The serving layer is responsible of finding the resource in the managed
  <br>
repository, with any required logic or temporary content, and to give a
  <br>
repository-related path back to the DavServer.
  <br>
  <br>
The default implementation could simply use proxies-connectors to find
the
  <br>
resource, and some interceptors / proxies could add features, like
  <br>
converting on-the-fly from a layout format to the managedRepository
layout,
  <br>
handle artifact relocation when a non-POM artifact is requested, or
anything
  <br>
we discover to be usefull.
  <br>
  <br>
What's your opinion ? <br>
</blockquote>
<br>
</body>
</html>

Mime
View raw message