Hi,

I've tried to list tradeoffs/pros & cons below rather than giving definitely answers because like everything else in the process side of software development it depends upon your specific circumstances.

I know all the cool kids are doing gradle these days, but for a number of reasons we have adopted maven in my team. At the beginning it was all cool, we could trust it to download dependencies instead of having to keep the third party jar files ourselves and all that, but we're getting to the difficult points now. Google has been somewhat helpful, but I'm finding too much information in a non-structured way (maybe I'm looking at the wrong places), so it's not really solving the core issue.

I am guessing some other people out here may have faced a few challenges with maven and I was wondering what resources you have used: books, presentations, anything. The level of "pain" I am getting to is:

• If your project consists of multiple jar files that produce a few war files, do you create a multi-module project or do you treat each project independently, publish the artefact to your corporate artifactory, and then consume the jar files from there?

In past projects I've used multi-module builds.

The main reason being that it's an easy way to get a single-step build for a whole project. The single step build really helps when implementing Continuous Integration/Delivery/Deployment. Otherwise you need to do things like configure your CI server to maintain the same set of dependency relationships which isn't a huge burden when you start and have like 3 projects but if you ever get to a heavily modularised build then maintaining the equivalent relationship in multiple places can be a burden.

The big downside of multi-module builds is that you're tied to releasing things in a big single-step release phase. If you have non-deterministic tests this can be risky and slow down deployments. Obviously you should fix those, but its the real world so maybe you haven't. If you really want to deploy the different components in your projects at different times (for example if you want to go down the micro-services route) then I would avoid a big multi-module build.

• When do you change from -SNAPSHOT to normal version and how? Particularly if you produce multiple jar files that are independent "projects" (ie pom files without a common parent).

• And how do you change back from normal version to -SNAPSHOT and when?

How

Versions without "-SNAPSHOT" are released versions. The release plugin has its own documentation [0]. Here's an example:

1. Start in version 0.0.1-SNAPSHOT

2. The version is changed to 0.0.1 and that is the version that is released (eg: uploaded to artifactory/nexus).

3. At the end of performing the release the version becomes 0.0.2-SNAPSHOT and you're ready for your next iteration of development.

When

Well it all really depends upon what your product release cycle and business needs are.

If you do releases periodically, for example at the end of each week. Here it makes sense to bump the version upon release so everything is in step. Another example of bumping the releases in step with releases is if you release software that gets deployed onto other people's machines and has an install step. For example: desktop software, services that run on client's servers or libraries. In these cases its worth doing a proper maven release everytime.

Of course its 2014 and the hot topic these days is continuous delivery and continuous deployment. The extreme approach to implementing these practices is to deploy every commit and keep the HEAD of your repository deployed. In these situations versions and releases in the traditional approach don't make much sense. I would recommend against ever doing a release if you're trying to maintain a HEAD deployment model and I know of a couple of companies who have successfully implemented this strategy. I would of course ensure that each version of your release is versioned but here using a commit identifier from your VCS seems more appropriate, for example the hash in git or the number in SVN.

• How and when do you run your component tests (ie testing a war file or similar as a black-box entity) and your full integration tests (testing all components together).

If you want to test a bunch of components together you can have a module or project which contains your system tests. This is particularly useful if you want to test the final bundle or deployment that gets shipped to customers which won't be available at earlier stages of the build. This can be done in either the multi-module or independent project approaches mentioned earlier. In both cases the module/project is just one which only contains tests and depends upon the build artifact of earlier modules/projects. Just make it the last module in your reactor build if you're going multi-module and you've still got a single step build.

Note: I'm not necessarily after answers to these four points (although that would help too). I'm after good resources where I can find the answers myself.

I have to say that it sounds like you're after "best practices" for maven. The official documentation really seems to be lacking in this regard. Nearly all the information that I've picked up in this regard has been from talking to people.

Phew! That email got a lot longer than I originally anticipated.

regards,

  Richard Warburton

  http://insightfullogic.com

  @RichardWarburto

[0] http://maven.apache.org/maven-release/maven-release-plugin/