Could org.apache.shardingsphere:shardingsphere-elasticjob-cloud-ui-frontend:3.1.0-SNAPSHOT drop off redundant dependencies?

[Celebrate-future]

This figure presents the dependency tree between multiple modules in shardingsphere-elasticjob-cloud-ui. As shown in this figure, Libraries

org.slf4j:jcl-over-slf4j:jar:1.7.26:compile org.slf4j:log4j-over-slf4j:jar:1.7.26:compile ch.qos.logback:logback-classic:jar:1.1.11:compile ch.qos.logback:logback-core:jar:1.1.11:compile

Vulnerable libraries

ch.qos.logback:logback-classic:1.1.11 (CVE-2017-5929) ch.qos.logback:logback-core:1.1.11 (CVE-2021-42550)

Outdated dependencies

ch.qos.logback:logback-classic:1.1.11 (2341 days without maintenance) org.slf4j:jcl-over-slf4j:1.7.26 (1622 days without maintenance)

---

in shardingsphere-elasticjob-cloud-ui-frontend and shardingsphere-elasticjob-cloud-ui-backend are inherited from their parent module. However, it is only actually used by shardingsphere-elasticjob-cloud-ui-backend. We can perform refactoring operations in the pom, by removing such redundant dependencies in shardingsphere-elasticjob-cloud-ui-frontend.

Specifically, the scope of org.slf4j:jcl-over-slf4j:jar:1.7.26, org.slf4j:log4j-over-slf4j:jar:1.7.26, ch.qos.logback:logback-classic:jar:1.1.11 in shardingsphere-elasticjob-cloud-ui-frontend can be changed from compile to provided. The revisions in the pom are described as follows: Removing the redundant dependencies can reduce the size of project and prevent potential dependency conflict issues (i.e., multiple versions of the same library). More importantly, one of the redundant dependencies ch.qos.logback:logback-core:jar:1.1.11:compile incorporates a medium-level vulnerability SNYK-JAVA-CHQOSLOGBACK-1726923. As such, I suggest a refactoring operation for org.apache.shardingsphere:shardingsphere-elasticjob-cloud-ui-frontend:3.1.0-SNAPSHOT’s pom file.