Build and dependencies

The default jar packages only your compiled classes. The first dependency class that the code uses is absent at runtime. To fix this, build a fat/uber jar that includes the dependency classes.

Source: https://docs.gradle.org/current/userguide/building_java_projects.html

The cluster provides Flink, so mark it compileOnly (provided). If you use implementation, Gradle bundles Flink into the job jar. This causes classloader and version conflicts and LinkageErrors on the cluster.

Source: https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/dev/configuration/overview/

Those are signature files of signed jars. After merging, the archive content no longer matches the signatures, so the JVM's jar verifier rejects it. Standard fat-jar practice drops them.

Source: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html

java -jar reads Main-Class from META-INF/MANIFEST.MF to find the entry point. Without it, you get 'no main manifest attribute'.

Source: https://docs.oracle.com/javase/tutorial/deployment/jar/appman.html

Relocation renames the packages of bundled libraries. Then multiple versions can coexist without conflict. This is why the Shadow plugin exists. The plugin also merges service descriptor files.

Source: https://docs.gradle.org/current/userguide/java_library_plugin.html

Gradle's Jar task fails on duplicate paths unless you set DuplicatesStrategy. EXCLUDE keeps the first file in a deterministic way. The truly correct handling MERGES service files (what Shadow's mergeServiceFiles does).

Source: https://docs.gradle.org/current/javadoc/org/gradle/api/file/DuplicatesStrategy.html

implementation is compile+runtime. So a fat-jar task that reads runtimeClasspath bundles it. compileOnly is compile-time only. It is intentionally not on the runtime classpath and not in the fat jar.

Source: https://docs.gradle.org/current/userguide/java_library_plugin.html