Publication of jars built with Quarkus and dependency tree

[jmini]

We have a Quarkus multi modules containing following modules:

1. A Quarkus server app
2. Some shared code
3. A client SDK to connect to the server

We are using gRPC so 2. contains the proto definitions and the java models, modules 1. and 3. have a dependency on 2., but I think the problem would be the same regardless of the technology (REST, graphQL, ...)

It makes sense for us to build those together since they share some logic/code.

---

When we publish the client-SDK jar, it has a lot of dependencies. Extract of a mvn org.apache.maven.plugins:maven-dependency-plugin:3.6.1:tree command:

    +- io.quarkus:quarkus-kotlin:jar:3.1.2.Final:runtime
...
    |  +- io.quarkus:quarkus-core:jar:3.1.2.Final:compile
    |  |  +- jakarta.enterprise:jakarta.enterprise.cdi-api:jar:4.0.1:compile
    |  |  |  +- jakarta.enterprise:jakarta.enterprise.lang-model:jar:4.0.1:compile
    |  |  |  +- jakarta.el:jakarta.el-api:jar:5.0.0:compile
    |  |  |  \- jakarta.interceptor:jakarta.interceptor-api:jar:2.1.0:compile
    |  |  +- jakarta.inject:jakarta.inject-api:jar:2.0.1:compile
    |  |  +- io.smallrye.common:smallrye-common-os:jar:2.1.0:compile
    |  |  +- io.quarkus:quarkus-ide-launcher:jar:3.1.2.Final:compile
    |  |  +- io.quarkus:quarkus-development-mode-spi:jar:3.1.2.Final:compile
    |  |  +- io.smallrye.config:smallrye-config:jar:3.2.1:compile
    |  |  |  \- io.smallrye.config:smallrye-config-core:jar:3.2.1:compile
    |  |  |     +- org.eclipse.microprofile.config:microprofile-config-api:jar:3.0.2:compile
    |  |  |     +- io.smallrye.common:smallrye-common-expression:jar:2.1.0:compile
    |  |  |     |  \- io.smallrye.common:smallrye-common-function:jar:2.1.0:compile
    |  |  |     +- io.smallrye.common:smallrye-common-classloader:jar:2.1.0:compile
    |  |  |     +- org.ow2.asm:asm:jar:9.4:compile
    |  |  |     \- io.smallrye.config:smallrye-config-common:jar:3.2.1:compile
    |  |  +- org.jboss.logging:jboss-logging:jar:3.5.1.Final:compile
    |  |  +- org.jboss.logmanager:jboss-logmanager-embedded:jar:1.1.1:compile
    |  |  +- org.jboss.logging:jboss-logging-annotations:jar:2.2.1.Final:compile
    |  |  +- org.jboss.threads:jboss-threads:jar:3.5.0.Final:compile
    |  |  +- org.slf4j:slf4j-api:jar:2.0.6:compile
    |  |  +- org.jboss.slf4j:slf4j-jboss-logmanager:jar:2.0.0.Final:compile
    |  |  +- org.graalvm.sdk:graal-sdk:jar:22.3.2:compile
    |  |  +- org.wildfly.common:wildfly-common:jar:1.5.4.Final-format-001:compile
    |  |  +- io.quarkus:quarkus-bootstrap-runner:jar:3.1.2.Final:compile
    |  |  |  \- io.smallrye.common:smallrye-common-io:jar:2.1.0:compile
    |  |  \- io.quarkus:quarkus-fs-util:jar:0.0.9:compile
    |  +- org.jetbrains:annotations:jar:24.0.1:runtime
    |  +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.8.21:runtime
    |  +- org.jetbrains.kotlin:kotlin-reflect:jar:1.8.21:runtime
    |  +- io.smallrye.reactive:mutiny-kotlin:jar:2.1.0:runtime
    |  |  \- org.jetbrains.kotlinx:kotlinx-coroutines-core:jar:1.6.4:runtime
    |  +- io.smallrye:smallrye-fault-tolerance-kotlin:jar:6.2.3:runtime
    |  \- org.jetbrains.kotlinx:kotlinx-coroutines-jdk8:jar:1.7.1:runtime
    |     \- org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:jar:1.7.1:runtime
    +- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10:runtime
    |  \- ...

According to my knowlege many of those dependencies are not even used at runtime.
They come from the fact that all the quarkus extentions are put on the implementation configuration (probably because with maven there is no other flexibility).

I would like to have a "clean" published client library:

1. because currently I can not use the client in a jbang script. https://github.com/orgs/jbangdev/discussions/1774
2. because those could be an issue if they are used in other projects (that might not even be based on Quarkus)
3. less dependencies is always better

Because I can probably not solve this at quarkus level (even if I think it makes no sense to have the quarkus extensions on the implementation configuration), my current idea is to investigate if I can modify the metadata (pom file) of the published client:

• https://docs.gradle.org/current/userguide/publishing_customization.html#sec:adding-variants-to-existing-components
• https://stackoverflow.com/questions/68470193/exclude-dependency-from-pom-using-maven-publish-plugin

Is there a way to identify if a quarkus extension contains some runtime code or if its code is only involve at build-step time.