archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: 504 in maven, works everywhere else
Date Thu, 07 Dec 2006 09:02:28 GMT
Hello all,

I've now solved the problem by writing my own proxy. It's called DSMP 
(Dead Stu..Simple Maven Proxy) and can be used with the <proxy> setting in 

It has these features:

- It automatically mirrors any Maven repository, not only those mentioned 
in some config/POM/whatever file.
- It remembers error returns from respository servers, so update checks 
run really fast. In the next version, I'm thinking about pluggable status 
caching strategies.
- You can redirect requests from one URL to another. So, for example, if 
Maven believes that the maven-compiler-plugin has to be downloaded from, you can rewrite that URL in the proxy without 
having to touch either your local repository or the broken POM. Of you can 
direct all maven requests to your nearest proxy without having to change 
the maven configuration. This will even work if there are multiple URLs to 
access the same file on a server (for example, on, 
"maven2" is a link to "repository").
- It allows to merge patches into the downloads. This way, you can add 
your own fixes to broken artefacts without changing maven, without having 
to enable SNAPSHOTs and without having to worry that all your developers 
use the same proxy/mirror/repository settings.

Things I'm thinking about:

- Forbid downloads (always return 404 for some site)
- Lock down snapshots (always return "no, there is no newer version")
- Version migration. There should be a simple way to create a 
self-contained set of files which allow a new plugin/artefact version to 
run/compile. The idea is that one developer examines a new version, checks 
that it doesn't break the build, etc. and then tells the proxy "Ok, now I 
want everyone to be able to see the new version" or "Nah, drop it".

I was thinking if you might want to include this in Archiva. The proxy 
runs independent of any container, though. Since it can create an 
arbitrary amount of threads, starting it from tomcat or jetty might not be 
that smart.

Aaron Digulla

View raw message