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/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 http://www.mosabuam.com/2009/08/installing-apache-maven-luxury-edition http://www.mosabuam.com/2009/08/installing-apache-maven-luxury-edition#comments Mon, 10 Aug 2009 07:21:34 +0000 Manfred http://www.mosabuam.com/?p=1371 As you might or might not know I have been using Apache Maven for quite a few years now and I have come to do all my development projects the maven way although I am probably not a full Maven maven. I am setting up a new development machine at home after being forced to look for a new job so I might as well write down what I do, since it is probably a bit different from the normal install.

For starters I am using Ubuntu Linux and I could just install Maven from the repository like this

sudo aptitude install maven2

and be done with it. I actually do that as a first step. However this does not play nice with having the latest and greatest version of Maven and getting the benefit of the numerous new features and bug fixes from new releases. I could use the Debian Testing repository and use apt pinning to stick with the version there, but things get hairy quickly that way. I also found I don’t have enough patience to wait for the package when a new release comes out, so I get the latest release from the
Apache site and stick it into /opt/apache-maven-2.2.0, add a symlink /opt/maven sudo ln -s /home/java/software/apache-maven-2.2.0/ maven and add M2_HOME and a M2_HOME/bin to the PATH in my ~/.bashrc.

With this install I get the latest Maven release together with the command completion from the Debian package. So I can type mvn and then use tab and get a list of options and lifecycle goals as well as use tab for command completion(see /etc/bash_completion.d/maven2 for details). Pretty sweet. As a lazy programmer I go one step further and add a bunch of aliases to my ~/.bashrc for often used commands.


alias mci='mvn clean install'
alias mcc='mvn clean compile'
alias mct='mvn clean test'
alias mi='mvn install'
alias mc='mvn compile'
alias mct='mvn test'
alias mcis='mvn clean install -Dmaven.test.skip=true'
alias mis='mvn install -Dmaven.test.skip=true'
alias mej='mvn exec:java'


Depending on projects I work with I also add specific aliases using profiles that need to used and more to additional aliases.

As the last but not least important job I install Sonatype Nexus as my local repository server. The instructions for the install in the Nexus book are all you need. I install Nexus on my developer machine for the following reasons:

• it acts as my local proxy allowing me to pretty much work offline smoothly without needing to use the offline mode in most cases.
• I can clean out my ~/.m2/repository folder for debugging or other issues (IDE slowdown..) and getting things back afterwards is MUCH faster
• I can use it to install thirdparty jars more permanently (e.g. the android jar or oracle jdbc driver jar) in a clean manner without polluting my ~/.m2/repository or depending on an external private repo server
• I can test the release plugin usage against my local proxy server

So there you have it. Thats all the steps I go through to install Maven and then I bathe in luxury ;-)

]]> http://www.mosabuam.com/2009/08/installing-apache-maven-luxury-edition/feed 4