I contacted Jason van Zyl and then Bob Lee on twitter and got support from both of them. Now I created an issue on google code for the request and I am in the process of publishing the request out to the world. I will track the progress with the comments to this post and potentially further posts. I really hope that this will happen with the push from the community just like it did with spring, jboss and google projects. I hope you will all help and retweet, star the issue or leave a supporting comment there. Lets see if we can get this happening.

But first lets clear up some of the confusion around the terms. As well explained in the great book Maven: The Definitive Guide the Super POM is the Maven internal setup of all the parameters used by Maven by convention. Among other things these include paths and versions of the most common plugins.

A company POM on the other hand contains all settings and parameters that are shared across a whole company. Most of the time this means multiple projects, many developers, different scm paths and so on. In many cases it also means many more maven plugins and their versions as well as many dependencies in their different versions. Management of such a centralized POM can become difficult when version upgrades of libraries become an issue. E.g. one project might need the latest and greatest, while another one actually can not upgrade to that version due to the large refactoring overhead. This can lead to difficult situations and in my opinion highlights a problem with the company POM approach. Namely it tries to do too many things.

Hence it seems quite reasonable to extract all the Maven specific things from the company POM and we have a Company Super POM. We can then slot the the new POM into the inheritance tree between the the super POM of the Maven install and a newer lighter and more focused company POM and its children in the form of project parent POMs. This will then act as the central place for settings related to Maven across the whole company.

Reason this makes sense are:

• most of the time there are only a few people (or one champion) responsible for all things Maven that bother tracking new versions and issues with existing versions of Maven and the host of plugins
• it makes sense to standardize on one version of Maven across the company, even if the projects using it vary widely and have large differences with regards to libraries used and more, they could even work on different platforms thanks to the variety of Maven plugins. E.g. there are plugins for all things Java also for Flex or Android

Confused. No problem. Lets look at it all in more detail and create our mosabuam company super pom and then use it. First lets create the Company Super POM. Since it is a normal top level POM the header will just look like this:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.mosabuam.maven</groupId>
    <artifactId>super-pom</artifactId>
    <packaging>pom</packaging>
    <version>0.1</version>
    <name>Mosabuam Maven Super POM</name>

Notice how the packaging is just pom. Next we are going to manage our plugin versions. This is done with pluginManagement like this

...
    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.agilejava.docbkx</groupId>
                    <artifactId>docbkx-maven-plugin</artifactId>
                    <version>2.0.9</version>
                </plugin>
                <plugin>
                    <groupId>com.jayway.maven.plugins.android.generation2</groupId>
                    <artifactId>maven-android-plugin</artifactId>
                    <version>2.2.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-assembly-plugin</artifactId>
                    <version>2.2-beta-4</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-changelog-plugin</artifactId>
                    <version>2.1</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-checkstyle-plugin</artifactId>
                    <version>2.3</version>
                </plugin>
...

Depending on the plugins used in your various builds this list can get quite long. Ideally you would have all plugin versions locked down and defined in here. Luckily with Maven 3 (which you would have to build yourself at the moment or get from the build grid) you will actually get a warning if some plugin version is undefined.


