>>>>> Tamás Cservenák <ta...@cservenak.net>: > Howdy, > for start https://issues.apache.org/jira/browse/MNG-8012 > Basically BOM _should not_ be used within a reactor (in other words, > in a reactor where BOM is being built, it must/should not be > referenced). > Maven "managed dependencies" should be handled the "usual way" instead.
> The idea for BOM is as follows: you manage your dependencies “as > usual”, and then generate BOM (or even multiple BOMs) as you like them > (skinny- reactor only or fat - full bill of materials of stack) for > downstream consumers. Yes, I know. (Side not: sorry about my rambling below but I started trying to explain the layout of things and ended up thinking, and re-thinking how things should be done) Here is my BOM https://github.com/steinarb/bang-bompom/blob/20d12dd29b2d3758f1c237b3c29df98ecc9125f8/bang-bom/pom.xml#L30 It contains my current versions of junit, assertj, mockito, mockrunner, pax-jdbc-*, derby, liquibase and postgresql (it may be that some of them have their own BOMs now...? I am importing the junit BOM I see... probably shouldn't have done that...? I think I am importing that one directly in projects as well...?) Hm... the import of the Junit BOM is to trigger dependabot upgrading JUnit...? Since I'm using dependabot anyway these days, maybe I should remove JUnit from here and put it directly in the individual projects? Should work fine since it is test code only and doesn't affect But for all of the runtime code I really need to put the version in a single place. (side note: I think I see where this walkthrough is leading. This BOM has to go. At least all dependencies that can be handled by their own BOM should go) I put it under this parent pom, to be able to get versions from the properties in that pom (to get a single point of change): https://github.com/steinarb/bang-bompom/blob/20d12dd29b2d3758f1c237b3c29df98ecc9125f8/pom.xml#L32 Inheriting that same top pom (but not the bom) I have this master parent, where I define config for the maven plugins I use in its <pluginManagement> https://github.com/steinarb/bang-bompom/blob/20d12dd29b2d3758f1c237b3c29df98ecc9125f8/bang-pom/pom.xml#L35 But not dependencyManagement I don't touch that. Then I have this parent POM, which is the parent for all of my projects using my own libraries. What I do is set the version in a property. I don't do anything with dependencies. Instead I set properties for versions and projects inheriting this parent uses those properties to load libraries' BOMs into their dependencyManagement. https://github.com/steinarb/bang-bompom/blob/20d12dd29b2d3758f1c237b3c29df98ecc9125f8/bang-pom/bang-app-pom/pom.xml#L28 And finally I have this parent POM which sets a property with the version of a something that is both an application and a library https://github.com/steinarb/bang-bompom/blob/20d12dd29b2d3758f1c237b3c29df98ecc9125f8/bang-pom/bang-app-pom/bang-authservice-client-pom/pom.xml#L29 (so authservice is using bang-app-pom/pom.xml but all of the others use bang-authservice-client-pom/pom.xml) Note: The no-inherit config for maven-release-plugin central-publishing-maven-plugin and the troublesome versions-maven-plugin, in these last two pom files, are to make sure that using them as a parent won't affect the release process of the program using the parent. So, summing it up: - the BOM is where it is in the hierarchy to be able to set up <dependencyManagment> for the versions set in the parent - the BOM is necessary for to get the same versions across all apps for runtime dependencies - test dependencies can move out of the BOM and be handled by projects individually using dependabot - The bang-pom.version property and the versions-maven-plugin magic was introduced back in 2021 as a way to tell projects inheriting one of the parent poms, the version they should use to load the BOM into their dependencyManagement I'm still not sure where to go, except for removing all test dependencies from the BOM...? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
