Some useful Maven configurations, practices and lessons learnt

After using Maven for a while, my colleagues and I have configured a couple useful things and learnt a few lessons.

Edit: as per comments
Local Repository Managers
On the maven site here: Repository Management there is a brief description of the major repo managers out there
and a very good breakdown on why they are a good idea. We had a couple issues with Artifactory, (this was a couple years back) and in the end went with Nexus, which has proven to be very stable and offers all we need.

Parent POMs
Define common things, like versions, compiler settings, reporting settings and common build plugins in a parent POM to allow this configuration to be used throughout the applications' components and sub projects. If you have multiple projects with different requirements you can create another layer of Parent. To give an example, we had a legacy project, and the new re-write. For the legacy system we could not enforce checkstyle or code coverage but we did want to enforce it for the new project. So we created a base parent pom that had some general configuration and version numbers in it and then another parent pom for the new system that had the base parent as it's parent and then all the specific code coverage and style checks.

Versioning(See update at end of post)
In a parent POM define variables for all out internal component versions, so that you would have 1 central place to change release versions / snapshots etc.
We didn't include the versions of common 3rd party libraries like Spring, The Apache commons projects, JUnit etc, which in hindsight was a mistake. This is now really quite a pain 3 years and 30ish POMs down the line when trying to upgrade a specific library, and invariably one gets missed and then you have 2 / 3 versions of Spring or Hibernate sneaking into the dependencies.

Parent POM:


Project POM:


Compiler Settings
Just to ensure that it is the same accross all the projects using the parent.


Common Build Settings
1. Unit Testing
Actually running and reporting on the unit tests and results.
1.a. In the report plugin I have included command line arguments to increase the VM size, we found that on our large projects with tons of unit tests it did occasionally ran out of memory.
1.b. In the build plugin, there is a "parallel" config, that i recently saw in John Smarts blog, that allows you to run the test classes concurrently.
2. Cobertura Code Coverge, This is great way to ensure that there are atleast a certian amount of test cases and that code is being run.
It unfortunately can't check the validility of the test cases so developers will be developers and code "useless" tests just to pass the coverage requirement, but it is still worth putting the plugin in, and "useless" tests can be caught with code reviews.

1. Surefire - Running and Reporting



2. Cobertura Code Coverage
We found that in our predetermined deadline environment going for more that 50% coverage really extended the development time and effort for components more than we could afford. There were a couple smaller components that off the bat had 80%+, but we couldn't enforce it on all due to the time constraints.We are now slowly increasing that percentage when ever there is new work on a component but that is also quite a slow and painful process.
The "totalLineRate" is the setting that determines the coverage % required.




Checkstyle
We defined our basic coding standards within Checkstyle, and to ensure that they are followed we would fail the build if the code doesn't comply. I have also snuck in the "taglist-maven-plugin" plugin under this topic as it was a pet peeve on one of the developers, and with it in the reporting section it will show up when using 'mvn site'.




Profiles
One of our .EARs needed to be deployed on both Glassfish and Weblogic and there were unfortunate compatibility issues between the 2 so we couldn't actually deploy the same ear.
We configured that specific POM with 2 profiles. The Weblogic on was set to be the default, and when we required a new deployment onto Glassfish we would run maven with -Dglassfish-build=true.



Edit 2: Dependency Management and Versioning
Again, thanks to the people that commented. I am always happy to learn something new. So a couple people pointed out that I completely missed this. When writing this I based it on personal and team experiences and we somehow missed this section of the maven docs. I state in "Versioning" it is now a bit of a pain in our lives, so to help out others, below is the link to how Maven says you should handle dependencies.

Dependency Management