How to alleviate conflicts with kiwi-bom and updates to SLF4J and Logback?

[sleberknight]

We currently define slf4j-api as a required compile-scope dependency and define logback-classic as a test-scoped dependency in this parent POM. This can cause dependency convergence errors from the Maven Enforcers plugin when there are SLF4J API or logbook updates between this POM and our kiwi-bom.

Would it be better in terms of dependency convergence to move both slf4j-api and logback-classic to the BOM (as part of dependencyManagement), instead of it remaining inside this parent POM? Since the BOM inherits from the parent POM, we can't have have it both ways and need to choose one place or the other.

The obvious downside is that our libraries then all need to declare both of these dependencies in their own POMs. But one upside is that the versions are locked to what's in our BOM and thus we avoid the convergence errors. It would also let us release the BOM more frequently without needing to necessarily release a new parent POM version, which is another tick in the plus column.

We would want to investigate what the latest version of SLF4J does if you don't have any implementations on the class/module path. I think it defaults to a "no-op" logger meaning you get no logging whatsoever. This would mainly impact tests and not our services, since Dropwizard brings in Logback anyway.

I suppose one other option is to have the kiwi-parent POM, the kiwi-bom BOM, and then have a "kiwi-dependencies" POM, sort of like how Dropwizard has dropwizard-dependencies. Inside the kiwi-dependencies POM, it can inherit from kiwi-parent, import kiwi-bom, and declare the SLF4J API and Logback dependencies. But is it worth having an entire new project to literally contain two dependencies, and only one that is compile-scope since Logback is test-scoped? (Of course, another question is whether Logback should be compile-scope instead of test-scope.)

Any thoughts on this?

[chrisrohr]

👍 on this... I think we should just bite the bullet and move slf4j-api to the bom and update our libraries to bring it in.

While the dropwizard approach might be nicer, it's a lot of work and we don't do a monorepo.

[sleberknight]

@chrisrohr Ok, sounds good. Should we do this before or after the mongo driver & Spring Data Mongo updates?

[chrisrohr]

Do it as part of 2.0

…

On Fri, Apr 15, 2022 at 1:08 PM Scott Leberknight ***@***.***> wrote: @chrisrohr <https://github.com/chrisrohr> Ok, sounds good. Should we do this before or after the mongo driver & Spring Data Mongo updates? — Reply to this email directly, view it on GitHub <#130 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMVUFJEWKIB5BX55XEOXLVFGO7TANCNFSM5TPLBV4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sleberknight]

This discussion is effectively closed because we have made these changes.