52

I have some years of experience with maven projects, even with multi modules ones (which has made me hate the multi modules feature of maven (so the disclaimer is now done)) and even if I really like maven there is something I cannot get a clear answer about :

What is a typical usecase of a multi module maven project ? What is the added value of such a structure compared to simple dependencies and parent pom ?

I have seen a lot of configuration of multi module projects but all of them could have clearly been addressed by creating a simple structure of dependency library living their own life as deliverables (even with a parent pom, as a separate deliverable : factorising depedencies and configuration) and I haven't found any usecase where I can clearly see an added value of the multi module structure.

I have always found that this kind of structure brings an overkilling complexity with no real benefit : where am I missing something ? (to be truly honest, I can get that some ear can benefit from this kind of structure but except from that particular usecase, any other real use and benefit ?)

Jonas
  • 121,568
  • 97
  • 310
  • 388
benzonico
  • 10,635
  • 5
  • 42
  • 50

5 Answers5

36

Here's a real life case.

I have a multi-module project (and to your rant... I haven't seen any complications with it.) The end result is a webapp but I have different modules for api, impl, and webapp.

12 months after creating the project I find that I have to integrate with Amazon S3 using a stand-alone process run from a jar. I add a new module which depends on api/impl and write my code for the integration in the new module. I use the assembly plugin (or something like it) to create a runnable jar and now I have a war I can deploy in tomcat and a process I can deploy on another server. I have no web classes in my S3 integration process and I have no Amazon dependencies in my webapp but I can share all the stuff in api and impl.

3 months after that we decide to create a REST webapp. We want to do it as a separate app instead of just new URL mappings in the existing webapp. Simple. One more module, another webapp created as the result of the maven build with no special tinkering. Business logic is shared easily between webapp and rest-webapp and I can deploy them as needed.

digitaljoel
  • 26,265
  • 15
  • 89
  • 115
  • 1
    This sounds to me the best usecase describe so far and moreover your comment on the other answer confirms what I kind of think/feel : multi module provides value for Multipackaging or huge project. – benzonico Mar 23 '13 at 16:42
  • I'm by no means a fanboi of maven but there are some cases where it has "just worked" and this seems to be one of its strengths to me. Glad the answer helped. – digitaljoel Mar 23 '13 at 17:06
  • 1
    I am actually plotting to use this answer to demonstrate in which cases the multi module should *not* be used. – benzonico Mar 23 '13 at 20:04
  • 4
    I know this is old, but I was wondering what the benefit of including the api / impl with the webapp was? I guess this just furthers the original question for me - I see that maybe the impl should be modularized with the API, but why things like the webapp and the other consumers of the API? – bvulaj Mar 04 '14 at 18:05
  • 1
    @BrandonV So you are thinking that rather than having the webapp be a module within the overall build it would be a project of its own with a dependency on the project that contains the api/impl modules? I can see that as a totally valid approach. In my case I didn't see or experience any pain with it being a single project with multiple modules. Since it was all so closely related I didn't want to take the time to separate it all out into a separate project and found it easier to just make modules within my own project. – digitaljoel Mar 04 '14 at 22:07
  • 1
    To continue my comment above, I guess for me it would depend on if I need to release the artifacts separately, or if it makes sense to release them together. In my case together since I would always be deploying them all together. In your case, it may make more sense to deploy api/impl together, and deploy webapp/api-webapp, and integration-library at separate times/locations. – digitaljoel Mar 04 '14 at 22:09
  • @digitaljoel Thanks for the response! That answers my questions. – bvulaj Mar 05 '14 at 14:04
  • @digitaljoel Did you have all your Maven modules/submodules in one version control repository or tracked each submodule under its own repo? – Alex Yursha Mar 23 '16 at 21:18
  • All the above sounds to me that its still easier to not use 'multi-module' Maven feature at all if you want to have even looser coupling between modules. – Alex Yursha Mar 23 '16 at 21:25
  • All of our modules were in one version control repository as children of the parent project. One possible advantage of multi-module instead of multi-project is that in your parent pom you can put the dependency-management section and lock versions of your dependencies across all modules. Yes, you could do that with a parent pom that is not in the project, but that's one more separate artifact to maintain. In our case, the modules were dependent on others and not really useful outside of this small vertical. There are certainly best cases for each route. – digitaljoel Mar 24 '16 at 15:22
  • 1
    In my day job we use both multi-module, and separate project style builds. Anything that is tightly related (like a webservice model, webapp, and client) would be modules within a single project, but an app that uses the client for the webservice would be its own project. – digitaljoel Mar 24 '16 at 15:23
  • sounds as suitable only for monolith architecture – Mikhail Jan 04 '22 at 09:12
18

The major benefit of multi modules are

  • one single maven command to build all your modules at once.
  • and the most important : maven take care of the build order for you.
  • configuring your CI-server is also very easy: one single jenkins job to build everything.

I already worked in a project with about 30 submodules. Sometimes, you need to change something in more than module, and running one single command and being sure that everything that need to be compiled is compiled in the correct order is a must.

EDIT

Why 30 submodules ?

Huge framework with lot's a features, lot's of developers, separation of features on a module base. It's a real life use case and the separation of the code into module was really meaningful.

ben75
  • 29,217
  • 10
  • 88
  • 134
  • The build order seems a valid argument to me but can you maybe describe why you would need 30 (!) submodules ? – benzonico Mar 21 '13 at 22:15
  • 1
    I have worked in a situation where we had 12-15 teams working on a single project. We had a main project that had around 30 modules. It allowed each team to have ownership of their area (2-4 modules) and provided clear separation of responsibilities among teams. It wasn't perfect, but it wasn't as bad as having 50 developers all mucking around in the same packages all the time (which I've also experienced at another time) – digitaljoel Mar 21 '13 at 22:45
  • 1
    Still not clear, why each team was not working on its own jars, that could then be joined in one-module project with jars as dependencies? – Andreas Gelever Aug 04 '18 at 08:45
4

I think you are correct in that most project that use multi modules, actually don't need them.

At where I work we use multimodule projects (and I think that for a good reason). We have something similar to a service oriented architecture, so each application

  • A client module
  • An interface module (which has shared objects between the client and implementation)
  • an implementation module
  • a war module

I agree that putting that implementation and war module in the same actual module would be ok, but the (arguably) benefit of this is that is very clear division between the classes that solve the problem and how the application communicates with the external world.

In previous projects that involved just a web application, I've tried to put everything in the same module, as it made testing easier, given the modules I was using.

Augusto
  • 28,839
  • 5
  • 58
  • 88
1

I find maven modules extremely useful for the following reasons:

  • Architecture layering and boundaries

For example, I make a maven module application-contract which contains the interfaces my presentation layer sees. So I have UI->Presenter-> application-contract <-application-impl <- infrastructure -> domain. This way, I know that my presentation/UI layer will not have access to classes from my Domain/application layers. If domain classes are not in classpath when I code in UI, I cant use them. And I like it this way (utilizing the class path restrictions). Perhaps Java 9 modules can solve this problem too, but (unfortunately) I have work with Java 8.

  • Running tests in one module each time

When I change code to a layer which is a module (as mentioned previously) I can run its tests only, without re-runing tests from code I did not change. This gives me speed. My presentation layer tests need ~3 seconds (for 300 tests). Every time I change code to a Presenter or whatever below application layer, I don't want my database H2 integration tests to run. Or My Image processing tests to run. Because these do IO and they are slow.

  • Building

Pretty much the same thing. When I change code to UI, i have only to build and deploy UI stuff (my UI is in Java).

George Z.
  • 6,643
  • 4
  • 27
  • 47
0

Multi modules can help you with re-use your code. It's one of the best benefits you'll feel in work.

Imagine if you have 3 web projects with a security layer, You'll have to copy paste your code 3 times and trying connect it with each project.

But what if you create a security module a project with a specific job. It'll be easy to use it by injecting it to your app and then boom it works.

Also as mentioned in @ben75's answer the one maven build command and the correct order of building all your used jars. You'll think no more about which depends on another.

Waleed Emad
  • 109
  • 1
  • 8
  • This is an old discussion. However I have some queries along these lines. I have an old project spring-boot and it is multimodular maven project. As time passed, number of modules grew significantly. All submodules are crons. Now with time it will grow even more and already we have around 90 modules and it gets difficult to manage, sometimes intellij does not all load all or in one git repo we removed one module, after changing repo sometimes they mess up the code base. What approach do I take in this case ? Let's say my number of crons will grow more. – Tuhin Subhra Mandal Jan 13 '21 at 07:28
  • 1
    Why is having the security in a module better than just having it as a separate lib than can be used not only by this project but by other apps in your company. It also solves the copy paste problem which you have mentioned. – denu Oct 07 '22 at 14:46
  • AS denu mentioned -> External library would be quite sufficient in this case to use and much easier to modify! – Hubert Bratek Jun 20 '23 at 20:07