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 settings.xml.
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 http://mysterious.com/, 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 maven.sateh.com, "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
