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 pr
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.po
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 c
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 fo
