Making the Most of Maven: Nexus, Hudson, Sonar

by
Tags: , , ,
Category:

Maven is a build tool. I like Maven because it supports dependency management, consistent builds and a modular code base. But if you are just using Maven without using Nexus, Hudson, Sonar you are really missing out on a lot of goodness.

Nexus is a Maven repository manager, Hudson is a CI server, and Sonar is a code metrics server. All three share some commons attributes:

  1. They are web-based server applications
  2. They have an open source license
  3. They are easy to install — just unzip and run the embedded app server (Jetty or Winstone) or deploy as a WAR into your existing app server
  4. They have very professional looking user interfaces. Don’t underestimate the value of a good paint job when getting buy-in for a new product.
  5. They are fairly easy to extend. I’ve written plugins for all three.
  6. They have active communities
  7. They have commercial support available if you want it
  8. They are continually being updated with new releases containing features and bug fixes

OK, great — all three are web-based and awesome. But what do they actually do?

Nexus

Nexus is a Maven repository manager. A vanilla Maven repository is just a web server with a directory structure of versioned jars with some XML metadata. The default Maven repository is a server called “central” with the URL: http://repo2.maven.org/maven2. Maven central is a good repository of a large number of open source jars.

However many organizations don’t want their builds to be dependent on and constantly downloading jars from central, which is a public Internet site, for performance, security, and even legal purposes. What if central goes down or gets really slow? What if central gets hacked? What if developers use a jar in central that is licensed in a way your organization doesn’t permit?

Running your own Maven repository that caches jars from central is a good idea. And what about your various projects and the jars/wars they produce? Running your own Maven repository within your organization allows you to host and version your own jars and make full use of Maven dependency management features.

While you can use any old web server as a Maven repository, there are many administrative headaches to consider:

  • Security — who has access to what
  • Searching — how can you find out what’s in the repository
  • Purging old SNAPSHOT versions — eventually your web server will fill up with old SNAPSHOTs jars
  • Scalability — what happens when you can’t fit everything on a single web server
  • Maintenance of settings.xml — restructuring repositories on your server can force you to push out a new version of settings.xml to all of clients

Nexus is a Maven repository + a bunch of administrative features that address all of these problems.

  • Security — Nexus has a fine-grained roles/permissions model, and integrates with LDAP
  • Searching — Nexus has a search feature based on Lucene. You can search for a particular artifact by group ID and artifact ID, or you can search for a particular class and find the jar(s) that contains that class.
  • Purging old SNAPSHOTs — Nexus allows you to schedule jobs to perform periodic tasks like purging old SNAPSHOTs
  • Scalability — Nexus has a proxy feature that allows you to run multiple instances that proxy to each other for redundancy or just to distribute load.
  • Maintenance — You can create logical repositories, called groups, which are the aggregate of many physical repositories. The effect is similar to DNS — you give a logical name to something that never changes which allows you to change the underlying physical structure without adversely effecting users. This means you don’t have to change the repositories listed in settings.xml for your users as often.
  • Programmable API — Nexus provides a REST API to perform most functions, and even allows you to extend the REST API via plugins which is very useful.

Hudson

Hudson is a continuous integration or CI server. If you aren’t familiar with CI, the goal of CI is to shorten the feedback loop from the time a developer makes a change until the time he/she sees the result. In practice this means a CI server periodically polls a version control system at short intervals, e.g. 15 minutes, and if it detects any code changes, it downloads the new code and tries to build it. If the build fails, then emails are sent to everyone on the development team pointing out the offending code and person who did it. The principle is “Better code through shame” and it works well.

There are other open source CI servers in existence. CruiseControl is a popular one, and was one of the first. The advantage Hudson has over any other that I’ve used is ease of use. It literally takes me 2 minutes or less to setup a new Hudson job via the user interface — all you need is the Subversion URL of the project that you want Hudson to watch and continuously build. Hudson also has a decent security model although it isn’t as flexible as Nexus’. The Hudson REST API is very useful for managing large numbers of Hudson jobs programmatically. And Hudson has a large number of useful, free plugins.

Sonar

Sonar is a code metrics server. It analyzes your code using a variety of metrics (cyclomatic complexity, Bob Martin’s OO metrics, dependency cycles, duplicate code, lines of code, etc) and runs various rules checkers to detect bad code such as PMD, Checkstyle, and FindBugs. Then it tracks those metrics and rules violations over time so you can see whether your code is getting better or worse.

Similarly to Hudson, the best part about Sonar is that it is incredibly easy to use. To get it setup, you first run a Sonar server instance. Then you use the Sonar maven plugin to analyze your Maven project by running “mvn sonar:sonar” and *magically* your code gets analyzed and the results appear in a beautiful dashboard on the Sonar server. That’s it. And to make this even easier, there is a nice Sonar Hudson plugin that allows you run Sonar on any Hudson job by checking a checkbox. Gathering metrics and trending them over time across many projects is generally a huge hassle so it never gets done. With Sonar, it is completely built into your CI process so it couldn’t be easier.

Conclusion

I’ve been using Nexus, Hudson, and Sonar for about 2 years now, and I wouldn’t consider using Maven without them. They are easy to use and provide so much value — especially considering they are free open source — that they really are worth an evaluation if you’ve never used them.