+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 >
