Download
Proximity
(current is RC9)
Proximity2, more precisely the "core" engine, will continue to be a heavily customizable "proactive mirror" thingie, but it's main "goal" will not be Maven Proxy anymore.
I am an old SuSE/SUSE/openSUSE Linux distro user, and also frustrated that this distro still has no proper Installation Server (Yes, YaST can do it, but it is not what I want). So, the new px-core engine "appliance" will be just as Proximity1 was for Maven: openSUSE installation server, RPM-MD repository hosting and proxying and extensive package search engine.
So, existing Proximity Maven Proxy users, you are encouraged to switch to Sonatype Nexus, while others will have to wait for px2-core engine and Proximity2 openSUSE (codenames Liza, Px2 for Lizards) application till end of this or beginning of the next 2008. year. Have fun!
In short: Proximity is in function somewhere between http-proxy and proactive-mirror. Proximity is not a HTTP Proxy (something like Squid is). It requires Java 1.4.2 platform and is a standard J2EE Web Application (altough, the px-core engine is pure J2SE application).
One of it's primary use is as Java web application to serve as Maven proxy on our company's intranet. As for reducing outgoing traffic (caching central and other maven repos), aggregating more repositories (reducing project config) with acting as one logical repository and for publishing in-house and other external maven artifacts which are not uploadable to "central" (like commercial projects, J2EE Jars, etc...).
Proximity (px-core) is a modular fetch-and-cache engine with various extra capabilities like indexing. The Px-Core module is driven by Maven bindings (px-core-maven) to implement a Maven Proxy application behaviour.
You can look at Proximity as something that comes "in parts" (IKEA furniture, LEGO, etc). While Proximity delivers itself in "default" flavour and various packaging (bundled and WAR), that should suffice the most of Maven2 developer needs, Proximity is actually just a "bunch of beans", with various local and remote peer implementations (you can reach "central" repo even over FTP, did you know that?). It's like a toolbox, and it is left to you to do the assembling part of it (or just use the "preassembled" defaults).
Proximity heavily uses the IoC capabilities of the latest containers, this is the reason of it's most hated (hard to re/configure) or beloved (easy to adapt to any needs) nature. Proximity is container independent. The default container used with Proximity is Spring Framework, but the are existing instances working in Plexus too.
The main thing behind "hard to configure" is these two reasons: