“This ended up being a much longer article than I anticipated but we’ve covered a lot of ground. Maven has worked it’s dependency voodoo which saved an enormous amount of time downloading jars and messing with classpaths. We’ve seen how the PAX toolkit from OPS4J makes creating, modifying and provisioning OSGi bundles a breeze. While the actual code examples were pretty trivial, we successfully managed to code up bundles in Java, Scala and Groovy. I think this displays a lot of the power that is offered by OSGi and points to a bright future for enterprise development on the JVM.”

Project-driven Plugins: Distributed, Open Innovation

In this case Maven is bridging a number of popular projects that have all created well-documented Maven plugins. Maven is the essential “glue” that allows someone like Brian to take a number of unrelated technologies and use them in ways that the designers of GMaven or the Scala plugin could never have predicted. As Maven matures and continues to evolve its Plugin API, we’re starting to see more projects and more systems commit to using it as an enabling “platform” for development. Those projects that have adopted Maven have found it beneficial to host and drive the Maven plugins that relate to their project or technology. Better support for Maven increases the adoption of Groovy, Scala, and (in this case) OSGi.

The PAX plugin is maintained and hosted by the Ops4J project, the Scala plugin is hosted and maintained by the Scala community, and the GMaven plugin is hosted and maintained by the Groovy community. Each community feels strongly enough about providing Maven support for their technology that they have made it a part of their project. This is important because it suggests an evolving approach to the way Maven plugins are created and supported. Four years ago, it was unlikely to see a project like Scala or Ops4J creating and hosting a Maven plugin. While Maven was already ubiquitous, projects still didn’t see Maven support as a primary concern. Instead, the plugin development would happen as part of the Maven community or in an ancillary community of Maven plugins known as the Mojo project at Codehaus.

Mojo is an important bridge. It allows third-party actors to craft support for tools like JBoss and GWT, but it is an aggregate, disjoint community with a single mailing list, perfunctory release votes, and little shared discussion about architecture or planning. It is a free-for-all. While Mojo does host some essential plugins it is also a dumping grounds for half-finished, owner-less plugins. As more projects provide their own Maven support, people should consider moving project from Mojo to the projects that develop the specific technologies in question. This is the “distributed” open innovation that will encourage quality, well-documented plugins.

Why Companies and Projects Need to “Own” Their Maven Support

We’ve transitioned into a point where projects need to start hosting and owning the Maven plugins that enable developers to use their software. Google would have been better off if they had invested a day or two crafting a solid Maven plugin for AppEngine before they announced Java support. Similarly, they should think about driving the development of the GWT plugin. If your project’s artifacts are available through the Central Maven repository, that is a first step, but if your project also publishes an artifact and a really compelling Maven plugin, you’ve made it trivial and easy for people to adopt your technology. “Going to market” without good Maven support no longer makes sense, and you should know that more and more developers are start with the question “how does this fit into my Maven build?” If your answer is “shrug, we don’t use Maven”, it is very likely that they will seek out other solutions that provide better integration.

If you are a tool vendor or create an open source framework, you should be hosting your own Maven plugin as a part of your project. If you support an SCM like Perforce or Clearcase, you should make sure that your software provides a solid SCM provider for Maven. If your company or project develops a server, you should be working with the Maven project to make sure that it integrates with Maven. To do otherwise is to invite your customers or users to look elsewhere for better integration. If you let someone else drive your Maven plugin, you are really just delegating an essential support function to the community. The message you are sending is, “we don’t really care that you use Maven, it isn’t a priority, someone will do the integration work for us”. This is true, but when that happens, you lose an opportunity to interact with your users and your customers.

PS: Brian’s post also inspired me to file this JIRA issue on the MVNDEF book project. Our book’s need code examples that can be more easily copied to the clipboard.

So Grails 1.1 Beta 2 is out. Rejoice! There are many new features that are detailed in the release notes. However, one of the main ones in this beta is the new support for Maven….Regular readers of my blog will probably be aware of my long history as one who, ahem, is not particularily fond of Maven. Granted I am still not [particularly] fond of Maven, but it is the Christmas period and in the spirit of “why can’t we all just get [along]” I am proud to say that Grails integrates nicely with Maven now

Merry Christmas, indeed.

