Over the past year (or more) we’ve been working to transition our internal development from Maven 1 to Maven 2. As you’ll know if you’ve kept an eye on Charles’ blog, it hasn’t been an entirely smooth process. But as we get deeper into it and slowly learn the zen of Maven, we’re seeing some real benefits.
As we’ve been going through that transition for our internal development, it’s also effected our external development.. With the Confluence build process in particular changing a lot from release to release, the process of building plugins became somewhat complicated. So we started working several month ago to totally revamp the plugin development process to take advantage of the tools that came with Maven 2.
It proved to be a much bigger undertaking than I had anticipated, but with lots of help from our Maven experts we released our brand new Maven-savvy plugin documentation:
In the old days, we had Plugin Development Kits for JIRA and Confluence. These were hundred-megabyte downloads that contained all of the dependencies necessary to build a plugin as well as a project template, some READMEs and plugin examples. (And that didn’t even include the source code, for those who had a source license.) In the new world, you just install Maven itself, and with a few commands Maven will go to the internet, fetch all of the correct dependencies (and the dependencies of the dependencies, etc) automatically.
In the old days, we had to create the product PDKs manually, and make sure that they worked correctly. Thanks to Maven 2’s dependency management, the external developers and our internal developers use exactly the same artifacts in exactly the same configuration. If it works for us, it works for you.
In the old days, you needed copy and modify a plugin template for each new plugin you wanted to create. With Maven 2, you use a maven archetype to create a fresh plugin template specific for each project. The plugin template comes pre-configured with all the right maven settings for packaging and deployment, testing and debugging, and our plugin hosting infrastructure.
In the old days, you had to manually attach source code for our dependencies if you ever needed to use a debugger. Now, maven does it for you with the default set project set-up. And if you have a product source license, a single additional command will integrate our licensed source code with your project.
In the old days, you had to set up a Confluence or JIRA instance separately in order to actually run your plugins as you developed. Now, thanks to some Maven 2 hacking, there’s a single command that will download Tomcat, install Confluence or JIRA, start them up, load sample data, then install your plugin for testing. And once you’ve started the application once, you can just leave it running while you uninstall and reinstall your plugin. That eliminates the most time consuming part of the process: restarting Confluence or JIRA.
All in all, the process of setting up and developing a plugin is simpler, more efficient and more automated thanks to our embrace of Maven 2. This new documentation replaces all of the older documentation we’ve been struggling with for the last year. Note, this only covers the general aspects of Atlassian plugin development — all product specific plugin documentation still lives with the product spaces, and isn’t as much affected by the move to Maven 2.
Go check out the new docs, give them a try on your next project, and let us know what you think.
We’ve also written a page about how to convert an existing plugin to take advantage of the new framework.
If you experience any hiccups or confusion, just let us know by commenting on the docs, and we’ll do our best to clear things up.