Splitting up this discussion ...
First is the "detection" of clients.
Archiva has to manage not only the artifact, but also the pom/model
version too.
Example:
A maven 2 client can request either of these format URLs.
http://machine.com/repository/internal/commons-lang/poms/commons-lang-2.1.pom
http://machine.com/repository/internal/commons-lang/commons-lang/2.1/commons-lang-2.1.pom
On maven 2, these can both be of model version 4.0.0 and it'll work.
On maven 1, these have to be model version 3.0.0 to work.
Oh if only the client could identify itself, then wouldn't be a problem. :-)
The reason for the "/get/{implementation-id}/{layout-path}" is to
clearly identify the intent of the client, and
compensate/migrate/regenerate/translate the requested resource for the
client. It is clear, not overloaded.
As it stands now, the bidirectional layout has a tough time with maven 1
layout requests of non-typical artifact types (seen commonly in
corporate environments). The lack of a 1::1 relationship between file
extension and artifact type makes things even more difficult for
"detection".
In short, I thoroughly dislike the idea of detecting the serving layer
based on path information.
I see it as a band-aide, a short term solution, one that will cause a
mess of spaghetti code in the Repository servlet.
When we move to other artifact providing concepts, yum/apt/osgi, etc...
there is tremendous overlap on the path structure, so much so that this
detection route is just a dead-end to me.
- 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 <[EMAIL PROTECTED]>:
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 ?
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
