I think it help. The good thing about two existing known maven-proxies (codehaus maven-proxy and Proximity) is that they're actually 2in1 solutions. They are NOT strictly a proxy as a HTTP proxy. The are just ABLE to behave like http proxy (or the logic that drives them is similar to HTTP proxy).
They are also fully functional when it comes to repository hosting too. And you have extras: fast searching, access management, etc. My practice with Proximity is following: define proxied repo for central, codehaus, etc... define LOCAL (so not proxied reposes) like inhouse, etc. Proxy storages are handled ONLY BY Proximity. And PUBLISH local proxy storages using standard ways (ftp, sftp, sambe, nfs...) and make your developers DEPLOY onto them using Maven2 itself! In case of a commercial project, it should be right in the superpom where is the deployment area, etc... In our house, we use JDS2* with well defined paths and URLs. On POM creation a developer knowing the project ID of project (this ID is used in paths, URLs, mailing list names, etc something like SourceForge project id) can write complete POM almost out of his head. And it's easier to maintain (one application in company does proxying and hosting) - one backup - one thing less to worry. Some WIKI scratch that tries to define JDS2 and what it should be. https://is-micro.myip.hu/trac/ismicro-jds2 ~t~ On 5/26/06, ben short <[EMAIL PROTECTED]> wrote:
Well you wouldnt. The proxy is used to cache ( and persist ) the dependancies that are hosted on the remote maven repos, like codehaus and ibilo. The means that your developers have access to the dependacies at a high speed, after they have been downloaded by the proxy. Now an inhouse repositry would be seperate. In this you would store all the jar that you produce and want to share between your development team. Does that help? Ben
