[FEATURE]: Ability to use System JDK for Jib

Feature Request

Garden Jib Provider should allow using the JDK installed on the System.

Background / Motivation

1. Support environments with alternate libc libraries, for example Alpine. If Garden runs in an Alpine container, JDK will not work because it depends on glibc, while alpine ships with musl. Executing the java binary results in a Not Found error, as shared libarary glibc cannot be found.
2. Support for any alternate JDK version / distribution. With this option you can use prerelease versions or alternative JDK distributions.

Costs

• This would come with the cost that different team members might end up using different versions. That is a trade our customers can make for themselves with this feature.
• In many cases, glibc compatibility libraries could be the better option. We could document this. Alpine Example: https://stackoverflow.com/a/68284294

What should the user be able to do?

If users specify the sdkVersion: system, it should detect system-installed JDK using PATH and/or JAVA_HOME env variables, and use that instead of downloading jdk.

Why do they want to do this? What problem does it solve?

There is a workaround of downloading the dependencies, and then symlinking the .garden/tools/openjdk-xx folder with the system java. But this solution is brittle and hacky. Official support for this use case saves developers who need this a lot of time on hacking a solution together.

Suggested Implementation(s)

Allow garden yaml option jdkVersion: system or useSystemJDK: true. Code location: https://github.com/garden-io/garden/blob/master/plugins/jib/index.ts#L51

if this option is specified, garden should autodetect the system JDK and use that instead of downloading it.

How important is this feature for you/your team?

🌵 Not having this feature makes using Garden painful

[laran]

@stefreak @vvagaytsev

A custom gradlePath seems like a good option.

• There is no gradle in my module folders.
• A freshly downloaded gradle would not be able to access the private repo I use.

Here’s more for context …

My project uses a custom Gradle 7.5.1.

I’m using Rancher-Desktop with Kubernetes 1.24.8+k3s1.

I use a private artifactory repository. The dependencies that the build fails on are supposed to come from artifactory. I’m logged into artifactory in my host os/shell. The garden build doesn’t seem to be able to use that though.

My project directory structure looks like this:

/project
/project/build.gradle
/project/gradle/wrapper/*
/project/gradlew
/project/gradle.properties
/project/project.garden.yml
/project/apps/app1
/project/apps/app1/build.gradle
/project/apps/app1/garden.yml
/project/apps/app2
/project/apps/app2/build.gradle
/project/apps/app2/garden.yml
/project/core
/project/core/build.gradle
/project/core/garden.yml
/project/shell
/project/shell/build.gradle
/project/shell/garden.yml

When I run garden dev the apps/* builds fail with a message like this:

Failed building app1. Here is the output:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Command failed with exit code 1:
/Users/laran/.garden/tools/gradle/c04163d9652793a8/gradle-7.5.1/bin/gradle jib
-Djib.to.image=app1:v-2c961f1603 -Djib.container.args=GARDEN_MODULE_VERSION=v-2c961f1603
-Dstyle.color=always -Djansi.passthrough=true -Djib.console=plain

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':core:compileJava'.
> Could not resolve all files for configuration ':core:compileClasspath'.
   > Could not find any matches for
com.foo:libA:latest.integration as no versions of
com.foo:libA are available.
     Required by:
         project :core
   > Could not find com.foo:libB:2.0.2.
     Required by:
         project :core

Because …

• apps/app1 depends on core
• core depends on libA and libB, both of which come from a private artifactory
• there is no gradle in the module folder
• and a freshly downloaded gradle can’t access the private artifactory

… the whole build fails.

[vvagaytsev]

There is an edge case in #3184. If we use explicit mavenPath and no explicit jdkPath, then we’ll pass the downloaded JDK’s home dir as a JAVA_HOME env var to the custom Maven. This looks like unexpected behavior. I’ll check this in detail later, the PR is still a draft.

The simplest solution is to ignore the JDK -related settings if an explicit mavenPath is specified. This means we’ll just use the provided Maven binary as it is. It seems natural to assume that the local Maven is configured properly – it means that the java command is already defined in the PATH.