I must say I haven't seen any project using the approach described in the Maven doc.
Most projects I've seen use the root POM as both the aggregator POM and the parent POM, and have their BOM in a submodule. Sometimes the root POM is only the aggregator and the parent POM is a submodule as well. Actually the biggest problem with BOMs is that you want them to have a parent to share all deployment plugins configuration, but without the dependency management of the project, so other submodules would have a different parent with those same plugins, possibly other plugins, and dependency management (importing the BOM and, in your example, Guava). This can quickly lead to many POM/submodules just to split plugin configuration and dependency mangement and the BOM and the parent and… Le jeu. 15 juin 2023 à 01:05, Garret Wilson <gar...@globalmentor.com> a écrit : > Hi, everyone. I understand this list to be a general forum for Apache > Maven users, so as such I'm sharing some ideas I've had related to BOMs. > > Over the years I've changed how I define "Bill of Material" POMs for my > large, aggregated projects. Recently I've settled on a pattern which I > feel is a refinement of the official Maven approach > < > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms> > > for putting together a BOM. I've described the technique in my blog post > I published today: /Improving the Maven Bill of Materials (BOM) Pattern/ > <https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern>. > Here's a summary. > > Assuming we have a project `com.example:…` with aggregated subprojects > `com.example:foo` and `com.example:bar`, my technique uses the following > directory structure: > > |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml| > > Interestingly the top-level BOM aggregates all three POMs: the two > submodule POMs as well as `parent-pom.xml` in the project root > directory. The two submodules `foo` and `bar` use `parent-pom.xml` as > their parent. > > I see this bringing a couple of benefits over the official approach in > the documentation: > > * Aggregated modules are easy to find—in the top-level POM where they > logically should be. > * Other project dependencies and configurations are located nearby, in > the `parent-pom.xml` file in the same project root directory as the > BOM, not relegated to a separate subdirectory. > > The post goes into much more detail explaining the differences, with > example of the POM contents. > > I'd be interested in feedback on this technique if you have any > comments—especially if you find a flaw in this approach. > > Best, > > Garret >
