Execution of Gradle task "libertyCreate" fails during execution of "productInfo.bat" if called from another Gradle Plugin

[UlrichLohrmann]

Hallo,

we use io.openliberty.tools:liberty-gradle-plugin:3.9.4 and have a Gradle plugin that extends the functionality of the Open Liberty ci.gradle plugin.

Our plugin defines a task "copyLibertyShared" that fills the $WLP/usr/shared/config directory of the Open Liberty installation with some common configuration files. The "copyLibertyShared" task is configured to depend on the "libertyCreate" task. So if "copyLibertyShared" is called the task "installLiberty" is executed before "copyLibertyShared".

During the execution of "installLiberty" in this scenario we get the following output:

Gradle Daemon started in 3 s 28 ms

Task :buildSrc:compileJava NO-SOURCE
Task :buildSrc:compileGroovy UP-TO-DATE
Task :buildSrc:processResources NO-SOURCE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :MokkaConnector:compileJava UP-TO-DATE
Task :MokkaConnector:processResources UP-TO-DATE
Task :MokkaConnector:classes UP-TO-DATE
Task :MokkaConnector:jar UP-TO-DATE
Task :MokkaConnector:rarDistZip UP-TO-DATE

Task :mokkascripts:installLiberty
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 10. This API is incompatible with the configuration cache, which will become the only mode supported by Gradle in a future release. Consult the upgrading guide for further information: https://docs.gradle.org/9.2.1/userguide/upgrading_version_7.html#task_project
[ant:get] Destination already exists (skipping): C:\Users\00000572\AppData\Local\Temp\wlp-cache\openliberty-jakartaee9.1-25.0.0.12.zip
[ant:server] Der Server MOKKA-Liberty wurde erstellt.

Task :mokkascripts:libertyCreate
[ant:server] CWWKM2001I: Invoke command ist ["D:\Programme\openLiberty\openLiberty-MOKKA\wlp\bin\server.bat", create, MOKKA-Liberty, --template=jakartaee9].
The default D:\Programme\openLiberty\openLiberty-MOKKA\wlp\usr\servers\MOKKA-Liberty\server.env file is overwritten by inlined configuration.

Task :mokkascripts:installFeature

Signaturen werden überprüft ...
<---------------------> 0,00%
Alle Funktionen wurden erfolgreich überprüft.

Task :mokkascripts:installFeature FAILED

[Incubating] Problems report is available at: file:///D:/IDEA-U/MOKKA/MokkaGradle/build/reports/problems/problems-report.html
9 actionable tasks: 3 executed, 6 up-to-date

FAILURE: Build failed with an exception.

• What went wrong:
  **Execution failed for task ':mokkascripts:installFeature'.

io.openliberty.tools.common.plugins.util.PluginExecutionException: productInfo exited with return code 9009. The productInfo command run was "D:\Programme\OpenLiberty\openLiberty-MOKKA\wlp\bin\productInfo.bat" validate**

I tried put a "rem" before the "@echo off" in the productInfo.bat file, but no more additional info ist dumped to the console then. It seems that the console output of the forked "productInfo.bat" ist not displayed in Gradle's output window.

After the error, I start the "copyLibertyShared" task again and then the Open Liberty installation is finished without any further error.

Any idea what could be the reason of the "productInfo.bat" error?

Best regards
Ulrich

[venmanyarun]

Hi @UlrichLohrmann

Exit code 9009 on Windows specifically indicates:

"Program is not recognized as an internal or external command"
This is a Windows-specific error meaning the executable or batch file cannot find a required command in its PATH

I checked productInfo.bat. This throws 9009 when:

• Windows cannot find the java command and returns exit code 9009
  It could be because

• None of the Java home variables are set (JAVA_HOME, JRE_HOME, WLP_DEFAULT_JAVA_HOME)

• The script falls back to using "java" from PATH (line 41)

• When called from a nested Gradle plugin context, the PATH environment variable doesn't include the Java bin directory

• Why Second Execution Succeeds

On the second run:

• The Gradle daemon has fully initialized
• Environment variables are properly propagated
• The java command is now in PATH or JAVA_HOME is set
• The script successfully executes

To confirm this, can you retry the same flow after clearing your build directory? Also can you check after setting java home variables system wide or in gradle.properties ?

[UlrichLohrmann]

Hi @venmanyarun

thank you for your fast reply.
Indeed, the JAVA_HOME variable in the global Environment ist not set which probabbly results in the error situation I described.

I don't want to set JAVA_HOME in my Environment but would prefer if the Java version would be used during execution of productInfo that Gradle uses for execution.

Wouldn`t ist be nice if the Gradle Plugin would check before start of productInfo.sh/bat whether or not JAVA_HOME ist set in the current environment and if not provide the started productInfo process with a JAVA_HOME environment variable with the content of System.getProperty('java.home')? That would never lead to a sitation where productInfo could not find java command. I could provide the code to do so.

Best regards
Ulrich

[venmanyarun]

Hi @UlrichLohrmann
can you try using the WLP_DEFAULT_JAVA_HOME ?
Or you can try setting a JAVA_HOME in server.env as well

[UlrichLohrmann]

Hi @venmanyarun

my scenario is the following

I use IntelliJ IDEA on my workstation for development. In IDEA the current JDK ist configured and also in the current project. Also in IntelliJ IDEA Gradle ist configured to use project default JDK for build. So nowhere else than in IntelliJ IDEA settings the JDK in use is configured. If I switch to a newer version of a JDK I simple change the JDK's installation path in IntelliJ settings and that's it. No modification of property files or other files. That's why JAVA_HOME ist not set upon execution of a Gradle build.

What I don't want ist that after a switch to a newer JDK in IntelliJ modify additional files with the same configuration (the path of the newer JDK).

Inside a Gradle build I cannot add JAVA_HOME to the environment (at least I found no way to do that). So the only way to provide JAVA_HOME ro productInfo in my scenario ist to modify the logic in ci.common, class InstellFeatureUtil, method productInfo.

Best regards
Ulrich