https://gradle.com/ logo
Join Slack
Powered by
Hello platform. How is everyone? I'm seeking for s...
# community-support
f
Hello platform. How is everyone? I'm seeking for some experienced eyes to understand this so I'm finally joined. I can't figure out why while running the wrapper 8.7 (on top of 4.4.1) I cannot read the 
org.gradle.java.home
property set in my gradle.properties located in the _GRADLE_USER_HOME_ but when using the same path in java_home env virable it is taken. I don't get it, I unset the environment variables and stop the daemons.. it should be the second place with priority
Here are some other details by the way: 1. I'm not setting GRADLE_USER_HOME (I'm assuming it is known by gradle). 2 The gradle.properties I was talking about is located at 
~/.gradle/gradle.properties
Oh it is 8.7 not 8.9, let me fix that in the main question..
A little note before the "Also".. When I set/unset the JAVA_HOME env variable I don't need to restart the daemons. I mentioned it as in "I've also tried that". Now, also ... I would think the toolchain is failing but if I specify an sdk I don't have it does download it (like the 19 that I just specified in my languageVersion just as a test. Here is the output of querying the toolchains:
Copy code
karma|May10|22:53:57¦Patrones¦ ./gradlew -q javaToolchains

 + Options
     | Auto-detection:     Enabled
     | Auto-download:      Enabled

 + Debian JDK 17.0.11+9-Debian-1deb12u1
     | Location:           /usr/lib/jvm/java-17-openjdk-amd64
     | Language Version:   17
     | Vendor:             Debian
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Common Linux Locations

 + Eclipse Temurin JDK 11.0.23+9
     | Location:           /home/karma/.jdks/jdk-11.0.23+9
     | Language Version:   11
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        IntelliJ IDEA

 + Eclipse Temurin JDK 11.0.23+9
     | Location:           /home/karma/.gradle/jdks/eclipse_adoptium-11-amd64-linux/jdk-11.0.23+9
     | Language Version:   11
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

 + Eclipse Temurin JDK 17.0.11+9
     | Location:           /home/karma/.jdks/temurin-17.0.11
     | Language Version:   17
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        IntelliJ IDEA

 + Eclipse Temurin JDK 19.0.2+7
     | Location:           /home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7
     | Language Version:   19
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

 + Eclipse Temurin JDK 21.0.3+9-LTS
     | Location:           /home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9
     | Language Version:   21
     | Vendor:             Eclipse Temurin
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        Auto-provisioned by Gradle

 + OpenJDK 22.0.1+8-16
     | Location:           /home/karma/.jdks/openjdk-22.0.1
     | Language Version:   22
     | Vendor:             Oracle
     | Architecture:       amd64
     | Is JDK:             true
     | Detected by:        IntelliJ IDEA
Copy code
karma|May10|23:37:53¦Patrones¦ ./gradlew properties | grep java.home
org.gradle.java.home: /home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9
karma|May10|23:38:14¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.11 (Debian 17.0.11+9-Debian-1deb12u1)
OS:           Linux 6.1.0-21-amd64 amd64

karma|May10|23:41:54¦Patrones¦ grep language app/build.gradle 
        languageVersion = JavaLanguageVersion.of(21)
Maybe the revisions has something to do with this.. like if the revision date could determine whether or not chose one or the other. I remember reading something about minor versions and revisions... I will check the docs again
a
can you try setting 
org.gradle.java.home
to be 
/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/Contents/Home/
?
f
That doesn't exists
Copy code
May10|23:46:12¦Patrones¦ echo $JAVA_HOME 
/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
karma|May10|23:46:24¦Patrones¦ ls $JAVA_HOME 
bin  conf  jmods  lib  man  NOTICE  provisioned.ok  release
But I will try
a
oh, weird! Maybe something changed in 21, or the layout is different for 
.gradle/jdks
...
I've got 
org.gradle.java.home=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/
f
Yeap it is invalid
Copy code
FAILURE: Build failed with an exception.

