Refactor to represent a nearer real case.
angelcervera opened this issue · comments
The advantage of using Maven multi-module layouts is to share commons in the parent pom.
This example is using spring-boot-starter-parent as parent pom in the modules and it is not using the parent pom owned by the project, so I think that it is not a good example.
On the other hand, usually, in a multi-module project, Spring and no Spring modules are mixed. In the case of modules that are not related to Spring we don't want any dependency with it.
So I think that it is necessary to refactor this example to:
- Refactor parent pom to add common stuff like properties, version, dependency manager for no Spring dependencies, surefire and failsafe configuration, etc.
- Refactor Spring modules to use the parent pom in the project and use Spring BOM instead of the
spring-boot-starter-parent. - Add a no-Spring module with no Spring dependencies.
Thoughts??
I guess I could get behind a parent Pom at the top level with spring boot starter parent as its parent to avoid having to list all the plugins. I’m not really keen on changing the content apart from that.
My concern is that is difficult to find BOM examples working in multimodule projects.
Using spring-boot-starter-parent in the parent pom is forcing you to take all Spring dependencies version and other configuration stuff into no-Spring libraries.
If the no-Spring module is an internal library used only for Spring modules, it is not a big issue (but not a good approach in my opinion). But when the library is used by external projects that are not using Spring at all, this approach is not acceptable I think.
In this case, using BOM in Spring modules is the only option.
I think that a lot of people are using the spring-boot-starter-parent in the parent pom too much because find an example of bom is difficult (I mean, mixing Spring modules importing BOM and non Spring modules).
There is no “no Spring” module in this project though (and I don’t see the need for it). Even if there was I’d want the parent Pom to manage all dependencies (including spring) so it would make sense to use the starter parent.
I take the point about using a custom parent with a bom. It is likely to be where many projects end up. But this is a “getting started” guide, and I would want to be using the starter parent to get started (and for as long as possible afterwards), just for convenience.
Yes, I know that currently there is no "no Spring" module. What I mean is that the project would be a more realistic case with a "no Spring" module.
Anyway, It was a suggestion and if the idea is to have a simple "hello world" then is fine. No really useful in my opinion, but fine for another "hello world".
Anyway, thanks for your time.
I arrived at this thread after struggling with the same problem. Did not really know how to resolve the conflict between wanting to share common stuff (esp. library versions) in parent module and not wanting to use spring-boot-starter-parent in the parent module to avoid forcing spring dependencies onto my library modules.
Can't help shake the feeling that this was rather a "Getting started in the wrong direction" guide. Any project large enough to use modules will very soon reach a stage where it will need to address this issue.
Really appreciate @angelcervera for raising the question and his suggestion to use bom.