In the same spirit of “why can’t we all just get along”, I’ve had a similar shift in my opinion of Groovy over the years, I used to talk about Groovy as the wrong choice when compared to something like Jython or JRuby, but after having used Groovy in a number of projects, I ready to admit defeat.  While I’m still interested in Java inoperability with Ruby and Python, it is often much more straightforward to use Groovy than it is to deal with the “impedance mismatch” between something like JRuby and Java.  Groovy has turned into a mature and valuable language that offers tight integration with the JVM thanks to the continued efforts of Graeme and Guillame at G2One (recently acquired by SpringSource).

GMaven provides a great option for people interested in writing Maven Plugins in Groovy and also as a quick way to extend a Maven build with a Groovy script.

The following scripts are in Groovy and they can be invoked from the command line using groovy.  For example, if you want to run the QuickSearch.groovy script, you would run “groovy QuickSearch.groovy activemq” to search for artfiacts that contain the string “activemq”.   I tested these Ruby scripts using the latest Groovy 1.5.7 distribution.  Go to the Groovy page, click on Download, and download the Cross-platform Installer, this will install Groovy on your machine and also tell you what you’ll need to add to your PATH.

The Nexus REST API

The UI of Nexus is written in ExtJS and it makes heavy use of AJAX callbacks to REST services.  In fact, if you load up Nexus in a tool like Firebug, an extension for Firefox which allows you to trace all network activity, you will see that almost every action in Nexus triggers a call to a REST service. For more details about the Nexus REST services and for a pointer to the documentation, read the previous blog post in this series which was focused on a similar set of Ruby scripts.

If you would like to download the sample scripts in this blog post, you can download this ZIP file which contains four Groovy scripts: http://books.sonatype.com/tutorial-files/nexus-rest-groovy.zip

Listing Repositories

The first script simply lists all of the repositories in a Nexus installation.  Here it is:

def xml = "http://repository.sonatype.org/service/local/repositories".toURL().text
 
def root = new XmlParser().parseText( xml )
root.data.'repositories-item'.each {
  println "${it.name.text()} (${it.id.text()})"
  println "\t${it.resourceURI.text()}\n"
}

This script sets the pattern for the scripts to follow.  We construct a URL in String, then we call toURL() and get the text attribute from the method call. In one line we fetch the response body. then we use the XmlParser in Groovy to print out the Repository name, id, and URL. This script could not be more straightforward. This post is simply a pointer to the service and a quick demonstration so I’m not going to dive into the meaning of every single element in the XML document returned by the repositories service.   If you are interested in see the full set of elements that are available, load up the results of this service in a web browser by click on this: http://repository.sonatype.org/service/local/repositories.

Performing a “Quick Search”

def xml = ("http://repository.sonatype.org/service/local/data_index?q=" + args[0]).toURL().text
 
def root = new XmlParser().parseText( xml )
root.data.artifact.each {
  println "${it.groupId.text()}:${it.artifactId.text()}:${it.version.text()}"
}

This script follows the pattern of the previous script to list all repositories with the exception that it reads an argument from the command line.   This script performs a quick search by hitting the data_index service and passing in the q parameter.   This script simply prints out the groupId:artifactId:version of all the artifacts located.

If you would like to see an example of the XML that this service produces click here: http://repository.sonatype.org/service/local/data_index?q=activemq. In the full results, you’ll see more information such as the number of search hits available, the resource URL for each artifact found, and the context (or repository) in which the artifact is available.

Searching by Class Name

def xml = ("http://repository.sonatype.org/service/local/data_index?cn=" + args[0]).toURL().text
 
def root = new XmlParser().parseText( xml )
root.data.artifact.each {
  println "${it.groupId.text()}:${it.artifactId.text()}:${it.version.text()}"
}

This script is almost exactly the same as the prior script that performed a quick search.  The difference in this script is that instead of passing the q parameter, this script passes the cn parameter.   Passing the cn parameter causes Nexus to search for artifacts which contain classes that match the given value.   The results are going to look the same as the quick search query script.     To see the XML yourself, search for all artifacts which contain a class named HibernateDaoSupport: http://repository.sonatype.org/service/local/data_index?cn=HibernateDaoSupport.

Performing a GAV Search

def xml = "http://repository.sonatype.org/service/local/data_index?g=${args[0]}&a=${args[1]}&v=${args[2]}".toURL().text
 
def root = new XmlParser().parseText( xml )
root.data.artifact.each {
  println "${it.groupId.text()}:${it.artifactId.text()}:${it.version.text()}"
}

This final script takes three command line arguments: groupId, artifactId, version, and it performs a GAV (groupId, artifactId, version) coordinate search over the repository.