I'm trying to improve the startup time of Gradle. The expererimental --daemon switch doesn't seem to really speed it up. So I'm thinking to use some server process independent of gradle, and make gradle connect to it. The options I found so far are
nailgun to invoke java
GroovyServ to invoke a groovy script
Since gradle is started by a shell script, it takes some tweaking. My question is: has anyone used the above options to start gradle? Or if you have successfully used another option, what's that?
My guess is that your build is doing something at configuration time that it should be doing at execution time. With m5, gradle build --profile will give you an HMTL report showing where the time goes. Another way to see what's going on is gradle build --info or gradle build --debug.
Related
IntelliJ IDEA 2021.1 and 2021.2 leaves the Gradle Daemon running when I exit the program. I would like to know if there is a way to momentarily stop or restart the Gradle Daemon from within IntelliJ without exiting. Gradle has a lock on files that doesn't go away when simply closing IntelliJ. The only way to get it to release the lock is to run gradle --stop from the version of Gradle that is currently running. The approaches I've found so far are far less than ideal. I'll share them in case they help anyone else, but I'm hoping there's a better way.
If I manually browse to my User Home.gradle\wrapper\dists\gradle-x.y.z-all<hash>\gradle-x.y.z\bin for the version of Gradle that I know IntelliJ is using, then I can manually run that gradle command with --stop flag and it will stop the daemon. So, yeah I guess I could create a batch script for this, but the fact that it is stored in such a buried directory involving some sort of hash code, I don't really want to have to change this script for different systems.
In InteliJ IDEA, If I click the "elephant" looking button at the top of the gradle menu called "Execute Gradle Task" it brings up a command line that starts with "gradle", but it only accepts established task names, it doesn't accept "gradle --stop". It gives the error Unknown command-line option '--stop'.
As a less than ideal work around, I have copied the gradle-x.y.z folder from near the end of that path to c:\Gradle\ and I have added that version's bin folder to the PATH environment variable. So, at least, I can open up a command prompt and run gradle --stop for now. This becomes problematic when I want my default / command line accessible gradle version to be different from the project I am working on. Yeah I could create a bunch of custom batch scripts that point to all different versions. That doesn't sound like fun. I have a hard time believing that I can't do something within IntelliJ to get the currently running gradle daemon to shutdown.
IDE does not kill Gradle daemon, because this demon can be reused by another build, including when doing a build from the command line.
There is an action Show Gradle Daemons (you can call it from Help | Find Action action):
It will show you the list of Gradle daemons with the ability to stop them:
We wired https://github.com/sherter/google-java-format-gradle-plugin into our project per the readme.
We also wired in a pre-commit hook to run the plugin before committing, which ensures that all of the code in a changelist is formatted before pushing it, which avoids errors in Jenkins when we run the verGJF task.
But we have to keep remembering to run goJF locally before running ./gradlew build, or the build fails with formatting errors.
We worked around this by adding the https://plugins.jetbrains.com/plugin/8527-google-java-format and https://plugins.jetbrains.com/plugin/7642-save-actions plugins for IntelliJ, enabling the google-java-format plugin, and configuring the save-actions plugin to format on save.
But that's a lot of extra configuration a developer has to remember to go through, plus it means they can't format code the way they want while working on it, and only have it be reformatted at the point of build or commit.
We'd prefer an all-Gradle solution, so that the goJF task is run before the build task (and before the verGJF task, which is already bound to the build task by the google-java-format Gradle plugin).
We couldn't figure out how to do that. Does someone else know?
It sounds like you want to essentially always ensure that the code is properly formatted before the verifyGoogleJavaFormat task is run (and could complain). In that case, I’d simply make the googleJavaFormat task a dependency of the verifyGoogleJavaFormat task. In your build.gradle file, after you have applied the google-java-format plugin, simply add the following:
verifyGoogleJavaFormat.dependsOn(tasks.googleJavaFormat)
Alternatively, if you really only want to run the code formatter when the build task is run (as opposed to when the verifyGoogleJavaFormat task is run only), you could add this instead:
build.dependsOn(tasks.googleJavaFormat)
verifyGoogleJavaFormat.mustRunAfter(tasks.googleJavaFormat)
I'm very new to App-V, which is evaluated in my office.
I have a Selenium test suite written in JUnit5 and can launch it as gradle test task using gradle-wrapper. My final goal is to run this on App-V5.1 virtualized environment, similar as this question.
As followed the link which was mentioned the answer, I tried to launch cmd.exe within the App-V environment, and it seeded works. Then, I tried to do this:
./gradlew --no-daemon clean test
Then the testClasses phase works perfectly, but in the test phase, I got an error like:
Could not write standard input into: Gradle Worker 1.
java.io.IOException: The pipe is being closed
...
(Sorry I couldn't show you the actual error log due to security reason, but it is similar to this question.)
May I wrong something? What's the right way to launch a gradle test in App-V env?
Have you tried launching cmd.exe from within the virtual bubble? I find the best way to do this is to create a shortcut to cmd.exe during sequencing and use this to troubleshoot.
If your process works within the bubble, the solution may be as simple as allowing Local Interaction. Have a read here about that.
Every build takes an extra 3-4 seconds, pausing immediately after the log output prints the following.
[LIFECYCLE]
[org.jetbrains.kotlin.gradle.plugin.KotlinGradleBuildServices] Forcing
System.gc()
Why is it "forcing" this? How do I avoid this and speed up my build?
I've looked into this, and this is a consequence of having Gradle's debug-level logging enabled (eg. gradle --debug assemble).
Run Gradle without debug logging enabled (eg. gradle --info assemble) and this should not occur anymore.
References: libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinGradleBuildServices.kt
Kotlin Gradle plugins calls System.gc before and after a build only when debug logging is enabled (Gradle is run with -d or --debug command line argument).
Users do not normally run Gradle with debug logging enabled because it is extremely noisy and slow, so forcing a GC is a relatively minor issue.
Historically this behaviour was added to test against memory leaks when Gradle daemon is enabled. The idea was to log a difference of used memory before and after a build, run a few builds consequently in a test, and assert that the difference is not exceeding the threshold.
I think calling System.gc should be avoided unless the test KotlinGradleIT#testKotlinOnlyDaemonMemory is running, so I've created an issue at Kotlin bugtracker https://youtrack.jetbrains.com/issue/KT-17960
I have a go lang application which exposes a rest API and logs the information to DB. I am trying to convert the make file to gradle build. Is there any default way similar to maven2gradle plugin or the gradle build file should be written manually? I checked the syntactical differences between gradle and make file but still not clear about passing run time arguments to gradle that is similar to
run:build
./hello -conf=/apps/content/properties/prop.json -v=0 -logDest="FILE" -log_dir="/var/log/logdir"
hello is my executable and others are the runtime arguments. This is my first attempt in migrating make to gradle and I couldnt find any clear documentation. Please help.
As far as I have checked, there is no direct plugin that could do this task. As a workaround, the build execution could be written as seperate tasks in gradle and ordered accordingly. Tasks here would contain setting Go path, installing dependencies and building the application and would be run as command line process in Gradle. Gradle provides support to run command line processes as described in gradle documentation. Hope it helps.