Exclude commons-logging from resteasy-client-microprofile

[glefloch]

This makes sure commons-logging does not end up in the compile classpath of a gradle project.

close #20896

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building d9895cb

Status	Name	Step	Failures	Logs	Raw logs
✖	JVM Tests - JDK 11	Build	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 17

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: integration-tests/smallrye-opentracing 

📦 integration-tests/smallrye-opentracing

✖ io.quarkus.it.opentracing.OpenTracingTestCase. line 35 - More details - Source on GitHub

org.testcontainers.containers.ContainerLaunchException: Container startup failed
	at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:336)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:317)

[gsmet]

I wonder if we should add it to our exclusion list in the build parent?

Also maybe we should add the JBoss Logging Bridge? You should be able to find which one to use in some of the other extensions.

[glefloch]

Sure, I will give it a try

[glefloch]

@gsmet, commons-logging is already in the exclude list of the build parent (

quarkus/build-parent/pom.xml

Line 505 in 992dc5d

<exclude>commons-logging:commons-logging</exclude>

) I try to exclude it directly in the bom, this works too but I don't know if we should exclude it there.

[glefloch]

The commons-logging-jboss-logging is already declared in that pom.xml

[gsmet]

Hmm, but why don't we have an error if it's supposed to be excluded?

[glefloch]

@aloubyansky, @famod Do you know why commons-logging can be in transitive dependencies while it is banned in the maven-enforcer-plugin ?

[gsmet]

No, it catches everything.

There's something weird going on because I don't get any commons-logging when doing mvn dependency:tree for this module and in particular for resteasy-client-microprofile I get:

[INFO] +- org.jboss.resteasy:resteasy-client-microprofile:jar:4.7.0.Final:compile
[INFO] |  \- org.jboss.resteasy:resteasy-client-microprofile-base:jar:4.7.0.Final:compile
[INFO] |     +- org.jboss.resteasy:resteasy-client:jar:4.7.0.Final:compile
[INFO] |     |  +- org.jboss.resteasy:resteasy-client-api:jar:4.7.0.Final:compile
[INFO] |     |  \- commons-io:commons-io:jar:2.11.0:compile
[INFO] |     \- org.jboss.resteasy:resteasy-cdi:jar:4.7.0.Final:compile

[glefloch]

I don't think the problem comes from the plug-in but from gradle ignoring it when resolving dependencies. How does maven handles that enforcer rules from dependencies ?

[gsmet]

The enforcer just checks that the dependencies are not around, it doesn't exclude anything. So if we don't have it in the Maven dependencies, it's because, using the Maven resolver, the dependency is not around. What I don't understand is why Gradle sees it in its dependencies. Maybe it still includes the transitive dependencies of the excluded dependencies?

[glefloch]

That’s really weird. Some transitive dependencies may bring commons-logging back but I don’t know how

[michalszynkiewicz]

the error doesn't seem related

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building 7f8e25c

Status	Name	Step	Failures	Logs	Raw logs
✖	Initial JDK 11 Build	Build	⚠️ Check →	Logs	Raw logs

[gsmet]

OK, well, in any case, it doesn't hurt and we have checked that our enforcer plugin configuration is not missing anything here. I suspect there's something weird in how the dependencies are resolved in Gradle or our Gradle plugin, but we can merge this.

[vhmolinar]

@glefloch
As mentioned in the issue #20896 the extension quarkus-keycloak-admin-client brings back the commons-logging dependency.