https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Can you provide a build 
--scan
? It contains pretty good information about the dependencies and where they come from. If not, maybe the 
dependencyInsight
task can help you.
The exclude you showed should work for the transitive dependency of xml graphics common though.
Except you also have it in another configuration and do not exclude it there.
Also, if you really want to generally exclude it, you might consider excluding it on the whole configuration instead.
If it is about a dependency that has a bad dependency, you might instead use a component metadata rule to fix the metadata instead of using an exclude.
But 
commons-logging
is just a logging API, so usually you should not need to exclude it, but to provide the proper bridging artifact that forwards the 
commons-logging
logged messages to your chosen logging implementation like 
log4j-core
.
h
There is a wired issue occurred in our project, all 
log.debug
etc, does not print message as expected. Our project is a spring boot project, by default it includes logback-classic as logging framework. So I tried to remove other logging libs in the project.
I found it is also required by dataframe plugin.
v
Well, as I said, that's the wrong solution. That will cause the logging calls to fail. Most logging libs, including 
commons-logging
are just log facades that require that you put the proper bridging library onto the runtime classpath. So if you use 
logback-classic
as logging framework, you need to put the according 
slf4j
bridges for the log facades your dependencies use. So for 
commons-logging
you would need 
org.slf4j:jcl-over-slf4j
on the runtime classpath, for 
java.util.logging
, 
org.slf4j:jul-to-slf4j
, for log4j 
org.slf4j:log4j-over-slf4j
and so on. Some bridges like the one for JUL might require additional actions, for example to set a system property before any logging call is done and enabling also the intended log level or all levels for that and so on.
I found it is also required by dataframe plugin.
That's in the build logic. Gradle should care about providing the bridging libraries to capture those log files. That has nothing to do with your production classpath.
h
spring boot stater logging includes all essential logging libs, by default it use logback, but it seems it does not include 
jcl-over-slf4j
. I have just added this explicitly, but the log in our project still does not work, no any output message from our log.debug in the console.
Copy code
+--- org.springframework.boot:spring-boot-starter-logging:3.1.0
|    |    |    +--- ch.qos.logback:logback-classic:1.4.7
|    |    |    |    +--- ch.qos.logback:logback-core:1.4.7
|    |    |    |    \--- org.slf4j:slf4j-api:2.0.4 -> 2.0.7
|    |    |    +--- org.apache.logging.log4j:log4j-to-slf4j:2.20.0
|    |    |    |    +--- org.apache.logging.log4j:log4j-api:2.20.0
|    |    |    |    \--- org.slf4j:slf4j-api:1.7.36 -> 2.0.7
|    |    |    \--- org.slf4j:jul-to-slf4j:2.0.7
|    |    |         \--- org.slf4j:slf4j-api:2.0.7
And spring-jcl itself should provides an implementation of 
commons-logging
API and also can bridge other logging to this impl since spring 5.x.
v
from our log.debug
Well, what logging library do you use there? If it is not 
commons-logging
then the discussion about how to get the 
commons-logging
logs is moot for your concrete problem, even though valid in general. What type is 
log
?
h
I always used slf4j API in the past years.
Copy code
private val log = LoggerFactory.getLogger(XXX::class.java)
Our log config in the Spring Boot applicaion.properties is not changed for months. In this period, we only update deps by dependabot, not sure if possible a plugin and a dep will affect the application log output.
v
Plugin classpath should not influence the application output, no. And if you use sfl4j, then 
logback-classic
should get the log messages. Unless there is maybe also some other slf4j implementation, but then it should usually also complain that there are multiple on the classpath. Your build scan shows that there is just 
slf4j-api
, 
jul-to-slf4j
, 
log4j-to-slf4j
, and 
logback-classic
on the runtime classpath. So if you log using slf4j, the messages should come through properly if your logback configuration enables the messages. The JCL messages will still be lost unless you add the according bridge library, but that should not affect your slf4j log calls.
16 Views
Open in Slack
PreviousNext
Powered by