You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The application layout with bin, conf and lib is good for developing or using it inside Docker. But I would prefer to have the option for a fat-jar with all dependencies. This makes it easier to handle to just need to download a single file. And execution is simple because I do not need to specify the classpath.
My final goal is to compile it to a native image with GraalVM, so distribution is also independent from the jvm.
I already played around with the config of the maven-assembly-plugin.
I added the jar-with-dependencies to the configuration but was not able to get it working:
Hello,
Even if I didn't thought about it, of course this is a great idea.
I had a look, and I identified two problems with it:
The Maven Resolver implementation is based on Eclipse Sisu (which is based on Google Guice) and that doesn't work well inside the JAR with dependencies.
The init.gradle file from the classpath couldn't be passed as an argument anymore to Gradle.
Solutions:
Migrate from Eclipse Sisu to the new Supplier implementation of Maven Resolver (will be compliant with the version 2 in the future)
Write the content of the init.gradle file to a temporary file that can be passed to Gradle
The application layout with
bin
,conf
andlib
is good for developing or using it inside Docker. But I would prefer to have the option for a fat-jar with all dependencies. This makes it easier to handle to just need to download a single file. And execution is simple because I do not need to specify the classpath.My final goal is to compile it to a native image with GraalVM, so distribution is also independent from the jvm.
I already played around with the config of the
maven-assembly-plugin
.I added the
jar-with-dependencies
to theconfiguration
but was not able to get it working:Of course, I can understand that this is not a must-have feature, and It may be additional work to support two assembly modes.
The text was updated successfully, but these errors were encountered: