lhotari commented on code in PR #22607:
URL: https://github.com/apache/pulsar/pull/22607#discussion_r1583195671
##########
pom.xml:
##########
@@ -765,18 +765,21 @@ flexible messaging model and an intuitive client
API.</description>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
+ <scope>provided</scope>
Review Comment:
> I see your reason. But as the conclusion, did you mean all downstream
projects need to import the `slf4j-api` dependency explicitly to get it around?
In the future, since there are both SLF4J 1.7.x and 2.x, any project would
have to use dependency management to select the desired version for that
project. Obviously if a project is using 2.x features, it will require 2.x
version at runtime.
I think that the correct solution is to keep `slf4j-api` in `compile` scope.
It's simply a bad solution to ignore the dependency. For `slf4j-simple` and
`jcl-over-slf4j`, the correct scope is `provided` since they are runtime only
type of dependencies. The same argumentation doesn't apply to `slf4j-api`.
> We must avoid introducing any breaking change, or at least, document the
breaking change and how should users get it around.
My assumption is that slf4j-api is binary compatible for all 1.7.x
interfaces in 2.x. . However, it will be necessary to document that Pulsar has
switched to use slf4j 2.x . All Java based projects will have to deal with this
eventually so this challenge isn't specific to Pulsar.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
