Am exactly along Thomas lines... And even tried to backport Maven 4 BOM to Maven 3.9.x, just to figure out that as it stands https://github.com/apache/maven/blob/master/maven-bom/pom.xml (modules only, so for consumer "first level deps") makes no sense to me.
T On Thu, Jun 15, 2023 at 8:12 AM Thomas Broyer <t.bro...@gmail.com> wrote: > 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 > > >
