I am building a Spring Boot REST API application and using Kotlin as the language.
For the development I am using IntellJ as the IDE.
The project structure looks as follows:
Is there a way to watch changes in the folder src to trigger the gradle task ./gradlew test after files have been changed?
You can use Gradle's support for continuous builds:
./gradlew test --continuous
This will cause Gradle to watch the filesystem for changes and execute the test task and any tasks upon which it depends whenever a change is detected.
You can right click the gradle task and set it to be done e.g. after each build.
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.
What is the difference between "gradle build" and "gradle bootJar"? Why would I use bootJar if I can still create the artifact using build?
build is a lifecycle task contributed by the Base Plugin. It is
Intended to build everything, including running all tests, producing the production artifacts and generating documentation. You will probably rarely attach concrete tasks directly to build as assemble and check are typically more appropriate.
bootJar on the other hand is a specific task added by Spring Boot Gradle plugin that, when the java plugin is present, attaches itself to the assemble lifecycle task.
The assemble task is automatically configured to depend upon the bootJar task so running assemble (or build) will also run the bootJar task.
(Packaging Executable Jars)
You want to use bootJar if you're only interested in building the executable jar and not interested in executing tests, code coverage, static code analysis or whatever is attached to the check lifecycle task.
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 currently trying to migrate a project from Gradle 3.5 to the latest Gradle version 4.9. and I'm running into the problem, that Gradle doesn't find the resources that it needs to execute the junit tests. These resources are generated upfront and contain some configuration files and referential data.
The project uses a combination of npm and Gradle to compile. Usually we run a npm script which executes a couple of tasks sequentially using run-s, e.g. webpack builds to generate some static resources. At the end we compile everything together using Gradle. The last Gradle task also executes the junit tests. This step fails and makes the whole build fail. The Gradle runner complains that some resources are not found, although the get properly copied to the right places.
When I execute ./gradlew test --rerun-tasks (Yes, we use the wrapper, which has been properly upgraded, too) right after the last Gradle build step failed, it executed the junit tests successfully.
I know, that the directory structure changed in Gradle 4.x, but this doesn't seem to be the problem.
My suspicion is, that it has something to do with how we normally run the whole build process. Something in the combination with npm.
I am using gradle lint plugin in my Android project on CI Server. But sometimes I want to run android lint only on custom files, just like gradle Copy Task include and exclude to defined task scope in my gradle task.
In Android Studio, inspection can defined these behavior. But in my case, it is gradle task run on CI Server without UI interaction.
I don't think the Gradle Plugin is capeable of that. However you can also run lint on it's own.
lint [flags] <project directory>
You can get all of the options with:
lint --help
The executable is located in $ANDROID_HOME/tools/
More information here.