I have a situation where i need to run multiple gradle tasks, in parallel.
For example: I am using gretty(org.akhikhl.gretty:gretty:+) plugin for running embedded webserivce, which runs my service.
So I ran, gradle jettyStart.
Now I have some scripts that need to be ran while the webservice is running, means the gradle jettyRun has run.
I have a migration script written in groovy, which I can call using gradle runScript <script_name>
but since this scripts calls the webservice apis, i need the service to be up. But the case is, once i keep running gradle jettyRun, i cant run gradle runScript until unless i stop the other tasks.
How can I resolve this issue.
You can use start (e.g. appStart) family of gretty tasks which starts jetty in background and exits. Then you can use any other gradle task on this project. To stop jetty you can use stop-tasks
You can get list of available tasks from documentation:
http://akhikhl.github.io/gretty-doc/Gretty-tasks.html
Related
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 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 have some integration tests that use Selenium and the HtmlUnitDriver to verify my web app behaves correctly from the browser. In IntelliJ, I'm able to run ./gradlew bootRun to start my embedded web server, and then run my Selenium tests manually.
The tests run as expected.
However, I'm wondering what the best strategy is to run these in an automated fashion on my CI Server (TeamCity in this case). Simply running bootRun doesn't quite work since the task runs until it gets terminated.
Should I create a script that runs bootRun, and then I can terminate gradle somehow after the tests complete? I'd also like to use my application.properties file I have in src/test/resources instead of src/main/resources which bootRun uses normally.
When I try to run build with gradle with the -t flag:
./gradlew clean build -x test -t
I get prompt line:
Waiting for changes to input files of tasks... (ctrl-d to exit)
but when I try it with bootRun command it doesn't work/appear:
./gradlew clean bootRun -t
Does it work with Spring Boot? (I know about Spring dev tools plugin - 1.3 is not released yet)
andy-wilkinson is correct in his answer : gradle bootRun never completes because some applications run indefinitely. Its well documented in this issue in the grails project.
I've found a way to force bootRun to live reload the application from the command line. The key items here are the gradle daemon and the spring-boot-devtools package.
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.
It depends on the nature of your Spring Boot application. If you app typically runs and then exits then continuous build will work. However if your app typically stays alive indefinitely, for example because it's a web app that handles HTTP requests, then it won't work. In the latter case the bootRun task never completes so Gradle doesn't know that it's time to start watching for changes.