+1

On Mon, Jan 8, 2024 at 11:11 AM Piotr P. Karwasz <piotr.karw...@gmail.com>
wrote:

> 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