Brian Murphy wrote a long blog post about the PAX Plugin which provides a good example of the power of Maven to act as an integration "bridge" between a number of unrelated technologies. In this post, Brian is using the PAX Maven Plugin from ops4j together with the gmaven-plugin and the maven-scala-plugin, he concludes with praise for Maven as an essential time saver:
"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.
