This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a commit to branch release18.12
in repository
https://gitbox.apache.org/repos/asf/ofbiz-framework.gitThe following commit(s) were added to refs/heads/release18.12 by this push:
new 36464a5 Improved: Gradle logging hygiene (OFBIZ-12085)
36464a5 is described below
commit 36464a5b84babfbf3d1f0035618d71f32da07332
Author: Jacques Le Roux <
[hidden email]>
AuthorDate: Fri Dec 11 17:58:54 2020 +0100
Improved: Gradle logging hygiene (OFBIZ-12085)
Some times ago, we were forced to stop and quickly restart the demos because of
the Gradle daemons logging taking all the place; though we don't use Gradle
daemons in demos. Weird isn't ?
The reason is that by default org.gradle.logging.level=lifecycle is verbose.
Anyway, all org.gradle.logging.level are verbose. I mean they also duplicate
OFBiz information, have a look into your own Gradle daemon dir!
And that even if you don't use daemons, as we do for demos. Because Gradle
always uses at least 1 daemon to run.
So I was looking for a solution to not uselessly clutter the VM disk demos and
stumbled upon <<Gradle logging hygiene - Issue #2688>> - gradle/gradle (github.com)
This uses Evgeny Naumenko's solution at
https://discuss.gradle.org/t/gradle-daemon-produces-a-lot-of-logs/9905
I backport because it's needed by demos
# Conflicts:
# build.gradle
---
build.gradle | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/build.gradle b/build.gradle
index ea87cff..1a07097 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1155,3 +1155,11 @@ def gradlewSubprocess(commandList) {
exec { commandLine(gradlew, "--no-daemon", *commandList) }
}
+
+def gradle = project.getGradle()
+new File("${gradle.getGradleUserHomeDir().getAbsolutePath()}/daemon/${gradle.getGradleVersion()}").listFiles().each {
+ if (it.getName().endsWith('.out.log')) {
+ logger.debug("Cleaning up daemon log file $it")
+ it.delete()
+ }
+}