[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.jayway.maven.plugins.android.generation2:maven-android-plugin:maven-plugin:2.2.1-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' is missing for org.apache.maven.plugins:maven-scm-plugin @ com.jayway.maven.plugins.android.generation2:maven-android-plugin:2.2.1-SNAPSHOT, /media/sdc1/java/dev/maven-android-plugin/pom.xml
[WARNING] 'reporting.plugins.plugin.version' is missing for org.apache.maven.plugins:maven-plugin-plugin @ com.jayway.maven.plugins.android.generation2:maven-android-plugin:2.2.1-SNAPSHOT, /media/sdc1/java/dev/maven-android-plugin/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

The reason you want all version locked down is that it will allow you to consciously upgrade and ensure things don’t regress in your builds causing havoc for the development team (especially those not so deeply into Maven..).

Some plugins like in my case the gmaven plugin actually require other dependencies declared and ideally you want to keep all the versions of the plugin and the dependencies in sync. You can use properties and the dependencyManagement section for that:

...
    <properties>
        <gmaven.version>1.0</gmaven.version>
        <maven.version>2.2.1</maven.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.codehaus.groovy.maven</groupId>
                <artifactId>gmaven-mojo</artifactId>
                <version>${gmaven.version}</version>
            </dependency>
            <dependency>
                <groupId>org.codehaus.groovy.maven.runtime</groupId>
                <artifactId>gmaven-runtime-1.6</artifactId>
                <version>${gmaven.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

You might have noticed there there is also a maven.version property. This is used to enforce that everybody uses the correct version of Maven with the enforcer plugin:

        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <executions>
                    <execution>
                        <id>enforce-maven</id>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <requireMavenVersion>
                                    <version>[${maven.version},)</version>
                                    <message>Check for Maven version &gt;=${maven.version} failed. Update your Maven install.</message>
                                </requireMavenVersion>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <!--
                the versions plugin can be used to check for new plugin versions like this:
                mvn versions:display-plugin-updates
             -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>versions-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

The versions plugin as configured above allows you to easily check for new versions with
mvn versions:display-plugin-updates. With all that slapped together you are pretty much ready to go. Just put the pom file in a folder for the project e.g

mosabuam-super-pom/pom.xml

and run

mvn clean install

in the folder. This will put the pom into your local .m2 repository and it will be ready to be used from any project. To do that you simply declare it as the parent of your project like this

    <parent>
        <groupId>com.mosabuam.maven</groupId>
        <artifactId>super-pom</artifactId>
        <version>0.1</version>
    </parent>
    <groupId>com.mosabuam.example</groupId>
    <artifactId>example</artifactId>
    <version>1.1</version>

Then you can remove all the versions from any plugin usage in your project so that e.g. an invocation of the maven-android-plugin could look like this

<build>
        <plugins>
            <plugin>
                <groupId>com.jayway.maven.plugins.android.generation2</groupId>
                <artifactId>maven-android-plugin</artifactId>
                <configuration>
                    <sdk>
                        <path>${env.ANDROID_HOME}</path>
                        <platform>1.5</platform>
                    </sdk>
                    <deleteConflictingFiles>true</deleteConflictingFiles>
                </configuration>
                <extensions>true</extensions>
            </plugin>

Now all you have to do for a version upgrade of a plugin across all your projects is to update the version in the company super pom and update its version to e.g. 0.2

    <groupId>com.mosabuam.maven</groupId>
    <artifactId>super-pom</artifactId>
    <packaging>pom</packaging>
    <version>0.2</version>
    <name>Mosabuam Maven Super POM</name>

and reference the new version number in the project POM. In a development team you would add a bit of configuration for your internal Nexus server and the version control system used along those lines:

    <scm>
        <connection>scm:svn:http://mosabuamsvn/repo/super-pom/trunk</connection>
        <developerConnection>scm:svn:http://mosabuamsvn/repo/super-pom/trunk</developerConnection>
    </scm>
    <distributionManagement>
        <repository>
            <id>nexus</id>
            <name>Mosabuam Nexus</name>
            <url>http://nexusserver:8080/nexus/content/repositories/releases</url>
        </repository>
    </distributionManagement>

With the passwords in your settings.xml you can then use the release plugin to cut a new release version easily as well as deploy it to Nexus, so it is available to all your project teams.

mvn clean install
mvn release:prepare
mvn release:perform


With this approach you have all your maven related plugin versions fixed and you still have the freedom to have separate company POMs or project parent POMs that use different version of the same libraries and a whole slew of other settings. Let me know what you think.

]]> http://www.mosabuam.com/2009/10/company-super-pom-a-maven-practice/feed 6 http://www.mosabuam.com/2009/09/manfreds-world-on-twitter-this-week-2009-09-13 http://www.mosabuam.com/2009/09/manfreds-world-on-twitter-this-week-2009-09-13#comments Sun, 13 Sep 2009 04:30:00 +0000 Manfred http://www.mosabuam.com/2009/09/manfreds-world-on-twitter-this-week-2009-09-13 Some craziness around our domain name and other fun while summer comes to an end.
• Backordering domain names.. #
• Jeff at Solidinternet.com support just saved my life. Thanks. #
• If you want to find out how dependent you are on your domain name just imagine nearly loosing it. I got a few more grey hair now. #
• Rejoicing that the problem with #wordpress tags and categories are gone. The problem were access right issues to /tmp. #
• Documented problems with #wordpress in new post http://bit.ly/184Lcn #
• Really liking the tooling for coding #android with @intellijidea so far. Now I just got to code away on my first app ;-) #
• Really not liking how blogtalkradio pretty much is a pain to subscribe and requires the html player rather than allowing easy donwload. #
• Not finding @twidroid Pro in the #android market here in Canada. #
• The #android market application should get features like bulk update from synaptic on #ubuntu. And a working search… #
• @sheaphillips don't despair ;-) in reply to sheaphillips #
• Anybody know if canonical will/does offer a hosted version of #launchpad for commercial use like #atlassian does jira studio.. #
• #scala and Model Driven Prototyping at the upcoming September is gonna be rocking. thx @kerrywright @abstratt http://bit.ly/1apVek #
• Looking forward to a shipment of my childhood lego from back home. 28kg ;-) Trains, cars, .. Lots and lots of fun with the boys coming up. #
• @abstratt thx.. intermittent problem at my hoster .. thats what you get for shared hosting.. time to move to a VPS? in reply to abstratt #
• Neil Gaimans @neilhimself downstairs library rocks. I wonder if he read it all. http://bit.ly/3V9Z5s #
• Just joined a twibe. Visit http://twibes.com/Sustainability to join #
• Just joined a twibe. Visit http://twibes.com/maven to join #
• @derJMR probier einfach beide.. in reply to derJMR #
• @derJMR ja sowohl #ubuntu als auch #opensuse gibt es ja als live cd .. reinschieben und los gehts. Persoenlich bin ich ein ubuntu convert in reply to derJMR #
• @derJMR und im gegensatz zum Mac kannst du ja gratis probiern ;-) in reply to derJMR #
• @lunafiko you will like magic and #android … in reply to lunafiko #
• Looking forward to more details about @abstratt s project around model driven prototyping after a private sneak peak. Very promising. #
]]> http://www.mosabuam.com/2009/09/manfreds-world-on-twitter-this-week-2009-09-13/feed 0 http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-23 http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-23#comments Sun, 23 Aug 2009 06:30:00 +0000 Manfred http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-23
• @tobrien Agreed. The Debian testing package is a bit more up to date. What I do though is http://tinyurl.com/lqp32g #maven #ubuntu #nexus in reply to tobrien #
• Downloaded Google Listen http://listen.googlelabs.com/index.html .. now off to go canoeing #
• Wow. John Willis from itmanagement is going to work on ubuntu one cloud. Look forward to the results. #
• @kellyrob99 Promise to look at joda-time tomorrow.. http://joda-time.sourceforge.net/ #
• Enjoying the Victoria dragon boat races… #
]]> http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-23/feed 0 http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-16 http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-16#comments Sun, 16 Aug 2009 06:30:00 +0000 Manfred http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-16
• Listening to @omegataupodcast about bird migration with professor hans winkler. Went for a bird watching session with him as a kid long ago. #
• @dillyh .. I guess then it is not a power point presentation but just a presentation… #
• Laughing at a quote from @seradio 142 "We build software architectures like cathedrals. First we build it, then we pray." #
• Hurting after leaving a bunch of skin on my sk8 deck. Better get back to podcast listening and renovating. #
• Watching lots of maven related artifact updates getting into debian testing. Awesome work! #
• @jonobacon .. yeah.. they are all pretty damn good looking, also bigger displays and more. Shipping outside the states however.. #
• Even though I don't like to admit it MS Live Meeting works okay on Ubuntu Linux. Maybe because it is Java powered.. hahaha ;-) #
• @motodev thanks for the linux version of the tools. Downloading now ;-) in reply to motodev #
• Bored out of my mind by Right Management career transition workshop. Coding in parallel. #
• @Brian_Fox This service is unavailable on your device on all browser for me on Ubuntu. #fail xenocode in reply to Brian_Fox #
• Facebook chat has connection problems .. #fail #
• @abstratt look at the build helper plugin… in reply to abstratt #
• Listening to agile executive podcast 5. Pretty good so far. Also found theheretech podcast. As usual there is lots to learn… #
• No google voice for me in Canada. What a shame. Oh well.. downloading Maven 2.2.1 instead.. #
• Off to shower after a day of home renovation and podcast listening (illegalargurment, linuxoutlaws, itmanagement, riaweekly, …) #
• Just got my google voice invite. Sweet. #
• VMWare buying Springsource and therefore getting Groovy. So will the installer for Groovy start to suck and Grails only work with Windows? #
• Got my blog post "Installing Apache Maven – Luxury Edition" out there ;-) http://tinyurl.com/lqp32g #
• Installing #nexus on my dev machine for local proxying and more. Could not use #maven without it. #
• Brushing up my resume. Should be ready to be spread around shortly. #
]]> http://www.mosabuam.com/2009/08/manfreds-world-on-twitter-this-week-2009-08-16/feed 0