* What went wrong:
Value '/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/Contents/Home' given for org.gradle.java.home Gradle property is invalid (Java home supplied is invalid)
At least it confirms an invalid path. So it has to be tied to the revisions
Is it safe to manually clear the 
~/.gradle/caches
right?
a
yes
I guess that the toolchains downloaded into 
.gradle/jdks/
can be used by Gradle to compile or run Java, but not run Gradle itself
do you have Java 21 installed in a regular location?
f
oh.. the cache is for gradle.. ok
It is all in user space (I posted it up there in a message). The only one set at system level is the 17. I have one 17 at user space but I didn't get any complaint about it yet 'cos I just been trying to use other than 17
OK I give up. I will check the bugs/issues list for this version and more recent because this is weird. It does read the values but it ignore them. This doesn't happen if you set the JAVA_HOME env variable, but using the properties file is completely ignored. There might be some messing with the priority order
Copy code
karma|May11|00:39:38¦Patrones¦ grep -r java.home ~/.gradle/gradle.properties 
org.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
karma|May11|00:39:46¦Patrones¦ grep -r java.home ./gradle.properties 
org.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7
karma|May11|00:39:49¦Patrones¦ ./gradlew properties | grep java.home
org.gradle.java.home: /home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
karma|May11|00:40:07¦Patrones¦ ./gradleW --version
bash: ./gradleW: No such file or directory
karma|May11|00:40:21¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.11 (Debian 17.0.11+9-Debian-1deb12u1)
OS:           Linux 6.1.0-21-amd64 amd64
And this also happen to the D and P flags from the cli the only thing that works is set that JAVA_HOME:
Copy code
karma|May11|00:40:28¦Patrones¦ export JAVA_HOME=/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
karma|May11|00:47:07¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          21.0.3 (Eclipse Adoptium 21.0.3+9-LTS)
OS:           Linux 6.1.0-21-amd64 amd64

karma|May11|00:47:12¦Patrones¦ export JAVA_HOME=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7
karma|May11|00:47:35¦Patrones¦ ./gradlew --version

ERROR: JAVA_HOME is set to an invalid directory: /home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

karma|May11|00:47:37¦Patrones¦ export JAVA_HOME=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7/
karma|May11|00:47:53¦Patrones¦ ./gradlew --version

ERROR: JAVA_HOME is set to an invalid directory: /home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7/

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

karma|May11|00:47:55¦Patrones¦ ./gradlew build

ERROR: JAVA_HOME is set to an invalid directory: /home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7/

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

karma|May11|00:48:35¦Patrones¦ unset JAVA_HOME 
karma|May11|00:48:50¦Patrones¦ ./gradlew build
Path for java installation '/usr/lib/jvm/openjdk-17' (Common Linux Locations) does not contain a java executable

BUILD SUCCESSFUL in 28s
7 actionable tasks: 7 executed
karma|May11|00:49:22¦Patrones¦ export JAVA_HOME=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7/
karma|May11|00:49:29¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          19.0.2 (Eclipse Adoptium 19.0.2+7)
OS:           Linux 6.1.0-21-amd64 amd64
v
oh, weird! Maybe something changed in 21, or the layout is different for .gradle/jdks...
Neither. The difference is, that you are using macOS while Federico is using Linux and macOS always needs something special.
I guess that the toolchains downloaded into .gradle/jdks/ can be used by Gradle to compile or run Java, but not run Gradle itself
They are just regular JDKs, they can be used for any purpose, there is nothing Gradle-specific about them besides the location.
I don't have a computer at hand. Does it work if you set it in the 
gradle.properties
of the project instead?
f
Thank you for jumping in. Hi. Neither files nor CLI flags are being considered. You can see the property is set, but it is not carried on
OK it is late what am I doing?! I'm not gonna waste anyone's time with this. I'll back "tomorrow". Thanks for the help
v
What I know is, that in the project directory in the properties file the property is used. At least with 7.6.4. I do use testkit tests where I use that to test a Java version check in a plugin.
f
I see. But you don't need software to test this, it is really simple. Change the property to a different jdk. If you are not getting any feedback from that when using actions (running tasks) then: • change the languageVersion in your ./AppRootFolder/$AppName/build.gradle to reflect your intentions to use the same JDK you had just set in the gradle.property (java.home). • Then check the version you are using with 
./gradlew --version
is it set the version you want? Let me show you another output, pay attention to the first message where it is aware of the incompatibility and stops the daemon:
Copy code
## I've just changed project settings to use jdk 19 instead of 17
## No environment variables set (because they actually work)
karma|May11|07:39:40¦Patrones¦ ./gradlew clean
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

