The Situation

I'm currently working in project that develops several RESTful services that partly interact with each other. As an example:

  • Service A uses Service B
  • Service C uses nothing
  • Service D uses Service C
  • most of the Services use a common Utillities project.

There is NO actual code sharing between the services, they strictly rely on the defined RESTful API. Util contains helpers for test, helpers for the security lib, ....

Currently every project is stand alone in their own git repository. During development there were some moments when this was slightly anoying:

  • multiple places to do dependency management (services share dependencies to third-party libs)
  • every project has to be (maven) released seperately (personaly i like that)
  • when working "between" projects (working on a service and working on util because of that) lead to 2 review requests, because of 2 project (pull-requests)

The Question

One in the Team proposed as a solution to above problems to merge all git repositories and projects into one git repository and one maven multi module projects.

Beside my own misgivings about the idea (no code sharing, only util as a common dependency, reliance on APIs between some (not all) services,...) i would like to know:

Are there known Advantages/Disadvantages of this Plan?

I don't like it makes a bad argument.

1 Answer 1


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.