Be a good Maven citizen — Don't scrape the whole damn central repository!
For the last few nights we have had some particularly bad Maven citizens averaging almost 3000 connections in a 10 minute period. This particular abuser emanates from the Netherlands and this is the first time I have completely blocked an IP permanently from the central repository (I’m sure they will just use another one but it’s a start). I’ve started trying to track down who exactly the IP (82.94.207.11) belongs to. I have a pretty good suspicion who it is.
We’re happy to work with groups who want to mirror the repository using rsync provided you are using that mirror to service other Maven users. Trying to scape Maven central cripples the primary feeder to all the mirrors and the synchronization with other open source organizations we work with. By opening 3000 connections to central and scraping it you screw every other Maven user on the planet you idiots. Anyone who knows me knows how rabidly tenacious I am and I will track down every IP you have and create blacklist that every Maven mirror and Maven repository manager will just drop connections to. If you make the life of Maven users more difficult then necessary I will find a way to do the same to you.
Nexus Maven Repository Manager 1.0 Released
Version 1.0 of the Nexus Maven Repository Manager has been released. Since the previous beta just 2 weeks ago, a decent number of fixes where made including some enhancements to the Nexus Indexer to improve search results for attached artifacts. Some changes where made to the configuration storage to simplify future upgrades, so be sure to view the changes and upgrade notes before upgrading.
Since this is a 1.0 release, it’s a good time to recap all the functionality that Nexus provides.
First and foremost, Nexus is a Maven Repository Manager, which means it serves as a local caching proxy for Maven repositories. It is also able to host internal snapshot and release repositories for your organization. Also included is the ability to serve M2 repositories to Maven 1 and vice-versa via “Virtual Repositories”.
Nexus allows you to take multiple repositories, whether proxies, hosted or virtual and logically present them to Maven as a single repository. The power in doing this is that control of adding new repositories is now centralized instead of spread across many poms or developer settings files. Along with Centralization of the repositories comes the ability to block and override dependencies as needed for the entire organization.
The major distinguishing factor of Nexus is the ability to fully manage and configure the system using an Ajax UI built with ExtJS. Using Ajax allows the UI to be fast and responsive so you can make changes quickly without waiting for JSP pages to load after each click. The Nexus UI is actually a REST client since all the communication to the server is done via REST api’s which means everything is integrate able into scripts and other tools as needed.
Another distinguisher is the memory footprint of Nexus. It runs on a fully loaded system such using as little as 28mb of ram. Even our public instance, which is pounded constantly by the Maven CI system is running with the default heap space of 64mb. Nexus is able to do this because it does not require a heavy database for artifact storage (they are stored in a regular Maven2 file based layout, making incremental backups a snap), and it doesn’t use a heavy webdav implementation. The Maven gets and puts are fully supported by the same REST api that the UI uses…no extended wagon is required with Nexus.
The Nexus Indexer component is used by several repositories, including Central, to publish searchable indexes of Maven artifacts. Several tools, including M2Eclipse are able to consume these indexes and allow class file level searching in IDEs. Nexus is able to proxy the remote indexes as well as produce them for internal repositories. Like the repository aggregation, Nexus is able to aggregate all the indexes into a single logical group, providing a single download for each developer using M2Eclipse. The indexes are also fully searchable via the UI. An applet is included to locally calculate checksums and then search the index to fingerprint unknown / unversioned artifacts.
All maintenance tasks are executable on demand and also via a scheduler. These things include snapshot repository clean up, unused proxy artifact purging, reindexing, and others.
Nexus is secured with a role-based security implemenation built on top of the JSecurity framework. This provides a light yet powerfull and extensible security model. Every REST api is exposed as an individual privilege that can be grouped into roles. Also included is the ability to control create, read, update and delete access for subsets of the repository based on their path. This means you can logically partition repositories into sets of artifacts maintained/owned by separate teams…in fact these sets of artifacts are able to span repositories (think snapshot, release and staging for example) using the same “Repository Target” to simplify security administration.
RSS feeds are provided for notification of newly deployed and/or cached artifacts as well as configuration and system state changes. Malformed poms are also logged to a feed for future resolution.
For those of you tired of manually deploying 3rd party / commercial jars and fighting with the command line deploy:deploy-file, Nexus provides a UI for uploading directly to the repository. A pom can be included or just the basic information provided and Nexus will create a pom for you.
Best of all, Nexus has professionally produced documentation that is included with the free online Maven book.
Nexus is an open source project using the GPL license so patches and feature contributions are welcome.
Check out the Nexus site for more information and links to the mailing lists, source, faqs, and more. You can find us on IRC at irc.codehaus.org, #nexus for questions, comments and assistance, and follow SonatypeNexus on twitter to see what we’re up to next.
What are you waiting for? Download your copy of Nexus today.
Sonatype's Tycho, m2eclipse and Maven: Eclipse Plugin and OSGi development simplified
On the m2eclipse mailing list Alexandre Sauvé asked about the future of Eclipse RCP-based application development with Maven and so Igor Fedorenko, who leads our development on Tycho, responded with a short summary of what we’re planning and what’s been accomplished so far with Tycho.
Here’s what Igor had to say:
First of all, I have to apologize for keeping Tycho development plans and progress to myself. I would like to thank you for bringing this up and will try to both explain our grand vision and what we already have or will have implemented in the near future.
The big picture. Ultimately, we want tycho to be one-stop solution for doing Eclipse and OSGi development with Maven 2 (actually, 3, more on this later). We believe there are two distinct development workflows, when developer explicitly creates and maintains OSGi manifest and other Eclipse/OSGi metadata (we call it “manifest-first”) and when OSGi metadata is generated by the build based on information available from pom.xml (“pom-first”, naturally). We plan to support both development workflows.
In manifest-first mode, tycho will use Eclipse/OSGi metadata and OSGi rules to calculate project dependencies dynamically, at build time. It will support all attributes supported by Eclipse OSGi resolver (Require-Bundle, Import-Package, Eclipse-GenericRequire, etc). It will use proper classpath access rules during compilation. It will support all projects supported by PDE and will use PDE/JDT project metadata where applicable. One important design goal is to make sure there is no duplication of metadata between pom.xml files and Eclipse/OSGi config files. In fact, tycho will support “pom-less” projects, where all required build metadata is derived from Eclipse/OSGi config files.
In pom-first mode current plan is to provide similar set of features as in felix/bnd plugin, although I do not know if we’ll be able to share any of the code. Additionally, Tycho will support Eclipse-friendlier Require-Bundle and will provide better support for developing multiple related OSGi bundles (I have not checked recently, so felix/bnd may already support these).
In both modes tycho will support remote repositories both as source and sink for artifacts. We plan to support maven repositories, p2 and update sites, although level of support will likely vary. There will also be integration between m2e, tycho and pde to make the three work nicely together.
So these are the plans… Disclaimer: plans do change! 
Now to what tycho is already able to do. Our first goal was to enable m2e continues build, so we started with manifest-first mode and I believe covered most of manifest-first features described above. Tycho already uses Eclipse/OSGi metadata to resolve project dependencies by OSGi rules and injects these dependencies into maven project model dynamically, at build time. It supports bundle, fragment, feature and update site projects (shame on me, but no RCP application yet). It knows how to run junit test plugins using OSGi runtime. Two big features that are still missing, are support for pom-less projects and work with artifact repositories, although there is prototype of target platform materialization from p2 repository already. There is also some rudimentary implementation of pom-first mode, but its usability outside of m2e build context is probably limited. Many smaller features are still missing and I am certain there are quite a few bugs too, but I think overall tycho code is in reasonably good shape already.
Few words about relationship between maven and tycho. Tycho is not morphing into maven, but it provides maven extensions and plugins that enable maven to work with Eclipse/OSGi projects. Some of tycho functionality, especially OSGi dependency injection, relies on maven features only available in maven 3.0 which was very recently renamed from 2.1. Since there is no maven 3.0 release yet, current tycho distribution includes complete copy of maven 3.0-SNAPSHOT.
As for contributing to the project… well, this would be really awesome . I think the best way to start is to try tycho and see what is missing to support your projects and development workflow. Then we can work together to implement missing features, fix bugs, etc. I have simple demo that shows how to use tycho to build set of simple projects and some user-level documentation. I will try to make this available later today. I will also provide tycho dev env setup steps, so you can start looking at the code if you want to. And tycho distribution is already available from the Sonatype Maven repository (looks for the latest .zip file)
I hope it answers your questions, but feel free to ask more, especially if something is not clear or does not make sense. You can subscribe to the m2e mailing list if you want to learn more.
Nexus, now on Twitter
If you’d like to get up to the minute Nexus Maven Repository Manager release status and other thoughts, you can follow the project on Twitter:
http://twitter.com/SonatypeNexus
And if you’re interested in the random thoughts of other Sonatype Crew, you can find them at: M2Eclipse: http://twitter.com/m2eclipse Brian Fox: http://twitter.com/brian_fox Jason van Zyl: http://twitter.com/jvanzyl Eugene Kuleshov: http://twitter.com/euxx