BUILD SUCCESSFUL in 17s
1 actionable task: 1 executed
karma|May11|07:40:05¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.11 (Debian 17.0.11+9-Debian-1deb12u1)
OS:           Linux 6.1.0-21-amd64 amd64

karma|May11|07:40:26¦Patrones¦ ./gradlew build
Path for java installation '/usr/lib/jvm/openjdk-17' (Common Linux Locations) does not contain a java executable

BUILD SUCCESSFUL in 10s
7 actionable tasks: 7 executed
karma|May11|07:40:43¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.11 (Debian 17.0.11+9-Debian-1deb12u1)
OS:           Linux 6.1.0-21-amd64 amd64

karma|May11|07:40:46¦Patrones¦ grep java gradle.properties && grep language app/
build/        build.gradle  src/          
karma|May11|07:40:46¦Patrones¦ grep java gradle.properties && grep language app/build.gradle 
org.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7
        languageVersion = JavaLanguageVersion.of(19)
karma|May11|07:42:39¦Patrones¦ echo $JAVA_HOME && echo $GRADLE_USER_HOME


karma|May11|07:43:09¦Patrones¦ grep java.home ~/.gradle/gradle.properties 
org.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
Is it supposed to follow the hierarchy and prioritize the property set at the $HOME/.gradle/gradle.property before the one in the project. Still it doesn't care. I mean if you print ./gradlew properties you can see it's set, but doesn't change anything. And we are talking about setting this property in two different places and it still is failing to set. You could argue the file is misspelled, or in the wrong path, but what about the CLI flags -D and -P ? They change nothing .. let me show you:
Copy code
karma|May11|08:01:36¦Patrones¦ ./gradlew properties | grep java.home
org.gradle.java.home: /home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
karma|May11|08:01:56¦Patrones¦ git status
On branch main
nothing to commit, working tree clean
karma|May11|08:03:42¦Patrones¦ ./gradlew -Dorg.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7 \
> -Porg.gradle.java.home=/home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

> Task :help

Welcome to Gradle 8.7.

To run a build, run gradlew <task> ...

To see a list of available tasks, run gradlew tasks

To see more detail about a task, run gradlew help --task <task>

To see a list of command-line options, run gradlew --help

For more detail on using Gradle, see <https://docs.gradle.org/8.7/userguide/command_line_interface.html>

For troubleshooting, visit <https://help.gradle.org>

BUILD SUCCESSFUL in 5s
1 actionable task: 1 executed
karma|May11|08:04:40¦Patrones¦ ./gradlew --version

------------------------------------------------------------
Gradle 8.7
------------------------------------------------------------

Build time:   2024-03-22 15:52:46 UTC
Revision:     650af14d7653aa949fce5e886e685efc9cf97c10

Kotlin:       1.9.22
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.11 (Debian 17.0.11+9-Debian-1deb12u1)
OS:           Linux 6.1.0-21-amd64 amd64

