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.
> On Sep 12, 2022, at 12:11 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > Hi, > > On Tue, 6 Sept 2022 at 22:40, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: >> What do you think about adding the `log4j-api-test` and >> `log4j-core-test` modules also in `release-2.x`? This should limit the >> number of conflicts to the differences that matter. > > It would be also nice to synchronise the `pom.xml` of `release-2.x` > and `master`. Since the main `pom.xml` has about a hundred > dependencies, what do you think about normalizing them by: > > * using BOMs if available (e.g. Jackson), I’m fine with this. > * 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. > * 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. > * adding a property in the main pom.xml for *each* dependency used > (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on > how to name these properties would be nice too... I don’t understand this. A property to do what? > * sorting dependencies by scope (provided > compile > runtime > > test), artifactId and groupId. I’m fine with this. > > Since POM style is as personal as code style, I would agree to all > possible conventions as long as they are coherent. > > Piotr Ralph
