How can I run a Gradle wrapper build with a configurable JDK?

[Brian Duguid]

We are running Atlassian Bamboo Data Center version 9.2.1 build 90201 and most of our build plans use Gradle.  We have been using the Groovy Tasks for Bamboo plugin since we began using Gradle which has been working great.  The plugin is for Server and they do not have a Data Center version.   We recently upgraded our remote agent count on Bamboo from 10 to 25, but we are not able to upgrade the plugin license from 10 to 25 agents.  The last email from their support is unclear as to the future of the plugin, but it was clear that they couldn't support it now since it was a Server Only plugin.

We need to move from this plugin to either another plugin (which I cannot easily find) or to a native Bamboo task like Script.

I can run the ./gradlew command in Script, but I am not finding any direction on how to change the JDK version.  The agent is running on JDK 11, but the code requires JDK 8.  The code is being upgraded to use JDK 17.  All three JDKs are installed on the agents and the capabilities have been configured for the agents.

How do I change the JDK version for the task using a defined JDK capability?

Is there an alternative Gradle plugin?  

Is the Script Task the best choice for this without a plugin?  

[Eduardo Alvarenga · Accepted solution]

Hello @Brian Duguid

You can specify the JAVA_HOME during runtime, such as:

gradlew build -Dorg.gradle.java.home=/JDK_PATH

 More info here:

• Gradle Build Environment

As you have the capabilities set in Bamboo, you can benefit from them by running something like:

gradlew build -Dorg.gradle.java.home=${bamboo_capability_system_jdk_JDK_8}

Sincerely,

Eduardo Alvarenga
Atlassian Support APAC

--please don't forget to Accept the answer if the reply is helpful-- 

[Brian Duguid]

@Eduardo Alvarenga thank you for the suggestion and example.  That mostly worked.  Apparently the plugin also isolated the JDK in the task from the JDK the Bamboo Agent service is running on.

Our project currently requires JDK 8.  It uses OSGi and the testing framework uses reflection to perform the tests.

The remote Bamboo Agents are running on Ubuntu and JDK 11.  Using the Groovy Task for Bamboo plugin, our project builds and tests successfully.

When I run the build using the method you described, the build is successful but the testing fails with and "An illegal reflective access operation has occurred" error as described in the Felix issue: https://issues.apache.org/jira/browse/FELIX-5765

Setting the JAVA_HOME variable in the Environment variables presumably sets the gradlew's cmd to use the same JDK 8, but the error is still thrown.  

I attempted to use the --illegal-access=permit and --add-opens switches to various places in the build, but an unknown command option error is thrown because those are not present in JDK 8.

I thought about adding the switches to the wrapper.conf of the Bamboo agent, but even if that worked that wouldn't be a good solution.

When I changed the Bamboo agent to run on JDK 8, everything worked as it should.

So my follow up question is, why is the Bamboo Agent JDK influencing the build process using Script Task, but not when using the Groovy Tasks for Bamboo plugin?  Is this more of question for Bamboo Data Center support?

[Brian Duguid]

EDIT: removed duplicate.

[Eduardo Alvarenga]

Hi @Brian Duguid,

Thanks for the thorough explanation.

Your gradle command is likely using your "java" 11 binary. Additionally to declaring the $JAVA_HOME, please check your $PATH environment variable and add the Java 8 path before Java 11. Or remove Java 11 from it.

Adding this to your Script Task should do the trick:

export JAVA_HOME=${bamboo_capability_system_jdk_JDK_8}
export PATH=$JAVA_HOME/bin:$PATH
gradlew ...

Sincerely,

Eduardo Alvarenga
Atlassian Support APAC

--please don't forget to Accept the answer if the reply is helpful-- 

[Brian Duguid]

Thank you @Eduardo Alvarenga.  That was the missing piece.  Our crisis has been averted.

If anyone finds them in a similar situation, based on Eduardo's guidance, this is what is working for me.

Global variable:

global.gradle.daemon = true

This is a precaution based on a thread I read about the Gradle daemon not terminating.  We have a lot of build plans each with one to four Gradle executions. I am being overly protective here.

Plan variables:

plan.java.home = ${bamboo.capability.system.jdk.JDK 1.8}
plan.gradle.daemon = ${bamboo.global.gradle.daemon}

I put the JDK as a plan variable so it can be overridden by a branch plan as well as easy configuration for two or more Gradle calls per plan.

Script Task example:
Everything after `-Dorg.gradle.daemon=${bamboo.plan.gradle.daemon}` is build specific.

#!/usr/bin/env bash  

export JAVA_HOME=${bamboo.plan.java.home} 
export PATH=$JAVA_HOME/bin:$PATH 
java -version 
set -x 
 
./gradlew \
  -Dorg.gradle.java.home=${bamboo.plan.java.home} \
  -Dorg.gradle.daemon=${bamboo.plan.gradle.daemon} \
  build export \
  ${bamboo.plan.build.exclusion.test} \
  ${bamboo.plan.build.exclusion.export} \
  --stacktrace \
  -DbuildVersion=${bamboo.injected.buildVersion} \
  -DbuildArtifactVersion=${bamboo.injected.buildVersion} \
  -DbuildResultKey=${bamboo.buildResultKey} 

[Eduardo Alvarenga]

Hey @Brian Duguid

I'm happy to know the solution worked for you! Thank you for sharing your implementation details. That will certainly assist other Community members in the future.

Best regards,

Eduardo Alvarenga
Atlassian Support APAC

[Brian Duguid]

EDIT: removed duplicate.