Maven, m2e and the Nexus Repository manager
Jetty-7 is moving to eclipse, cometd-java is moving from jetty to cometd.org and the maven build system for dojo has been moved out of the main dojo tree. So I'm involved in some major refactoring of three interdependent projects at the same time. This refactoring would be impossible to contemplate without the tools support for these projects. Maven, m2e and nexus are making my life a lot easier.
Maven
Apache Maven is a build tool of the “you'll love it or you'll hate it” variety. It uses convention over configuration in order to make advanced behaviour available with little effort. If the maven conventions are what you want, then you'll love maven. Luckily the conventions that maven uses encapsulate some best practises that many of the haters really should consider using. The winning feature for me is the declaritive management of dependencies. With maven, you know what you depend on, what version you depend on and why you depend on it. The following output shows the transitive dependency tree for the cometd demo module:
~gregw> mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building Cometd :: Java :: Server Demo
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree]
[INFO] org.cometd.java:cometd-java-demo:war:1.0-SNAPSHOT
[INFO] +- org.cometd.dojox:cometd-dojox-examples:war:1.0-SNAPSHOT:compile
[INFO] +- org.cometd.jquery:cometd-jquery-examples:war:1.0-SNAPSHOT:compile
[INFO] +- org.cometd.java:cometd-java-server:jar:1.0-SNAPSHOT:compile
[INFO] | +- org.cometd.java:cometd-api:jar:1.0-SNAPSHOT:compile
[INFO] | +- org.eclipse.jetty:jetty-util:jar:7.0.0.M0-SNAPSHOT:compile
[INFO] | \- org.eclipse.jetty:jetty-continuation:jar:7.0.0.M0-SNAPSHOT:compile
[INFO] | \- javax.servlet:servlet-api:jar:2.5:provided (scope managed from compile)
[INFO] \- org.eclipse.jetty:jetty-servlet:jar:7.0.0.M0-SNAPSHOT:provided
[INFO] \- org.eclipse.jetty:jetty-security:jar:7.0.0.M0-SNAPSHOT:provided
[INFO] \- org.eclipse.jetty:jetty-server:jar:7.0.0.M0-SNAPSHOT:provided
[INFO] \- org.eclipse.jetty:jetty-http:jar:7.0.0.M0-SNAPSHOT:provided
[INFO] \- org.eclipse.jetty:jetty-io:jar:7.0.0.M0-SNAPSHOT:provided
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Apr 01 17:46:14 EST 2009
[INFO] Final Memory: 11M/65M
[INFO] ------------------------------------------------------------------------
With such information available during my refactoring, I can quickly see if any dependency (or a transitive dependency) is pointing to the org.mortbay.jetty artefacts. Building against changed dependencies is just a matter of updating the pom.xml file and maven will download and install the jars on my classpath.
M2Eclipse
The features of maven are integrated into the eclipse IDE with the m2eclipse plugin, which has now become a tool that I cannot live without. The plugin uses the maven pom.xml files to setup eclipse projects, their dependent projects and external dependencies. To start a new work space and import the 24 sub-projects of jetty-7 is just a few simple clicks and something that I do routinely during refactoring to check that the code builds from a fresh start. Not only are the dependencies automatically added to the project build path, but m2eclipse is able to download the javadoc and source from the maven repository, so that eclipse can provide detailed help and navigation within the editors.
The GUI goodness of m2eclipse includes a graphical view of the dependency tree provided by maven:
Nexus repository manager
Once the refactoring is over, it's time to deploy the built artefacts. The Maven view of published artefacts is that they are immutable and that once version x.y.z is published, then it is published forever and it is not an option to republish or delete a version. Maven is about reproducable builds and immutability of published versions is key to that.
Thus publishing released artifacts is something that needs to be done with great care and few errors. Unfortunately, I'm one that subscribes to the release early and release often approach, so there have been a few DOH! moments when I've previously made jetty releases. During refactoring, the risk of breaking the release mechanism is high and testing is difficult if the results are immutable.
Thus having a repository manager is key to releasing maven
artefacts so they can be staged, tested before publication. Thus the
Nexus
repository manager has now become a vital step in the release
procedurers of the dojo toolkit, the cometd ajax push framework and
the jetty @ eclipse project. The kind folks at sonatype
have made an instance of their Pro Product available at
http://oss.sonatype.org for a
growing list of open source project to publish their artefacts to.
The rich web interface allows the repositories to be viewed, searched
and managed and there are other features that I've not used that are appropriate for management of a corporate repository.
Nexus acts as a staging area where releases can made available in a repository before being promoted to the public repositories (or to a private coporate repository for those few developers left not working on open source projects). The developers on dojo, cometd and jetty are now coordinating their parallel refactors using this repository:
These tools are really contributing to improved productivity and quality of the the jetty and cometd projects.
Posted at 11:50PM Apr 01, 2009 by gregw in General | Comments[0]
