archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nicolas.del...@gmail.com>
Subject Re: service layer API proposal
Date Wed, 06 Jun 2007 06:50:10 GMT
I agree with Brett about moving the DAV Url to a specific entry, as it
requires some specific handlign of GET as Joakim exposed to be compatible
with no-so-compliant Dav clients.

Based on this, if we access the repository as Dav via
/webdav/{repoId}/{path}, and map the /repository/{repoId}/{path} to a new
Get servlet, wy couldn't we combine layout detection with specific URLS ?

I mean /repository/{repoId}/{path} can detect legacy vs default maven layout
easily based on number of "/" in the path. If the apt path (for example)
overlaps with another supported layout, we simply need to provide an
alternative /apt/{repoId}/{path}. "repository" would then simply be a
reserved keyword for "autodetect requested type".


2007/6/5, Joakim Erdfelt <joakim@erdfelt.com>:
>
> 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 <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 ?
> >>>
> >>>
> >>>
> >
>
>
> --
> - Joakim Erdfelt
>   joakim@erdfelt.com
>   Open Source Software (OSS) Developer
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message