Quarkus manages org.bouncycastle:bctls-jdk18on dependency in the applicaton BOM even though it doesn't use it

[michalvavrik]

Describe the bug

Quarkus manages dependency org.bouncycastle:bctls-jdk18on here:

• quarkus/bom/application/pom.xml

  Line 3507 in dd04f1e

  <artifactId>bctls-jdk18on</artifactId>

And it uses the dependency in a integration test module here:

• quarkus/integration-tests/bouncycastle-jsse/pom.xml

  Line 33 in dd04f1e

  <artifactId>bctls-jdk18on</artifactId>

And documents this dependency usage here:

• quarkus/docs/src/main/asciidoc/security-customization.adoc

  Line 506 in dd04f1e

  <artifactId>bctls-jdk18on</artifactId>

When downstream builds of Quarkus (like the Red Hat one I am interested in) builds this project from source, they need to solve a dilemma that this dependency is not used but managed, should they ship it as well? Now, if it was something regular I'd not mind, but Quarkus QE has a tool that detect such a cases and this is the only issue (for which we don't have an exception). I'd like to check, this is intentional and desirable?

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @pedroigor (bearer-token), @sberyozkin (bearer-token,jwt,security)

[michalvavrik]

I think @gsmet and @aloubyansky are the most knowledgeable people on this topic, so CC-ing them.

[geoand]

Might be useful to get the info @aloubyansky produced for the JGit here

[aloubyansky]

@michalvavrik could you clarify what the actual issue is?

Now, if it was something regular I'd not mind, but Quarkus QE has a tool that detect such a cases and this is the only issue

What do you mean by "regular" and not regular in this case?

[aloubyansky]

AFAICS, there are a multiple artifacts from BC aligned on the same version, so this looks good to me.
The same would apply to Jackson, Vert.x, Netty, etc. We don't necessarily use all their components but we still import their complete BOMs in the quarkus-bom.

[aloubyansky]

It looks like the doc also shows it'd be useful to have this dependency managed

[michalvavrik]

What do you mean by "regular" and not regular in this case?

We have a tool analyzing this and this (let alone some native artifacts and gradle API) was the only artifact that was reported as managed but not used. I presume there are some exceptions to this, but it is definitely not like 100 of artifacts.

It looks like the doc also shows it'd be useful to have this dependency managed

Fine with me, I just wanted to check.

AFAICS, there are a multiple artifacts from BC aligned on the same version, so this looks good to me.
The same would apply to Jackson, Vert.x, Netty, etc. We don't necessarily use all their components but we still import their complete BOMs in the quarkus-bom.

Alright thank you. I'll close this issue tonight. @rsvoboda can reopen if he sees a different point of a view.

[gsmet]

I think the idea was to make sure BC artifacts would be consistent when people use them.

Now the BC dependencies look like a landmine with various artifacts for various JDK versions. I'm not sure it makes sense to keep this one but I wouldn't want to break apps either.

[michalvavrik]

Understood, thank you for all your feedback.