https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
The 
JAVA_OPTS
line in 
gradle.properties
has no effect whatsoever. And the message is more info than warning. Do you mabe also have daemon disabled either by property or by commandline argument? Does maybe info or debug logging give more information? It should at least show the arguments with which the daemon is started.
👍 1
c
is that warning from your CI? I say so because for example when using Travis, it's travis who tries to disable gradle daemon by default
j
Yes its on CI. I guess I just read the docs wrong here and assume it would work by adding it to the 
gradle.properties
.
I guess my next question is: Can this be specified in the 
gradle.properties
?
c
the message is just telling you the daemon is disabled, I guess you can enable it from your gradle.properties (I don't know how your CI is disabling it and which method will have precedence)
but anyway, why do you care? unless you are running multiple gradle commands in the same CI job, it's exactly the same
j
Mostly its just annoying to look at. The question is if I can specify the "client vm" memory settings via the 
gradle.properties
file
v
Why should you want to? It is basically just a dumb output processor, it shouldn't need an increase in memory.
And no, I don't think you can specfiy it in 
gradle.properties
, because it is the first process to start so it it a hen and egg problem. You would need to have the process running to read the 
gradle.properties
to know the VM settings to start the process with which to read the 
gradle.properties
.
j
Yeah I get that but maybe the gradle wrapper script would do it
looking through it that does not seem to be the case though
v
That's not really possible. properties file are not as trivial as they seem to be
You can have various separators, multi-line entries, unicode escapes, different encodings, ...
And it doesn't really make sense, as the client is just a dumb terminal basically so you don't need to increase the VM RAM settings.
And if you really need to, you need to do it outside the Gradle properties, for example using actual environment variables.
j
My biggest issue is that I hate to train people to ignore warnings. It sets a poor precedence. Its difficult enough to get people to take warnings seriously so they act on it rather than ignoring it
c
but for that...look how your CI disables gradle daemon and override it
v
It's not a warning, it's info
And influencing the client VM parameters would not change anything regarding that log line
but for that...look how your CI disables gradle daemon and override it
That's most likely not possible though
You could use a custom Gradle distribution 😄
c
isn't it? If CI is setting in ~/.gradle/gradle.properties: org.gradle.daemon=false you can write org.gradle.daemon=true which one takes precedence userHome or project?
v
user home
Because you want as user override the defaults defined for the project
j
Reading https://docs.gradle.org/7.3.3/userguide/gradle_daemon.html#sec:disabling_the_daemon it seems to imply that the log line is output because the memory settings differ
c
(I don't remember how Travis did it, but as we wrote our own custom workers we removed that)
v
That is then only beaten by commandline
But it is actually unlikely that CI uses the user-specific file
Usually they use the commandline arguments and thus cannot be beaten
Except by a custom Gradle distribution
c
not even env vars? Then.. adding org.gradle.daemon=true to the home properties (so it will have both 😂 )
The issue is CI is doing something wrong because it used to be the right thing years ago
v
it seems to imply that the log line is output because the memory settings differ
That's one option. As I said, look at info or debug output, that should give more information, especially the daemon arguments
not even env vars?
No, env var will not beat commandline argument
j
We use
Copy code
org.gradle.jvmargs=-Xmx2048M
so it is only/also caused by this
But I think I have my answer. Thanks for participating all.
v
The issue is CI is doing something wrong because it used to be the right thing years ago
That's arguable actually. Gradle indeed recommends in the userguide to have it enabled even on CI. But I usually also disable the daemon on CI due to various reasons. For example if you have a build that uses some tool that uses static state, builds will influence each other even cross-project. You can avoid that with disabling the daemon for a little slower builds because the daemon has to start up. But on CI I prefer correctness over speed.
so it is only/also caused by this
No, if you run two builds with this setting, the second would still reuse the daemon of the first. It most likely really is that the daemon is disabled.
Especially as it logs that it will quit the daemon at the end of the build
c
a build that uses some tool that uses static state
Then the daemon may be the last of your problems anyway, I usually see ephemeral CI disabling the daemon, when there it's not unnecessary (and shouldn't really matter)
v
Even ephemeral CI could benefit from the daemon if you run multiple Gradle invocations within the ephemeral box.
Then the daemon may be the last of your problems
Why? As long as each build is running in a new process it works fine. Of course at developers it might (and did) cause trouble. But at least on CI it would be correct builds.
It was Spotbugs having that issue iirc.
c
Precisely, as Dev, you would had the same issue. Good that CI keeps working, but I don't think CI should disable a feature be default because some plugin did something terribly wrong.
And yes, you can benefit from it on CI, I don't see any reason to disable it.
v
I don't see any reason to enable it and risk incorrect builds for a few seconds time saving Well, I think we can agree that we will not agree on that. 🙂
c
Hahaha, fine 👍
18 Views
Open in Slack
PreviousNext
Powered by