As many of you already know, the Gradle daemon can speed considerably Gradle.
I have a multimodule build and using Gradle wrapper.
When running from the command line:
gradlew :MyModule:test
Gradle spends some seconds analyzing my modules. If I launch again, it consumes the valuable time again and again.
I'm using Gradle 1.12.
I've tried to set add this line:
org.gradle.daemon=true
to local.properties, but no luck.
I don't know if I have to change myHome/.gradle/gradle.properties or some other file.
org.gradle.daemon=true has to be added to gradle.properties, not local.properties.
Related
I have a gradle project where I've added the archunit-junit5 dependency and written some test classes with #ArchTests. These get picked up by IntelliJ.
How do I get gradle to execute them?
I've found the com.societegenerale.commons:arch-unit-gradle-plugin but that seems to need configuration in the gradle file.
I just want gradle to pick up the tests I already have in the test/java directory.
Gradle should pick up #ArchTests with archunit-junit5 if you useJUnitPlatform().
https://github.com/TNG/ArchUnit-Examples/tree/main/example-junit5 shows a quite minimal working example.
In SpringBoot application, what is the difference between
type ./gradlew and execute main method in **App.java?
I'm in chaos. I thought execute main method contains ./gradlew task. But it seems like doesn't contains that.
Because the result was different when I execute both task.
the w in gradlew is for wrapper as stated in gradle official website:
The recommended way to execute any Gradle build is with the help of the Gradle Wrapper (in short just “Wrapper”). The Wrapper is a script that invokes a declared version of Gradle, downloading it beforehand if necessary. As a result, developers can get up and running with a Gradle project quickly without having to follow manual installation processes saving your company time and money.
It should be possible to have a Spring Boot app continuously build (i.e. hot reload) by running gradle build --continuous and gradle bootRun in sequence.
I'm trying to modify the bootRun task in the gradle build file so that it calls the build task in continuous mode, but I can't seem to add arguments to it.
bootRun.dependsOn build
How can I get that build to run continuously?
This question and the corresponding answers are pretty interesting.
Short answer : you can't have the bootRun task running with the continuous option (if your app stays alive indefinitely)
But there is a hack by Stefan Crain :
To get it to live reload you need to have 2 terminals open.
gradle build --continuous
build --continuous will keep satisfying the initial build request until stopped
gradle build --continuous --quiet & 2>1 >/dev/null runs in the background, but you would miss the important build warnings/errors.
gradle --stop to stop watching.
gradle bootRun
bootrun starts with spring-boot-devtools on classpath, which will detect changes and restart application.
I think it's what you are looking for.
Another option to Toyonos solution seems to work for me, run the commands in two separate terminals to maintain the build warning messages:
gradle bootRun
gradle build --continuous
I'm new to Gradle. I see that Gradle lib already has a file 'groovy-all-2.4.12.jar' in lib folder and I don't seem to have any issues with tasks and or dependencies. Still, is it necessary in any scenario to install Groovy on my system on top of it?
Reason why I ask is that, when I do 'gradle -v' in command prompt, I see few warnings. Please see attached screenshot.
With gradle it is strongly recommended to use the Gradle wrapper committed into the project you are building instead of a system-wide gradle distribution (that is gradlew and not gralde). This guarantees the matching version of Gradle your project has been tested with.
With the Gradle wrapper you do not need to care about any dependencies that Grade itself needs, such as groovy and you really do not need to install anything of Gradle at all as the wrapper in your project will download all it needs on the first run.
The minimum setup for the Gradle wrapper is:
/gradlew - unix shell script
/gradlew.bat - windows batch script
/gradle/wrapper/gradle-wrapper.properties -- the properties file defining the version
/gradle/wrapper/gradle-wrapper.jar -- the minimal jar (50Kb) that takes care about the rest
The above files must be committed into your project and this is what 99% of all gradle projects do. You will find further details here https://docs.gradle.org/current/userguide/gradle_wrapper.html
I just converted my Maven project to a gradle project. It was a multi project structure:
master-project
pom.xml
---->project1
-------->pom.xml
---->project2
-------->pom.xml
---->project3
-------->pom.xml
I ran a gradle init on it and have this structure now:
master-project
build.gradle
---->project1
-------->build.gradle
---->project2
-------->build.gradle
---->project3
-------->build.gradle
Everything builds fine, and I have been able to get some things done with that I couldn't figure out how to do with Maven, so that's great. Next step was to integrate that into the IDE since the Maven Dependencies are gone since I have removed the pom.xml files.
However the project isn't recognized as a gradle project - and I am not sure how to change that?
In Eclipse Mars it's still recognized as a Maven build, not gradle....
Thanks in advance.
EDIT: I reimported the projects which enabled the plugin for Eclipse. Now I am having weird behavior.
The build works from the command line, however when attempting the same execution from within Eclipse, it fails trying to copy the file dependencies.
For example:
Couldn't copy dependency jakarta-regexp-1.4.jar
java.nio.file.NoSuchFileException: C:\Users\user.m2\repository\jakarta-regexp\jakarta-regexp\1.4\jakarta-regexp-1.4.jar -> build\jfx\app\lib\jakarta-regexp-1.4.jar
I haven't changed the repo from maven yet - just changed the build scripts. This is running from the master project. So I am confused as to why the script would work from the commandline but not from within eclipse.
EDIT 2: Turns out this behavior is also present when running from the command line when the --daemon flag is set. Is there anyway to run the tasks without the daemon in Buildship? Or perhaps a way to fix this issue when the --daemon flag is enabled?
Thanks.
The issue with the build was that there is a leak in the JDK when bundling the JRE with the native app. This only happens when running with the --daemon flag (which all IDEs user). Therefore until this is fixed you will need to run gradle --stop and then run the clean.
The plug in I am using is no longer running the native task when running with --daemon.