Block shardingsphere-logging-core from passing logback-classic dependencies to downstream modules

[linghengqian]

Fixes #32377 .

Changes proposed in this pull request:

• Block shardingsphere-logging-core from passing logback-classic dependencies to downstream modules. Once merged, logging behavior for most modules will look the same as if the following dependencies were added. Unless the downstream module declares a declaration for some Slf4j implementation, such as Log4j1, Log4j2, Reload4j, Logback and the defunct Jakarta Commons Logging, which has been defunct for ten years. Of course Apache Commons Logging https://github.com/apache/commons-logging was recently resurrected.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-nop</artifactId>
    <version>1.7.36</version>
</dependency>

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[linghengqian]

@RaigorJiang What do you think about removing the test dependency of logback globally? Or keeping it?

[RaigorJiang]

@linghengqian I'm in favor of removing it from the global, and temporarily disabling the logging rule, since it now binds to logback, and users don't know how to configure the rule.

#23856 provides a good idea, but before we implement the logging rule well, it is better not to let it affect users.

[linghengqian]

So far, the current PR seems to be ready for the next review. In the current PR, Shardingsphere Proxy uses Logback with runtime scope, while ShardingSphere JDBC only provides Logback with provided scope.

[RaigorJiang]

I see from the dependency analyzer that the shardingsphere-standalone-mode-repository-jdbc module's dependency on logback-classic is already in test scope. Can you please help check it?

[linghengqian]

• After I removed the declaration of ch.qos.logback:logback-classic here, I didn't see any logback dependencies. Without explicit declaration, the mode/type/standalone/repository/provider/jdbc/src/test/resources/logback-test.xml of this module will be useless. Where does this picture come from?
• 

[RaigorJiang]

My screenshot is from here

[linghengqian]

It looks like you are looking at the dependencies of the master branch. On the master branch, logback in test scope is pulled into all modules, as I pointed out in #32389 (comment).

[RaigorJiang]

Similar to the situation in shardingsphere-standalone-mode-repository-jdbc, it is already in test scope.

[linghengqian]

• See Block shardingsphere-logging-core from passing logback-classic dependencies to downstream modules #32389 (comment) . After I removed the declaration of ch.qos.logback:logback-classic here, I didn't see any logback dependencies. Without explicit declaration, the parser/sql/dialect/doris/src/test/resources/logback-test.xml of this module will be useless. Where does this picture come from?
• 

[RaigorJiang]

[linghengqian]

It looks like you are looking at the dependencies of the master branch. On the master branch, logback in test scope is pulled into all modules, as I pointed out in #32389 (comment) .

[RaigorJiang]

@linghengqian Yes, I found the difference, in this PR you removed logback from the root pom and added it to specific modules, just to make logback not appear in the test scope downstream?

[RaigorJiang]

Yes. Because if we do not exclude the test scope logback globally, after a module introduces Hiveserver2 JDBC Driver, multiple slf4j adapters including Reload4j, Log4j2, Logback, Jakarta Commons Logging, etc. will still appear in the classpath of the unit test at the same time, which violates https://www.slf4j.org/codes.html#multiple_bindings . I think a better solution is to explicitly declare Logback in the module that needs to use Logback. What do you think?

If we use <exclusion> to exclude incompatible dependencies when introducing new dependency, such as log4j introduced by hive, to ensure the simplicity of ShardingSphere itself, is this possible?

[linghengqian]

• This is actually what I asked you at Block shardingsphere-logging-core from passing logback-classic dependencies to downstream modules #32389 (comment) . We have 2 options, one is to keep the test scope Logback globally, the other is to remove the test scope Logback globally. We can of course limit unit tests to use only Logback. If you think the test scope Log should be kept globally, another commit will be pushed.

        <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-jdbc</artifactId>
            <version>4.0.0</version>
        </dependency>
        <!-- See https://issues.apache.org/jira/browse/HIVE-28308 -->
        <dependency>
            <groupId>org.apache.hive</groupId>
            <artifactId>hive-service</artifactId>
            <version>4.0.0</version>
            <exclusions>
                <!-- See https://issues.apache.org/jira/browse/HIVE-28429 -->
                <exclusion>
                    <groupId>org.apache.hadoop</groupId>
                    <artifactId>hadoop-client-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.logging.log4j</groupId>
                    <artifactId>log4j-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.logging.log4j</groupId>
                    <artifactId>log4j-slf4j-impl</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.apache.hadoop</groupId>
            <artifactId>hadoop-client-api</artifactId>
            <version>3.3.6</version>
        </dependency>

[RaigorJiang]

• This is actually what I asked you at Block shardingsphere-logging-core from passing logback-classic dependencies to downstream modules #32389 (comment) . We have 2 options, one is to keep the test scope Logback globally, the other is to remove the test scope Logback globally. We can of course limit unit tests to use only Logback. If you think the test scope Log should be kept globally, another commit will be pushed.

Sorry, I misunderstood your intention. I thought we were going to remove the logback dependency introduced by the logging rule.

For scenarios like hive, the <exclusion> method is more acceptable, and ShardingSphere developers can still focus on logback.

[linghengqian]

• Done.

[RaigorJiang]

@linghengqian Thank you!