karma|May11|08:04:46¦Patrones¦ git status
On branch main
nothing to commit, working tree clean
karma|May11|08:05:14¦Patrones¦ ./gradlew properties | grep java.home
org.gradle.java.home: /home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9/
(I failed to add a slash at the end of the paths in this opportunity but it doesn't change the final result, I just checked it just in case that observation arises) And yes, the path is valid:
Copy code
karma|May11|08:10:51¦Patrones¦ ls /home/karma/.gradle/jdks/eclipse_adoptium-19-amd64-linux/jdk-19.0.2+7/
bin  conf  include  jmods  legal  lib  man  NOTICE  provisioned.ok  release
So I think I have enough confidence this is a bug, hence I will open a ticket (to value your time, to help others, and to document it) but honestly I'm not with too much time to learn debug gradle plugins (mainly because I don't know about gradle plugins)
OK so I finally could make sense of 
--info
· I can see -D flag is passed out (not ignored as I though), · also the hierarchy is respected · and the daemon is started with the correct version Bad news is that · (apparently) the daemon will expect that -D flag for every action otherwise properties set at gradle user home will take precedence (I mean they will override your local properties. Which is known but I don't know, my concept of the -D flag was different similar to an environment variable but for this project. Something like "plesase override", however it makes sense because "for how long". Alright.. This has been interesting
By the way: the info shown by ./gradlew --version about the JVM is influenced by the jdk version found by the JVM starter (the wrapper) that is the one looking for that JAVA_HOME variable. So these value, will be different to the default (or system-wide-installation) if the env-variable is set not otherwise. We (debian based SO users) are still getting the undesired/confusing output about the not java executable found for openjdk17. But there is an issue opened already, and there is an easy workaround, set the JAVA_HOME. But not in the bashrc or .profile files because that would override (??) the properties set at gradle user home? I don't know yet ...
Copy code
Wanted: DefaultDaemonContext[uid=null,javaHome=/home/karma/.jdks/jdk-11.0.23+9,daemonRegistryDir=/home/karma/.gradle/daemon,pid=44987,idleTimeout=null,priority=NORMAL,applyInstrumentationAgent=true,daemonOpts=--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]

Actual: DefaultDaemonContext[uid=ded5d221-95c4-4c68-a909-4836b5d9517d,javaHome=/home/karma/.gradle/jdks/eclipse_adoptium-21-amd64-linux/jdk-21.0.3+9,daemonRegistryDir=/home/karma/.gradle/daemon,pid=42950,idleTimeout=10800000,priority=NORMAL,applyInstrumentationAgent=true,daemonOpts=--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]
Jss.. this is killing me. Everything is fine, everything works but I could swear that so far setting the env-variable have been fixing that problem with the java executable warning.. and it is back 😪 I replied an issue in github about that as a workaround... shame
v
I'm a bit uncertain what your findings are now. So does everything work as expected, you just understood it wrong? Or is still something questionable or unclear?
f
Hello Vampire. I know this thread is a mess, but my observations have helped me to understand Gradle a little better. While I could explain what I think it's still "wrong" and confusing I don't know the expertise of those people trying to help me to solve these issues. So based on that (maybe there are more users than developers reaching out in this channel) I'm considering to stop adding more personal conclusions and outputs, and accept this is just a learning stage. Mainly because: • I don't know when I'm in a mistake until I figure it out by myself. And that makes this thread hard to follow . I mean this would be simpler if someone could easily understand the question (that is my fault), or quickly spot that it's a misunderstanding of concepts. • I've been using an environment variable (both: using and as a replacement of the gradle.properties files) because of the immediate effect I was getting from querying the wrapper version. However that was mistake. The JVM version returned by 
gralew --version
was the one used by the lightweight client not the daemon running the logic. It could be if the org.gradle.java.home is not specified in gradle.properties files. However, using an old JDK with a recent wrapper logs enough warnings and errors to realize the client should be running a more recent version (or the one it was made for) but a daemon which is assigned to use the specified metadata will not complain. Besides this could lead to bigger "what is going on" if users have the JAVA_HOME set at user-session level (.profile, _.bash_aliases,_ or .bashrc). Despite the errors a target machine will use what it has installed so here the solutions would be to ignore the logs or downgrade the wrapper (I certainly don't know yet), but from the development point of view the environment variable would be handy in virtual environments and containers. --- but wait.. not because the environment variable will override the gradle.properties value, no, but because the wrapper version reported is going to return the one detected at the specified found at the env-variable path. Which if not set, will be the one the wrapper detects. Later, the toolchains resolver will do its job but for the daemons. Do you see how messy (complex under the hood) it is? And this leads to the final point of my observations • I still don't know (under review) if the resolver will pick the appropriate jdk or it will just report the available options. It's a plugin included for a reason: to make this work.. and my programs work simply by changing/updating the value of the language version in the toolchain at the project configuration. So I assume it just work. However, it runs even if the properties are set. this have two three downsides 1. If there is a compatible daemon available, this is completely unnecessary. 2. If there isn't a compatible daemon available, then it should first check if the java home has been specified. You can see this in the following issue at github 3. It does this report/log about the not found path every time it runs a task. So the question is are we using the resolver every single time?
Although, complex doesn't necessarily mean bad. I love this auto detection functionality. The documentation is rich about configuration options, however I had to go deep into Gradle (just chapter one 😅) to understand how it works, but my goal was to use it first then learn better. This took some time but I still choose following this path (learn to use the default gradle) than using an integration such as IntelliJ where they are not even using the resolver (at first glance) but some custom mechanism.. Choosing Gradle not their custom builder. I mean gradle is already customized by them and I don't want by any means hold a dependency to Jetbrain because I think that's their game, and they play very smart
v
To be honest, I think I still not really follow.
I mean gradle is already customized by them
It's not, is it? They just use the regular Gradle tooling API that also the CLI uses to drive Gradle builds. Afaik there is no customization. Just some init scripts to add integration what exactly is what init scripts are mainly for. I feel that you are mixing up various things. To start the CLI process you need some Java, this is detected by the start scripts. This looks for 
JAVA_HOME
or the 
java
in the 
PATH
and uses that to start the CLI process. The CLI process then considers 
org.gradle.java.home
for starting the Daemon process or if not set, the same that was used to start the CLI process. For neither JVM Toolchains are in any way relevant currently. JVM Toolchains are only for things like compiling, testing, or running your production code. (This actually changes with 8.8 where an incubating possibility is added to also use a detected toolchain by given criteria - but not to auto-provision one - to start the daemon process)
f
Am I mixing things? With all respect, maybe you should review the docs. The cli process you are talking about becomes a lightweight jvm. Then it becomes smart enough to communicate with existent/running daemons or start them and log everything. Have you even looked up the code? If it's specified to not do it (--no-daemon) then it becomes a daemon itself. Anyways I would NOT rest importance to the toolchains unless you want what you said, use the same Java installation the wrapper is using. And forget about change JDK version without worrying where they are. In fact, if you take away the javaToolchain from the build then problem solved.. no more messages like this
Copy code
Path for java installation '/usr/lib/jvm/openjdk-17' (Common Linux Locations) does not contain a java executable
However, as you said, for testing we would have to do some custom extra work, not really a smart move. But.. if instead we disable OH MY GOSH .. give me a second Oh lord.. This works. Finally some useful help! Thank you Vampire. I will test this a little more and upload this possible workaround to the issue in github mentioned above Let's just consider for a moment I'm mixing things.. would be that my fault (or caused by a disability) or the natural complexity of the software? Check this out, it is f#~ nonsense! Tell me how this makes sense to you.
To solve the problem caused by the javaToolchain I disabled java-installation-auto-detection but somehow the java toolchain keeps doing what it does (without the discovery???) and downloads what it needs (just if it doesn't exists.. so there is no discovery but it knows when (I mean it does not override and extract.. but auto-detect is disables. Isn't that weird?)
My rhetorical question doesn't help much but it somehow explains the filling.. the complexity makes us think that we don't get it.. that we need to have a deep/better understanding while in fact it's not really really clear. I know you didn't try say something offensive, instead something like "you're getting it wrong". And it's OK. I hope my sarcastic answer to that is not sarcastic enough
v
> With all respect, maybe you should review the docs. I'm happy to learn something new every day. Please tell me which doc exactly I should review that says something differently than I said. > If it's specified to not do it (--no-daemon) then it becomes a daemon itself. No it does not. If it is right-away used, but only if it fulfills the requirements, which it nowadays practically never does. Thus a single-use daemon is almost always started when you use 
--no-daemon
. > In fact, if you take away the javaToolchain from the build then problem solved.. no more messages like this >
Copy code
Path for java installation '/usr/lib/jvm/openjdk-17' (Common Linux Locations) does not contain a java executable
Sure, if no toolchains are searched for, then no complaint about a place where a JDK is expected but not present. If that is your main concern, check why there is not a valid JDK in that directory. Probably either some left-overs, or a 
...src
package installed without the actual JDK package which more-or-less can also be seen as left-over. > However, as you said, for testing we would have to do some custom extra work, not really a smart move. Did I? Which move is not smart? I'm really sorry, but I still don't quite get what you try to say. > Isn't that weird?) No. JDKs it auto-provisioned itself are not detected. They are auto-provisioned and managed and thus known by Gradle. They don't need to be detected, they are simply known. Auto-detection only affects locations not managed by Gradle, like typical installation places, typical keys in the Windows registry, typical package manager locations, and so on.
f
Oh is that how auto-detection works? It makes sense then with my last observations. About the source of documentation I mentioned before, you can find it here: https://blog.gradle.org/how-gradle-works-1 which is listed in the contributing documentations as part of "How Gradle works". The issue mentioned was for a particular point needing review. Another one was for example why the flags passed in a command (a build task or just passed out to the wrapper without tasks) was not making it to the project gradle.properties or (being a system property) why it was wasn't been persisted to the gradle.properties in the user-gradle folder. And the answer was that "they're for simple use scenarios" like running a task in certain conditions. This thread was/is so confusing mainly because it didn't have much assistance so I answering my own questions, sometimes with wrong answers.. It helped to learn but I doubt it will be helpful to someone looking for help. At least, it was self contained in a thread, that's the best I can say about this mess. Alright, it has been fun and formative. Definitely a much better feeling than the first time I started to use Gradle (a week ago or so)
v
> Oh is that how auto-detection works? It makes sense then with my last observations. Yes 🙂 > About the source of documentation I mentioned before, you can find it here: https://blog.gradle.org/how-gradle-works-1 which is listed in the contributing documentations as part of "How Gradle works". And it tells you exactly the same that I told you. So why made you read me that blog post? Or did I miss something? > Another one was for example why the flags passed in a command (a build task or just passed out to the wrapper without tasks) was not making it to the project gradle.properties or (being a system property) why it was wasn't been persisted to the gradle.properties in the user-gradle folder. Why should anything you give on the commandline be persisted to any file? That's not what is supposed to happen. You can have things in the project 
gradle.properties
that should be the same for everyone. You can nevertheless override those values by having them in your 
<GRADLE_USER_HOME>/gradle.properties
. And you can override those for each call where necessary by using 
-P
flags or 
-D
flags, depending on what kind of property it is. Or also using system properties or environment variables, if you for example can control those but not the commandline arguments or local files and so on like on some CI. But nothing you do will ever persist anything to those files. (Well, that's not entirely true, there are some plugins that indeed to persist some information in the 
<GRADLE_USER_HOME>/gradle.properties
file, but that is not core functionality we are talking about here) > At least, it was self contained in a thread, that's the best I can say about this mess. 👌 > because it didn't have much assistance I'm really sooo sorry, that I am not available 24/7 to immediately answer your questions in minutes in my sparse spare time and during my vacation. > Alright, it has been fun and formative. 🎉
f
Or did I miss something?
Really? I mean is this true?
So why made you read me that blog post?
To start there is no such a thing as a CLI process. There are processes, period. Some of them are started from the CLI, yes. But we are going to get there, just bare with me a few minutes because I have to put something clear: This is not about you, I'm not disappointed because you could not help earlier.. No, I started a thread on a weekend, I knew what I was doing, so you don't have to explain or much less be ironic about it
I'm really sooo sorry, that I am not available 24/7 to immediately answer your questions in minut ....
Indeed, what actually felt uncomfortable was, that after you said the following this weekend (after voluntarily offer some help)
I don't have a computer at hand. Does it work if you set it in the 
gradle.properties
of the project instead?
You came today (after I said this)
I don't know when I'm in a mistake until I figure it out by myself. And that makes this thread hard to follow . I mean this would be simpler if someone could easily understand the question (that is my fault), or quickly spot that it's a misunderstanding of concepts.
(as a reply to this)
I'm a bit uncertain what your findings are now.
So does everything work as expected, you just understood it wrong?
Or is still something questionable or unclear?
you came today to take the talk to concepts. Man I would love to do that before, not after I spent the hole weekend on this and by the time I had practically figured it all out ... That is why I felt that
I feel that you are mixing up various things.
a little personal, but relax, not too much personal. It felt uncomfortable because it actually looks like you have even more mixing-up-things than me. Now, let's proceed with the CLI process .. If you read it, and not just that but also the code and the workflow, you would know at this point you are wrong in your explanation about how I am mixing-up things.. but not much it is just we are referring the same with different names. This below is what you said (I repeat myself: "after I figured this out myself using the docs, that's why I'm making the trivial technical difference)
To start the CLI process you need some Java, this is detected by the start scripts.
This looks for 
JAVA_HOME
or the 
java
in the 
PATH
and uses that to start the CLI process.
The CLI process then considers 
org.gradle.java.home
for starting the Daemon process or if not set, the same that was used to start the CLI process.
You are calling this a CLI process, I was saying it is a lightweight JVM (that could potentially become a daemon) Again, trivial, no need to discuss beyond this but if you feel called to reply be my guest.. This is from the doc I shared you said you read
However, there is one exception for this workflow. If you pass 
--no-daemon
to the Gradle build, the client JVM may convert itself into a daemon JVM if it is compatible with build requirements
Now, a little excess on the technical concept. I felt the need to tell you you were using the wrong terminology because for me the CLI process you are talking about is the wrapper, not the lightweight jvm, and the lastone will then interact with another jvm (or convert itself). I don't think it is really a trivial annotation because what the wrapper collects (the java version and path) matters in terms of the info you see in the logs when it is not comfortable with the JDK it was passed to it. The daemon will not complain, but the client will
One more thing. I said this:
for me the CLI process you are talking about is the wrapper
but you said the CLI process is called by the start scripts.. so we are are talking about the same,.. The wrapper is the start script, the cli process is the client jvm. End of the discussion
And please please do not take it personal. I really don't know who I talking to. You might be a contributor, a Gradle user, an enthusiast, or the main contributor. All I know is you said this in #C03PU37T8TZ
Neither me nor Thomas are Gradle folks, and discussing here is a bit far from the issue
So sorry for questioning your knowledge or how accurate is a concept
v
> Or did I miss something?
Really? I mean is this true?
I ask you
To start there is no such a thing as a CLI process
Sure there is, even if you call it differently. I talk about the process that in the end starts the daemon, so the process that is started from the 
gradlew
script of the wrapper or the 
gradle
script of the distribution (that you usually shouldn't use).
so you don't have to explain or much less be ironic about it
I'm sorry, just wanted to make clear that you sound pretty passive-aggressive against a fellow user that is trying to help you in his spare time for free. 🙂
you would know at this point you are wrong in your explanation about how I am mixing-up things
Didn't want to blame you or anything, just tried to say that you might mix up things, as you seemed to talk about JVM toolchains where they are not relevant at all.
for me the CLI process you are talking about is the wrapper, not the lightweight jvm, and the lastone will then interact with another jvm (or convert itself).
For the sake of this discussion, this is exactly the same. The 
gradlew
started process will provision a given Gradle version and in-process use it. And at that point it is exactly the same as using the 
gradle
started process from a distribution. Both these cases I summarized as "CLI process" as it is the process you start using either of those scripts and then starts / communicates with a daemon process (or uses itself as daemon process if possible which is almost never the case nowadays as I said above) and provides the CLI of Gradle, showing output, letting you answer questions and so on. That blog post you linked just means the console where you type 
gradlew
or 
gradle
when it says CLI. That is also a CLI, but it is the CLI of the shell you use, not the CLI of Gradle that I was referring to. 🙂
The daemon will not complain, but the client will
If you are talking about the "this directory is not a proper JVM" complaint, that is coming from the daemon, not from the <however you call it>. This complaint is coming from the JVM toolchains feature which is not relevant for the <however you call it>, unless maybe you use the incubating feature in 8.8-rc-1 I mentioned above.
And please please do not take it personal.
Don't worry, if I would be taking everything said in here too personal, I'd have had various heart-attacks already. 😄
You might be a contributor, a Gradle user, an enthusiast, or the main contributor.
All but that last. 🙂 FOSS enthusiast using Gradle since pre-1.0 contributing regularly to Gradle and helping fellow users.
So sorry for questioning your knowledge or how accurate is a concept
Don't be sorry, you should always question anything you learn from the internet. There is many bad or outdated advice and knowledge out there, especially for something fast-evolving like Gradle. That I said we are no Gradle folks was just to make clear that we do not speak for Gradle as we are not affiliated to Gradle and that if you want to discuss your contribution with Gradle folks we are the wrong addressees. It was not meant to say that Thomas and I are not giving correct information, just that we can not speak for Gradle.
f
Alright main contributor not affiliated to Gradle. I see I've been out of place here then.. About the complains from the client
If you are talking about the "this directory is not a proper JVM...
I can't remember and I don't have the computer on (I'm at the kitchen) but I will take a look again. Just a quick look, I'm late after this weekend little adventure so no need to chase another log (from --info, I'm not sure it is even printed without it, but it was an [error]). What I do remember is that I was running the version 8.7 of the wrapper with the java home set in the environment to java 11. Alright, take care. Thanks
v
main contributor
No, not main contributor, I said all but the last. 😄 Just contributing occasionally some things, but I'm mentioned in most release notes. 🙂
💯 1
35 Views
Open in Slack
PreviousNext
Powered by