So to say, in a project that for example depends on maven-core ONLY, I would assume my transitive deps would be good.... But, in a moment I have OTHER direct dependendencies, that MAY have overlapping transitive dependencies with anything overlapping with those from maven-core, things go south...
T On Thu, Jun 15, 2023 at 8:17 AM Tamás Cservenák <ta...@cservenak.net> wrote: > 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 >> > >> >
