Crash when trying to run a product built with buildProduct

[icedevml]

Hello,

I'm using Ubuntu Jammy (22.04.3 LTS) with OpenJDK 17 and gradle version 7.3. I'm running gretty in 4.1.1 version.

Whenever I build the product using gradlew buildProduct, I'm getting the following exception when trying to run it using the generated run.sh script:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
Exception in thread "main" groovy.lang.MissingPropertyException: No such property: numberOfArgs for class: org.apache.commons.cli.Option
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:65)
        at org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.getProperty(GetEffectivePojoPropertySite.java:65)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetPropertySafe(AbstractCallSite.java:448)
        at groovy.cli.commons.OptionAccessor.getTypedValue(OptionAccessor.groovy:101)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.codehaus.groovy.runtime.callsite.PlainObjectMetaMethodSite.doInvoke(PlainObjectMetaMethodSite.java:43)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:193)
        at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:61)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:203)
        at groovy.cli.commons.OptionAccessor.getProperty(OptionAccessor.groovy:150)
        at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
        at org.akhikhl.gretty.Runner.main(Runner.groovy:34)

I've tried to upgrade to gradle 8.5 with OpenJDK 21 - the issue is exactly the same. I've also changed the Ubuntu version to the latest one and it doesn't help too.

The same codebase builds and runs fully correctly on Windows, under exactly the same OpenJDK versions.

I would like to kindly ask you for assistance with debugging this one. I feel like I've already looked at it from every possible angle and I can't spot what is wrong. The crash is somewhat very early and related with some CLI arguments parsing in runner, although I don't fully understand what really happens there.

Could you please provide some guidance on how to troubleshoot the issue?

[f4lco]

Hello @icedevml! I have a reproducer on macOS for this one.

I can only assume this is a dependency conflict - either Gretty ships multiple competing versions of apache-commons-cli, or we have an incompatibility between groovy-cli-commons and apache-commons-cli.
From the stacktrace, it looks like groovy-cli-commons tries to call a method on apache-commons-cli which ceased to exist.

The order on the classpath can vary from one JRE to the next, or from one operating system to the other.
When Gretty runs fine on Windows, and not on Linux, this means there is at least one compatible version of apache-commons-cli on the classpath, and by luck sometimes the JRE gives priority to the compatible version.

As a workaround, can you try and delete runner/commons-cli-1.5.0.jar from the output folder of buildProduct and report back if that makes Gretty run?

[icedevml]

Hello @f4lco and thanks for your help.

I can confirm that the issue is resolved with the workaround that you have provided. Gretty runs succesfully through run.sh when runner/commons-cli-1.5.0.jar is deleted.

And yeah, I was even comparing hashes of all the build artifacts. They are exactly the same, so I think that you are right. It must be the difference in the classpath precedence across Windows and UNIX systems.

[icedevml]

@f4lco By the way, not sure if it's related, but:

grettyStarter
+--- org.gretty:gretty-starter:4.1.2
|    +--- org.gretty:gretty-core:4.1.2
|    |    +--- commons-cli:commons-cli:1.5.0  <--------------
|    |    +--- commons-configuration:commons-configuration:1.10
|    |    |    +--- commons-lang:commons-lang:2.6
|    |    |    \--- commons-logging:commons-logging:1.1.1
|    |    +--- commons-io:commons-io:2.14.0
|    |    +--- org.apache.commons:commons-lang3:3.12.0
|    |    +--- org.bouncycastle:bcprov-jdk15on:1.70
|    |    \--- org.gretty:gretty-common:4.1.2
|    \--- org.slf4j:slf4j-api:2.0.9
+--- org.codehaus.groovy:groovy-cli-commons:3.0.17
|    +--- org.codehaus.groovy:groovy:3.0.17
|    \--- commons-cli:commons-cli:1.4 -> 1.5.0  <--------------
\--- org.codehaus.groovy:groovy-json:3.0.17
     \--- org.codehaus.groovy:groovy:3.0.17

So there at least two versions of the commons-cli:commons-cli in the dependency graph.