This touches on my pet peeve about maven. I wish that I could download a zip file containing the subset of central containing maven's core plugins and their dependencies. I would then gladly use it as my central mirror and work productively on my projects without having to worry about central.
I also wish that Maven did not access a central online repository by default, so I wouldn't have to go through the extra effort of preventing it from doing so. When Maven is installed "out of the box", it could be configured to use its own self-contained repository that came with the installation. If I want non-core plugins or other things, then I could tell maven to use an online repository. In other words, I want an integration-tested self-contained maven release. Is that a lot to ask for from a dependency management tool? I don't have that now, so I have to do my own version managemnet of all maven plugins that I use. When I try to use a plugin or a plugin feature that I haven't used before, I have to go through a sometimes painful process of figuring out which is the version of the plugin that works and is consistent with all my existing projects and plugins. I've more than once used a plugin version mentioned in the documentation, only to find out that it's buggy or obsolete and I need to use a newer version (or sometimes even a completely different groupId/artifactId). Can maven, the tool, be separated from central, the grand repository of java libraries? I don't want central. If I want library X for my projects, I can go to library X's website, download X, and add it to my repository. If library X wants to be maven-friendly, it can include a script that lets me add all its jar files to my repository easily, so I don't have to add them one by one manually. Wouldn't this reduce traffic to maven central? But maven doesn't come in a box. Instead, it lets its plugins download whatever dependencies they want from central. It seems that it even gives them the freedom to specify a range of versions, or any random version they find, so that what a build does is unpredictable and dependent on the vagaries of a moving target central repository. It's amazing that it works most of the time, but it fails too often for me. One of the most annoying problems I ran into with maven was when I setup a central mirror containing my old local repository, deleted my local repository, and then tried to rebuild it by doing a build. mvn went on to happily copy things from my central mirror, until it couldn't resolve a dependency. It has something to do with a "RELEASE" version of a plugin not being found. I have aparently gotten a central artifact at some point in time that has an integration problem with other artifacts and ends up using an artifact version that it doesn't explicitly ask for. I believe it's related to the site plugin, which I have since stopped trying to use. In the end, I went back to copying my central mirror to my local repository (something easily done with svn, which I use as my repository manager). -Alex On Tue, Nov 25, 2008 at 5:27 PM, Brian E. Fox <[EMAIL PROTECTED]>wrote: > The central repo has been undergoing significant load lately, most > likely the result of people crawling and attempting to download all 70GB > of it. I'd like to point out the availability of additional mirrors that > you can use to increase your download performance and reduce the load on > central. These mirrors are updated daily right after central pulls in > all the new artifacts, so they are as fresh as central. Find the list of > mirrors here[1]. > > > > Also, for those of you with multiple developers in a single location not > using a repo manager, what are you waiting for? There are plenty to > choose from and numerous reasons to do so, particularly the ability to > isolate yourself from transitive network outages or slowdowns. You can > read more about why and the existing repo managers at [2],[3] and a > comparison grid here at [4] > > > > Also, if you are using a repo manager, make sure to correctly configure > it to not make requests to public repositories for your internal > artifacts. Otherwise you are making a ton of requests for things that > will never be found, increasing the bandwidth usage on your side and > ours. Also it gives away potentially sensitive information as someone > could scrape the logs and figure out what you're up to internally based > on these requests. Nexus lets you configure routing rules so you could > exclude com.yourcompany.* from central. Archiva has similar > functionality, I'm not sure about Artifactory. > > > > Please be a polite repository user. These repos and mirrors are provided > free of charge but there is a real cost behind providing this bandwidth. > Scraping the entire repository starves other users and increases the > cost of providing these repositories to the community. If the mirrors > start getting abused then we may find less geographical redundancy as a > result. There is never a reason to download the world if you have a > repository manager that is caching everything you need locally. > > > > [1] http://docs.codehaus.org/display/MAVENUSER/Mirrors+Repositories > > [2] http://maven.apache.org/repository-management.html > > [3] > http://books.sonatype.com/maven-book/reference/repository-manager.html > > [4] > http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feat > ure+Matrix > > > > Brian Fox > > Apache Maven PMC > > http://blogs.sonatype.com/people/brian > > > > > >
