Skip navigation

A couple of weeks ago, I wrote a post Announcing Jive Maven Archetype Changes.  This was just the first step in a series of changes to make both the use and the management of Jive Maven archetype-generated projects easier.  The first step, described in the aforementioned post, discussed the new unified archetypes, which, going forward, will support Jive 6, 7, and beyond. Next, we abstracted the archetypes altogether with the creation of the Jive Project Plugin for Maven, described in How To: Create a Custom Jive Project, making the generation of a project as easy as typing a simple, easily-rememberable command, which will always pull from the latest version of the unified archetypes, so you get all the latest improvements for your new project.


While these first steps make project and plugin creation a cinch, they don't help much with maintaining your project.  You still need to know which version of Jive to point to, and which versions of the EAE and Search server libraries to use for that version. We tried to make that a bit easier with Jive EAE/Search Dependency Map, but it's still ultimately a manual process to upgrade them, and still quite error prone.  Not only that, but the project POM files are kinda huge.  We use lots of plugins and dependencies in our projects, and they are repeated, over and over again, every time you create a project.  As we changed things, such as AspectJ or Spring library dependencies, or Maven plugin configurations, there was really no way to get them to you, the developer.  You were pretty much stuck with generating a new project from the latest archetype version, and performing a diff against your existing project.


Well, those days are gone.


I'm thrilled to tell you about new changes to the Jive Maven Unified Archetype (and the Jive Maven Unified Plugin Archetype) that simplify version management, decrease the size of your project POMs, and help keep your builds up-to-date with the latest changes.  Best of all, this is already available to you.


First things first:  You'll need to upgrade your Maven installation.  Unfortunately, some of the awesome features we wanted to use were only available in Maven 3.2.1.  Go get it here.


If you follow the instructions in How To: Create a Custom Jive Project, and execute the command to create a new project..


mvn -U jive:create-project


...and follow all the prompts, on the surface, your new project will look the same.  If you look a bit closer, however, you'll see the difference.  Check out the project's root pom.xml file.


<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="" xmlns:xsi=""
    <description>Jive customization project. This is the parent pom</description>




Notice the new <parent> element.  This references the new jive-parent-pom, which enables us to do all those things we mentioned above.  If you click the link, and take a look at the POM itself (after authenticating to our Archiva server, of course), you'll see that we pushed all the dependency and plugin management up into this new parent POM.


Now, all those nasty versioning details are completely abstracted.  The versions you need for the Jive, EAE, Search service, AspectJ, Spring libraries, are all defined for you, and you won't need to change them.  But if, for some reason they do need to change, all you'll have to do is change which version of the parent POM your project is pointing to (from, for example, to, and you'll get all those changes.  This does not only apply to versions, but also to Maven plugins.  Whereas before all plugins were explicitly defined in the root, web, and plugin POMs, now they are defined in the parent POM, and merely referenced in the individual POM files.  Each plugin's configuration is hidden where possible, and each POM that needs it simply references it.  As you can imagine, this makes the POMs themselves much smaller.


Fun Fact:  We reduced the size of the root POM file from 318 lines, to 77 lines.  The web POM is still kinda hefty, due to the cargo configurations, but it, too, shrunk in size a great deal, going from 520 lines, down to 331.


At this point you might be asking yourself how a developer might know that new changes are available in a new version of the parent POM, and you'd be right to do so.  After all, the whole point of all these exercises was to simplify things and get our developers out of the business of keeping track of which versions of what to use, so what gives?  My answer to you would be this:


Your build will tell you.


Tucked away into the <plugins> section of the jive-parent-pom is a little plugin called jive-parent-pom-version-check-plugin, which contains a goal which is run every time you perform a build.  During the validate step of the project lifecycle, it will check Maven to see if another, newer, version of the jive-parent-pom is available, and will display a message if that is the case.  For instance, if my project was using version of the parent POM, I would see the following message when building my project:


[INFO] Checking for newer versions of jive-parent-pom...

[INFO] You are currently using version of jive-parent-pom.

[INFO] The latest version of jive-parent-pom is

[ERROR] ************************************************************************************************************************************************

[ERROR] You are not using the latest version of jive-parent-pom.  It is strongly recommended you update your project POMs to reflect this, as follows:

[ERROR] <parent>

[ERROR]    <groupId>com.jivesoftware.maven</groupId>

[ERROR]    <artifactId>jive-parent-pom</artifactId>

[ERROR]    <version></version>

[ERROR] </parent>

[ERROR] You can bypass this error by setting the ignoreNewVersion property to "true"

[ERROR] ************************************************************************************************************************************************


At this point, you would have the option of changing the version to the recommended version, and you're golden.  And when it comes time to upgrade, it's just a matter of changing your jive-parent-pom version to the appropriate version, and then dealing with compile errors, etc.


Transparency Time:  As I type this, I understand that it's not entirely obvious, when it is time to upgrade, which version to change to.  For now, this will be a trial and error process.  Simply change the version to the next Jive version, and add a -0.  Your build will tell you if:
  • a parent POM for that version of Jive exists
  • whether a new version for the parent POM exists for that version of Jive (like -1 or -2 ) exists


Look for another blog post soon that details some new cool ways to know what versions of the jive-parent-pom are available, right from your command line.


If you have read this, and are wondering how you can get these changes into your existing project without having to scrap everything and start over, well there's good new and bad news.


The good news is, yes, you can definitely do this!  The bad news is, you have to do it the old way, by creating a new project, and then performing a diff on your root, web, run-services, and plugin POMs.  However, you only have to do it this one last time!


For plugins that exist within the context of a project, they should still use the root project as their parent, but will still get all the parent POM goodness through inheritance.  Independent plugins, on the other hand, which do not live within a root project, should reference the jive-parent-pom directly, as its parent.


Hold On, Right There:  The new jive-parent-pom is only available for Jive and up.  If you're still using Jive 5, or an earlier version of Jive 6, you'll need to wait to get this until you upgrade.  So upgrade, already!


As always, we welcome your feedback.