Can not use a jar built with quarkus with Jbang

[jmini]

We have a Quarkus multi module build where one module is:

• A client SDK to connect to the server
• A quarkus server app

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
    |  \- ...

---

Point 1) probably we can improve the publication process of our library. It is probably wrong that this one is based on quarkus. This is probably a "dependency leak", due to the current project setup.

Point 2) right now when we start a small jbang script that is using this single library, it doesn't work. We get:

jbang MyScript.java --verbose
[jbang] Building jar for MyScript.java...
[jbang] Post build with io.quarkus.launcher.JBangIntegration
[jbang] [ERROR] Issue running postBuild()
[jbang] Run with --verbose for more details

The --verbose flag does not help.

Any idea how I can prevent the JBangIntegration step to be executed (I think it is inquarkus-ide-launcher) ?
My guess is that I am not interested at all by the quarkus tooling for this jar, since this is not a quarkus app.

Or what can I do to investigate what is going on?

---

If there is some interest, I could try to share a reproducer.

Maybe the problem is more in the quarkus project setup than in Jbang itself...

[quintesse]

The --verbose flag does not help.

The --verbose flag has to be put before the filename, anything after the filename is considered arguments for the application.

[maxandersen]

btw. the reason 999-snapshot being fetched here is due to that is the default GAV set for a jbang jar.... if you add //GAV some.org:app:1.0.0. in your .java it should change.

not that its right - but just explaining what is happening.

[quintesse]

I wondered about that actually, I looked at the code but I couldn't find the "dev.jbang.user:quarkus" anywhere? Only the "999-SNAPSHOT", so I wasn't sure where that would come from. I assumed from the Quarkus integration.

[maxandersen]

Hmm. Might be the quarkus jbang integration that does that as quarkus requires gav

[jmini]

I added //GAV some.org:app:1.0.0 in my jbang script and it doesn't help.

I looked at the stacktrace, and for me the fetch of dev.jbang.user:quarkus:999-SNAPSHOT is hard-coded here:
https://github.com/quarkusio/quarkus/blob/937f4ba0959c5ae690f5afc00a66784f37e88f51/independent-projects/bootstrap/core/src/main/java/io/quarkus/bootstrap/jbang/JBangBuilderImpl.java#L54-L55

So the question is more, which repo is needed to fetch this.

The next question is: if I am using a released version of Quarkus, why doesn't it fetch that version from maven central?

And the third question is: can't I instruct jbang to not run postBuild step? In this case I am not running/building a quarkus app. I just have a regular jar that happens to have io.quarkus:quarkus-ide-launcher:jar:3.1.2.Final on its classpath for a reason I did not investigated yet.

[maxandersen]

1. about hardcoding - you are correct and this is something missing in the jbang / quarkus integration. jbangbuilder was made before jbang had GAV support and that was missed

2. why not fetch from maven central - unless you specified mavencentral as snapshot repo it will not go there but rather resolve locally and then look in your snapshot defined maven repos order?

3. about not running buildstep - yes, correct we don't have a way to turn that off. your usecase or rather "unfortunate situaton" here probably warrants we have a way to turn it off. Wanna open issue/pr ? somewhere in the call chain of

   jbang/src/main/java/dev/jbang/source/AppBuilder.java

   Line 98 in 826755c

   integrationResult = getIntegrationBuildStep().build();

   we should have an "off" switch.

[maxandersen]

You are not pointing to a quarkus app jar afaics. You are pointing to a jar with lots of quarkus Dev deps.

Not sure what to suggest as not sure what app you have but as long as the pom says it has those deps jbang Will honor that.

And as we don't have exclude option yet it will cosntinue happen.

Possible solutions as of today is to point to a Uber jar or make a pom.xml with the true dependencies.

[maxandersen]

Btw. I don't think this is jbang specific issue -. Same happens wuth maven or Gradle I assume?

[jmini]

I can run the same script class from my IDE inside a maven project where I turned the //DEPS and //REPOS into their corresponding notation in the pom.xml. Maybe using the exec:exec task would run more stuff than when I start the main(..) from my IDE. I don't know.

But if I run my script with maven or gradle, how should they be aware of the io.quarkus.launcher.JBangIntegration SPI. This is a jbang thing, not?

---

And yes the dependency tree of the jar doesn't look healthy, and this is due to a too-quick setup of the multi-module gradle project containing the quarkus app.

The scenario to have one repo hosting a multi-module app where one module is the back-end app (quarkus app) and an other module is the jar needed to connect to this back-end is IMO a good pattern that brings a lot of benefit:

• You can share the models classes
• You can generate the client code based on your contract (grpc or OpenAPI) also used by the server or even derived by the server
• Inside your CI you can have some tests making sure that your client code stays compatible and up-to-date with the server
• You release the client code and the server at the same time.

Probably we missed something, since we do not want our client jar have that much dependencies. Ideally it should be independent of quarkus to be able to use it anywhere. But until we have identified why we have this leak of dependencies, it means there is no way to run the client-jar inside a jbang script?

[maxandersen]

yes, so dependency wise its the same - too much stuff shows up on the classpath due to the content of the pom.xml.

Ultimately the proper fix is you make a separate module or deployment that does not have the extra deps, but I also agree jbang can and should improve here: one is off/on switch for integrations(#1776), second is abilty to exclude deps (#150)

[jmini]

too much stuff shows up on the classpath due to the content of the pom.xml.

Is this a topic in the quarkus project?
The current setup is to put each quarkus extension on the compile classpath, which sounds wired to me (maybe it does the right thing but I never looked at the internals of what this means).

This is somehow fine for the use-case of working on a single-module app, but for multi-module projects with publication on a distant maven repo.

I know that in maven you do not have all the possibilities that you can have with gradle and the different configurations where you can put dependencies compileOnly, api, implementation, annotationProcessor. With this approach you could come up with a quarkusExtension configuration where you put the extensions on and then add only the relevant jars to the relevant configurations.

[maxandersen]

Is this a topic in the quarkus project?

kind of. not sure what we can do to fix it as its really a maven limiitation.

[jmini]

This is solved with version 0.122.0 and usage of the //NOINTEGRATIONS flag:

///usr/bin/env jbang "$0" "$@" ; exit $?

//DEPS <client SDK based on quarkus>
//JAVA 17
//NOINTEGRATIONS

import static java.lang.System.out;

public class MyScript {

    public static void main(String... args) {
        out.println("start");
        // usage of the client SDK containing the dependency to quarkus
        out.println("end");
    }
}