Totally agreed with all the points!
I would like to extend this a bit more:
* switch to CI-friendly versions via ${revision}
* group properties by domain (e.g., common, lib versions, plugin versions)
and lexicographically sort each group
On Mon, Sep 12, 2022 at 9: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),
> * 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.
> * removing exclusions from `<dependencyManagement>`: AFAIK they are
> ignored by Maven. Or we can keep the exclusions as a template for the
> projects.
> * 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...
> * sorting dependencies by scope (provided > compile > runtime >
> test), artifactId and groupId.
>
> Since POM style is as personal as code style, I would agree to all
> possible conventions as long as they are coherent.
>
> Piotr
>
