Managing Maven Dependencies Across Multiple Teams

How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about.

A good example set of decisions might be:

Things we can't live without:

• be able to reconstruct any past release at any time
• be able to maintain multiple supported major versions of the product at any time

Things we would like to have:

• be able to perform ongoing major-feature development (for the next major release) without worrying about branch merges
• be able to perform maintenance updates to past releases

Things we can live without:

• automated backporting of changes from current work to past releases
• never interrupt major feature development even for a few days or a week at at time

If the above were your goals, you could then adopt a process like this:

1. Do all development work on the trunk of your VCS ("master" in git)
2. When you are close to a major release, halt major feature development, and focus on system stability for a week or so
3. When the trunk seems stable, create a branch for this major release
4. Major feature development can now proceed on the trunk, while only bug fixes and release preparation are allowed on the branch
5. However, all bug fixes to be made to the branch must first be tested on the trunk; this ensures that they will also be present in all future releases
6. Create a (VCS) tag on the branch when you are ready to release; this tag can be used to recreate the release at any time, even after further work on the same branch
7. Further maintenance releases to this major release (minor releases) can now be prepared on the branch; each will be tagged before release
8. In the mean time, major feature development geared toward the next major release can continue on the trunk
9. When you get close to that release, repeat the above steps, creating a new releases branch for that release. This allows you to have multiple major releases, each on their own branch, in supported status at the same time, with the ability to release separate minor releases against each.

This process won't answer all of your questions -- in particular, you will need a process in place to decide what fixes can be made to a release branch, and to ensure that bugs are not fixed on a release branch first (such fixes should always be tested on the trunk where possible). But it will give you a framework in which to make such decisions.

If all projects have to be (always, or almost always) released simultaneously, like service-a-1.2.3, service-b-1.2.3, service-c-1.2.3 etc, then multi-module project is what doctor ordered because it gives you these simultaneous releases out of the box, instead of having to manually repeat releases for each module every time.

Otherwise, you better think twice before going there. It could be quite cumbersome and confusing to have something like 10 identical releases of service-a only because there were 10 releases of service-b - because, well, multi-module project would force you release a every time you release b.

In one of my past projects, troubles with redundant releases of loosely coupled modules have been the main reason to split a multi-module project.

• ^{"Hey guys, why do we have 10 releases of module-a? Oh wait, 2 of these were because of changes in module-b, 3 because of module-c, 4 because of module-d. And, yeah, there was one release because of changes in module-a, right." Seeing stuff like that go away after split was quite a relief.}

On the other hand, that very experience taught me that if I ever need synchronous releases of several modules, I'll go for multi-module project without a doubt.

Just think of it - no need to memorize involved modules, no need to design complicated release scripts - you just shoot mvn -B clean release:prepare release:perform, relax for a while and get it all done for you in a perfect harmony. It just can't get better than that.