Maven and OSGi for Application Lifecycle Management

It’s no secret that Maven and OSGi are technologies that get a lot of hype.  But it’s also no secret that working with them can cause a whole host of headaches.  So one has to question why would you want to go through that hassle when you’re doing perfectly fine with Ant based builds?

The reason is that these tools make it possible to move towards a loosely coupled, open source,application lifecycle management environment that takes you from development to production deployment with minimal manual processes.  The basic flow is shown below.

• Developer Workstations - Machines used by your developers with your company’s IDE(s) of choice
• Version Control System (subversion, CVS, git, etc) - Manages your source code, but not your build artifacts
• Build Servers (Hudson, Cruise Control, etc) - Automatically polls the version control system for changes, performs builds/tests, and publishes build artifacts (OSGi bundles) to the Maven repository
• Maven/OSGi Repository (Artifactory, Nexus, etc) - Manages your maven build artifacts as well as mirroring external third party artifacts approved for use in your organization
• OSGi Application Servers (Spring dmServer) - OSGi servers that are connected to the Maven/OSGi repository so that deployment is as simple as choosing the artifacts you want to run on them, and they automatically take care of downloading the appropriate versions of any dependencies
• Requirements/Issue/Defect Management (JIRA, Bugzilla, Requisite Pro, etc) - There are a large number of products in this genre, each with their own benefits/drawbacks depending on the culture and processes in your organization, so this integration is left out of the diagram above.

So where does Maven fit in?

Basically, Maven provides an out of the box approach for packaging your build artifacts, assigning versions to them, declaratively specifying your dependencies, and automatically downloading those dependencies from a Maven repository.

But what is a Maven repository?  There are public repositories containing open source artifacts that you can connect to by default, but where do you put your private artifacts?  Unfortunately, Maven doesn’t provide a repository server, though you can use a combination of Apache, FTP, shared file systems, etc to build one yourself.  But what if you want to mirror external repositories?  Or how do decide how to manage security for your repository?  Dealing with these issues is often where companies that try Maven out stumble.

Fortunately, there are Maven repository products like Artifactory or Nexus available to handle those issues for you.  Both products are open source with commercial support available and I would highly recommend choosing one of these products over rolling your own Maven repository.

With your projects using Maven for builds, and with a Maven repository in place, you can now use your automated build tools to automatically build code from your version control system and publish the artifacts to your Maven repository.  And now it is very easy for other development groups in your organization to browse what artifacts are available and to depend on specific versions of those artifacts.

But how do you deploy those artifacts to your test and production environments?  That’s where OSGi comes in.  OSGi supports the concept of bundles which are basically packaged Java artifacts that have a specific version number, and which declaratively specify the other artifacts that they depend on.  Sound familiar?  With your Maven infrastructure in place, you can leverage it’s declarative dependencies and Maven OSGi plugins to publish your Maven artifacts as OSGi bundles.

OSGi bundles, in turn, run on OSGi servers like Spring dmServer, which are similar to JEE servers and are responsible for loading OSGi bundles and handling the runtime dependency management.  But where should they load those dependencies from?  Again, the synergy with a Maven repository covers that.  The same repository you used for build management also holds your deployment artifacts.  And now you have closed the loop from development to production with minimal manual intervention:

1. Developers check in code to version control
2. Build server builds code, runs tests, and publishes artifact to Maven repository (no chance for builds to only work from a developer’s machine, and no need for release managers to know how to perform builds)
3. Release Managers publish a specific version from the Maven repository to test servers
4. Testers test a specific application version and approve it
5. Release Managers publish that version to the production servers

It goes without saying that you could follow this same lifecycle with tools other than Maven and OSGi.  You could create custom Ant build scripts, use Ivy for dependency management, write your own scripts for packaging and publishing JEE artifacts to a repository, write custom scripts for deploying those JEE artifacts to your JEE servers, etc.  And maybe your solution will end up being better than the Maven and OSGi approach.  Maybe it won’t.  But either way, that is a lot of custom scripting, and it’s a lot of things to document and maintain and to train every new employee on.

Whereas if you use Maven and OSGi, you get the benefit of an ever growing set of tools that operate with those technologies, including many cloud related tools.  You benefit from the growing library of books, articles, and blog posts on those technologies.  You benefit from being able to look for employees who already have experience with your build tools and lifecycle.  And you get this without locking yourself into a proprietary vendor solution.