sonar-scanner: Allow overriding JDK

[jonesbusy]

Use JDK17 for sonar-scanner which is the only supported version according to https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/scanner-environment/general-requirements/

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

Tested all the abose and ensuring correct JDK is used

$ sonar-scanner --version
06:10:48.484 INFO  Project root configuration file: NONE
06:10:48.497 INFO  SonarScanner CLI 6.2.1.4610
06:10:48.499 INFO  Java 17.0.12 Homebrew (64-bit)

[jonesbusy]

Fixed commit style

[SMillerDev]

Does it not work with a newer version? Homebrew generally does not use the latest version upstream documented, but the latest version that works.

[cesarjorgemartinez]

Hi I have my sonar-scanner break until find this PR.
I Apply these changes to test but not working in my case.
I use sonar-scanner to a sonar local with https and a own certificate. Then I use a copy of cacerts and add my own certificate (keytool), using the properties of truststore, etc.
But not working more:
HTTP FAILED: javax.net.ssl.SSLHandshakeException: None of the TrustManagers trust this certificate chain

I see a $HOME/.sonar directory that has one JRE.

.sonar/cache/003d3e0a65a2f0633b8bfed42be133724b490acb323c174c708d3a446d5fc660/OpenJDK17U-jre_aarch64_mac_hotspot_17.0.11_9.tar.gz_extracted/jdk-17.0.11+9-jre/Contents/Home/bin/java -version
openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode)

/opt/homebrew/opt/openjdk@17/bin/java -version
openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment Homebrew (build 17.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing)

Or, howto use my own external JRE/JDK 17?

[jonesbusy]

I didn't faced any particular issue. For me it just looked weird to run a non-LTS version of Java for the sonnar-scanner.

Related to @cesarjorgemartinez I cannot say. But looking at the bin on /home/linuxbrew/.linuxbrew/bin/sonar-scanner the JAVA_HOME is set on the command like. Make it not possible to use your own java (if it's installed via an other way, like SDKMAN)

I don't know enough homebrew how to manage such dependency. Can java be optional ?

I saw also other Formula ussing Language::Java.overridable_java_home_env but not sure how to use it and what is the purpose of it (maybe use any JDK ? Even your own ?)

[cesarjorgemartinez]

I didn't faced any particular issue. For me it just looked weird to run a non-LTS version of Java for the sonnar-scanner.

Related to @cesarjorgemartinez I cannot say. But looking at the bin on /home/linuxbrew/.linuxbrew/bin/sonar-scanner the JAVA_HOME is set on the command like. Make it not possible to use your own java (if it's installed via an other way, like SDKMAN)

I don't know enough homebrew how to manage such dependency. Can java be optional ?

I saw also other Formula ussing Language::Java.overridable_java_home_env but not sure how to use it and what is the purpose of it (maybe use any JDK ? Even your own ?)

My case for this issue, I have:
/opt/homebrew/opt/openjdk/bin/java -version
openjdk version "23" 2024-09-17
/opt/homebrew/opt/openjdk@17/bin/java -version
openjdk version "17.0.12"

Yes, I see the same variable inside the script sonar-scanner. I was using this file (/opt/homebrew/bin/sonar-scanner) to locate the JDK used and then, go to the cacerts, copy to one directory, and add my own certificate and use the properties (fastlane):

ENV['SONAR_SCANNER_OPTS'] = "-Djavax.net.ssl.trustStore=#{work_dir}/cacerts -Djavax.net.ssl.keyStore=#{work_dir}/cacerts -Djavax.net.ssl.trustStorePassword=xxx -Djavax.net.ssl.keyStorePassword=xxx"

But now no... Inside the sonar-scanner, download one JRE (maven https://github.com/SonarSource/sonar-scanner-cli/blob/master/pom.xml), put inside $HOME/.sonar and use this JRE. Example in my case:

find $HOME/.sonar/cache -name cacerts
.../.sonar/cache/003d3e0a65a2f0633b8bfed42be133724b490acb323c174c708d3a446d5fc660/OpenJDK17U-jre_..._17.0.11_9.tar.gz_extracted/jdk-17.0.11+9-jre/Contents/Home/lib/security/cacerts

In short, when launching the Java process, an external version of Java is used, but then for some obscure reason, internally, it uses one downloaded in $HOME/.sonar/cache. The repository is https://github.com/SonarSource/sonar-scanner-cli. I'm also looking at https://github.com/SonarSource/sonar-scanner-cli-docker. Or that it does not use any dependency and that it is the same jar that uses its own JRE...

Or, howto do a brew install sonar-scanner as a one concrete version and prevent to build one weird workaround for this issue?

[cesarjorgemartinez]

I didn't faced any particular issue. For me it just looked weird to run a non-LTS version of Java for the sonnar-scanner.

Hi @jonesbusy,

Can you try this?:

Doing a:
export use_embedded_jre=false

In file https://github.com/SonarSource/sonar-scanner-cli/blob/master/src/main/assembly/bin/sonar-scanner

Appear this:

#!/usr/bin/env sh
#
# SonarScanner CLI Startup Script for Unix
#
# Required ENV vars:
#   JAVA_HOME - Location of Java's installation, optional if use_embedded_jre is set
#
# Optional ENV vars:
#   SONAR_SCANNER_OPTS - Parameters passed to the Java VM when running the SonarScanner
#   SONAR_SCANNER_DEBUG_OPTS - Extra parameters passed to the Java VM for debugging

...
use_embedded_jre=${use_embedded_jre}
if [ "$use_embedded_jre" = true ]; then
  export JAVA_HOME="$sonar_scanner_home/jre"
fi

if [ -n "$JAVA_HOME" ]
then
  java_cmd="$JAVA_HOME/bin/java"
else
  java_cmd="`\\unset -f command; \\command -v java`"
fi

if [ -z "$java_cmd" -o ! -x "$java_cmd" ] ; then
  echo "Could not find 'java' executable in JAVA_HOME or PATH."
  exit 1
fi

[carlocab]

If you can update the test so that it shows sonar-scanner erroring out with a Java version that's too new, then we can make this change.

Otherwise, I've provided a suggestion below that will let you use this with your preferred Java runtime.

[carlocab]

This should let you use whichever Java version you like by setting JAVA_HOME:

Suggested change

	JAVA_HOME: Formula["openjdk@17"].opt_prefix
	JAVA_HOME: Language::Java.overridable_java_home_env

But this requires dropping the change to depends_on.

[jonesbusy]

Is now

#!/bin/bash
SONAR_SCANNER_HOME="/home/linuxbrew/.linuxbrew/Cellar/sonar-scanner/6.2.1.4610/libexec" JAVA_HOME="${JAVA_HOME:-/home/linuxbrew/.linuxbrew/opt/openjdk/libexec}" exec "/home/linuxbrew/.linuxbrew/Cellar/sonar-scanner/6.2.1.4610/libexec/bin/sonar-scanner"  "$@"

Tested with JAVA_HOME

$ sonar-scanner --version
...
16:12:18.176 INFO  Java 21.0.4 Eclipse Adoptium (64-bit)
...

$ unset JAVA_HOME
$ sonar-scanner --version
...
16:15:04.380 INFO  Java 23 Homebrew (64-bit)
...