This sounds good on paper, but in practicality it could be troublesome. First of all, there are many more moving parts and we can't be sure of or control the reliability of all these remote repos. Recall the trouble we had with Ibiblio a few years ago and the instability there. Since central moved to Contegix, it has been remarkably fast and reliable. I believe there is also a hot back already available for this.
Additionally, for locations that have restrictive proxy/firewall policies, this would be a nightmare. They would constantly need to have access opened up to new repos and it might be impossible to predict ahead of time exactly which ones they may need. For those reasons, I would be -1 on this. --Brian -----Original Message----- From: David Siefert [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 13, 2007 4:36 AM To: [email protected] Subject: Proposal for a Maven Dependency Registry Hi, I am not sure if anyone has already asked about this, but in case not I am proposing the idea now: a Maven Dependency Registry. I created a very simple web application (could not attach here--detected as spam) that accepts requests for files (presumably the Maven 2 convention for a dependency located in the repository), looks up a registry of groupId's based on a properties file, and sends an HTTP 302 redirect response with the appropriate registry location's full path. It is not perfect yet--it is just a Proof of Concept. I am attempting to solve some issues, namely: 1> Relieves the burden of the Maven projects staff of maintaining the big, bloated, disorganized repository. This effort will be handled by those who actually release libraries (such as JBoss.org, Codehaus, Apache projects, etc). The repo1.maven.org should eventually die off (dependencies removed as others register their groupId with their repository), or only be left for Maven itself and the bundled plugins that are maintained. 2> Since the original authors of the dependencies will maintain their own small release/snapshot repository, all the POM information will automatically be bundled, and nothing has to be fished down (transitive dependencies that were not specified because the libraries were loaded from a non-Maven project). Transitive dependencies stay on their respective repository and don't lose their valuable Maven build information. 3> Speedier access to the Maven core repository, and other repositories for that matter since the repository is smaller and not needed for everything. 4> Lower maintenance requirements of the Maven team--more time for bug fixing. Maybe these aren't good enough reasons, or developers of Maven may see a reason NOT to have a registry. That is why I am only proposing the idea and presenting a small proof of concept. If it is not ideal, then I won't waste my time developing this any further. I appreciate any and all feedback. Thanks, David Siefert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
