Hi all,

Following the discussion in PR#2166, I would like to change the dep
management convention I mentioned in 2022.

On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
> 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.

This convention seems unnatural to many of our contributors,
especially regarding dependencies that are used by a single module.

Alternative Maven resolvers have also problems with a centralized dep
management (cf. Issue#1983 for example).

Therefore I would like to amend the proposition above to state:

 * if a dependency is used by a single module, it is only declared in
that module,
 * if a dependency is used by more than one module, it should be
managed in the parent.

What do you think?

Piotr

[1] https://github.com/apache/logging-log4j2/pull/2166
[2] https://github.com/apache/logging-log4j2/issues/1983

Reply via email to