Maven : Multimodule projects and versioning

Question

What are the best practices for software versioning and multimodules projects with Maven?

I mean, when I create a multimodules project with Maven, what is the best approach for the versioning? To use a single version for all the modules (defined in the top project)? To use a version for each module (defined in the POM of each module)? Is there another approach that I'm missing? What are the pros and cons of each approach?

In general, are the different modules released together (possibly sharing the same version number)?

Thanks

Neoterism

Hey Mickel I am getting some issue in Multimodule project can you please help me out – Hilversum

@subodh Hi, you can formulate a question and post it on StackOverflow and I'll try to help you. – Neoterism

Hi i have added a question here #13393415 – Hilversum

Answer 1

Honestly it depends on what you would like to do. Multimodule projects are created for multiple reasons, one of them being you only need to deploy what has changed instead of all modules.

Think about it this way: if you had a non-multi-module project and you only had to change one line in the services layer, you have to rebuild the entire project and deploy all of the code again...even though only your services layer will change.

With multi-module projects, you can regenerate your project and deploy only what changed...your services. This reduces risk and you're assured that only your services module changed.

You also have a multitude of benefits to using multi-module projects that I'm not listing here but there is certainly a huge benefit to NOT keeping your version numbers of your modules in sync.

When you build your project, consider deploying it to a repository that will hold all compatible jars together for builds (each build creates a new folder with the parent-most pom version number). That way, you don't need to keep documentation about which jars are compatible...they're all just deployed together with a build number.

Cyathus

Yes, but I can also define one Maven independent project for each module without using multimodules features of Maven. What are the differences? – Neoterism

A very valid question. Someone else has asked the same on StackOverflow and they have some decent answers (link at end). Remember, maven is one of many ways to get the job done (and there are many ways to do the same thing in maven...just depends on what works for you). link: #6676321 – Cyathus

@MickaelMarrache: The difference is that these modules depend on each other and if I refactor something within a dependency, I have a single commit that changes that. Same applies for releases - the built server can test every commit if all the modules work together like that (I admit, I don't have integration tests yet, but I would add it as module as well). So my code is consistent all the time. – Appreciative

Answer 2

I was looking for a solution for this exact problem myself and versions-maven-plugin was exactly what I needed. I don't like the release plugin communicating with the SCM system. The versions plugin does just what we need: it sets a new version number in all poms of the project:

mvn versions:set -DnewVersion=2.0.0

Then I can proceed with commits, tags and an official build server build...

EDIT:

The versions plugin depends on how a maven multi-module project has been organised: as a result, it often does not update all POM files in a complex multi-module project. I've found that sed and find do the job much more reliably:

sed -i 's/1.0.0-SNAPSHOT/1.0.0-RC1/g' `find . -name 'pom.xml'`

Palsy

Answer 3

Typically you create a multi-module project because you have deemed that the various modules are parts of a single whole. Maybe the client-piece, the controller-piece and the services-piece. Or maybe the UI with services.

In any case, it makes sense to have the version numbers for the various modules to move in lock-step. However Maven does not enforce that as a rule.

As to your question

are the different modules released together (possibly sharing the same version number)

I would think so. That is one of the reasons for having it a multi-module project. Otherwise you could have the modules as independent projects.

Of course this is the kind of stuff that is rife with edge cases and exceptions ;-)

Negris

What if only one module is modified? Let's take as example a 3-tier project with a GUI layer, a controller layer and a data access layer. The three layers are modules of a single project, but in some cases, only the data access layer is changed (the controller is not changed because the use of abstraction). In this case, why to release all the three modules? Also, why to give a new version to all modules, even if two modules have not been changed? – Neoterism

@MickaelMarrache Let me start off by referring you to the last line of my response "...this is the kind of stuff that is rife with edge cases and exceptions". We can have an endless debate on this topic. The thing I consider is whether I can easily re-create an development environment for any released version of my product. Why? So that I can recreate any bugs and work on a fix. – Negris

@Michael That kind of reasoning can easily go ad absurdum: you could always argue that a specific code package should be broken up further "because one part might change, but the other might not". It doesn't matter if only a single subproject was modified: all of them get their version number increased. As I see it, multimodule projects are useful so that you can build only the smallest practical unit of code containing the changes you are making, yet when it is time to release, you can use the top level projects to produce a binary which can be installed. – Palsy

Answer 4

I had the same problem with a project I`m working on. I also decided to use separate versions and even the dependency to the parent pom only has to be updated if some of the managed dependencies change. (so mostly as @vinnybad describes it)

Two additions

exists-maven-plugin

With the usage of the "org.honton.chas.exists-maven-plugin" only the modules will be deployed to the repository that have actually changed, which is really great, because also the according docker-images will only be published if something has changed on one of the service. This avoids "polluting" the image repository with different but unchanged versions.

versioning

One main downside of the "separated versions" approach are the questions regarding versioning:

• What's the current version of my project?
• Which module versions work with each other? (even thought they don't directly depend on each other, one does rely on what another does, e.g. they share the database schema)

To solve that I put all module versions into the dependency management part of the parent pom, even if no other module depends on them. A "integration-test" module could solve that by depending on all of the modules - and of course testing them together.

This way I would be "forced" to update the parent pom with every change, since it's referring the released module versions. This way the parent pom would have the "leading" version and at the dependency-management block state the versions of all modules that are compatible with each other (which will be ensured by the integration test).

Appreciative

If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review – Primateship

For me it's the same question, just an extended solution based on the answer of @Cyathus – Appreciative

@Primateship Ok, I've updated it to be an alternative answer without any question in it. – Appreciative

@Appreciative With your versioning strategy, how are you handling changes that you make to a submodule, releasing it and then using the new version? It doesn't seem like you are using SNAPSHOT builds, so are you simply incrementing the submodule version manually and also manually increment the corresponding module version in your parent pom and then running mvn release at the parent level? – Hebert

@Hebert yes, manual version bumps everywhere. For bigger releases that come trough "develop" branch, I prepare all version bumps there and merge afterwards (a clean way would be a release branch). For bugfixes and minor changes, the version bump goes directly with the fix. oh and I am not using mvn release at all. – Appreciative