Hi, On Mon, 12 Sept 2022 at 18:05, Ralph Goers <ralph.go...@dslextreme.com> wrote: > See below. While I OK with reorganizing the parent pom.xml in release-2.x I > am not > OK with making radical changes to it since it is “stable”. I also think > trying to synchronize > the two is kind of pointless. Given that one is based on Java 8 and one is > Java 11 > and the organization of the projects is different there are going to be > significant differences.
I don't plan any radical changes, I would just like a similar structure to easily compare the dependencies of the two branches. Of course `master` can have newer dependency versions, but it can not have older dependencies than `release-2.x`. > > * removing the scope from `<dependencyManagement>`: this way there > > will be no difference between BOMs and explicit dependencies. It's > > more verbose, but we won't risk having JUnit in the compile scope. > > I don’t understand. A BOM MUST be <scope>import</scope> to be included > properly. > Why wouldn’t you specify Junit as test scope since it always is, except for > test modules > that deliver a test jar. Those can be overriden. The problem with BOMs is that they import dependencies in the default scope. If we use `junit-bom`, we need to specify the `test` scope of JUnit libraries in all children POMs, while we don't need to do it with `hamcrest-core` that does not have a BOM. What I propose is to *always* specify the scope in children POMs, even if it is inherited from <dependencyManagement>. > > * removing exclusions from `<dependencyManagement>`: AFAIK they are > > ignored by Maven. Or we can keep the exclusions as a template for the > > projects. > > Are you sure this is true? I’m not sure it isn’t. I stand corrected. Regardless of what StackOverflow says, exclusions in the <dependencyManagement> seem to work (since version 2.0 :-) ) Piotr
