On one of our projects, we have the need for integration tests to be run with rspec. This means we have to bootRun in a separate terminal / process, run the tests, then go back and stop the bootRun. It would be hugely beneficial to have a daemon option that stops once the gradle script is completed; this way we could bootRun with daemon, run tests, finish (spinning down the bootRun'd server) all in one gradle task.
Comment From: snicoll
We have an out-of-the-box support for that in Maven in the 1.3 line (see working with integration tests).
I have no idea if Gradle does support pre/post integration test hook points but if it does we can probably cook something. I am sure @wilkinsona knows more.
Comment From: wilkinsona
Sadly, this is one of those things that Gradle seems to go out of its way to make more difficult than it needs to be. The JavaExec task (which BootRun subclasses) doesn't support running as a daemon. Such functionality was requested almost 5 years ago but, despite it being the third-most voted for issue, it's yet to be implemented. JavaExec is a thin adapter on top of JavaExecHandlerBuilder which could, perhaps, be reused, however it's in an internal package so it's off limits.
A few options:
1. Submit a Gradle PR to add support for running as a daemon. This requires the PR to be accepted and would cut off anyone who wants to use an older version of Gradle.
2. Add a new task designed for integration testing that runs the app in the background. We might be able to wrap BootRun in an Executor to achieve this.
3. Rewrite BootRun so that it no longer extends JavaExec but has support for running as a daemon
Of these, 2 feels like the one that will yield the quickest results as 1 is largely out of our control and 3 either involves a breaking API change or a lot of reinventing the wheel.
Comment From: octavianlaies
We have a similar use case but I can't figure out how we would use the start/stop goals. We are developing a Java client library for our spring-boot microservice but it's a separate maven module. Our maven structure is something like this:
- parent
-- my-microservice
-- my-microservice-client
So in the pre-integration test phase of my-microservice-client we would need to use the my-microservice.jar file that was built earlier. I can easily download that dependency but the plugin requires a classesDirectory parameter and I can't figure out a way to run it from the jarfile. Even if I use a mechanism that would add the jarfile to the classpath it still wouldn't work because the dependencies are in the lib subfolder and only the Spring Boot launcher knows how to run that as a boot service. maven-exec would be an alternative if it could do external processes and manage their lifecycle.
Comment From: jeanbza
@wilkinsona @snicoll Thanks for the replies, apologies for not seeing this sooner. I'll poke around and see what the world looks like for this kind of thing.
Comment From: wilkinsona
The relevant Gradle issue is now this one: https://github.com/gradle/gradle/issues/1367.
Comment From: MariiaZaitcevaNYT
spring-projects/spring-boot#9884 "Rewrite BootRun so that it no longer extends JavaExec" was finished, this should unblock this one
Comment From: wilkinsona
@MariiaZaitcevaNYT BootRun is still a JavaExec sub-class and will remain so. It was rewritten during the 2.0 milestones so that it was not, but the change caused more problems than it solved so it was reverted.
Comment From: cebaa
@wilkinsona Is this - i.e. running gradle build --continuous in one terminal and gradle bootRun in another - still the best workaround for this issue?
I don't see details in https://github.com/spring-projects/spring-boot/issues/9884 regarding what the issues were - is this that will potentially be revisited or are there any alternative ways being explored?
Comment From: wilkinsona
@cebaa That really depends on what you're trying to achieve. The answer on Stack Overflow is only really relevant in the context of DevTools. If you're looking for something more akin to the Maven plugin's stop and start goals (which is what comes to my mind when I think of a daemon option), it won't really help you.
This issue remains open so it will be revisited at some point in the future. We don't have any concrete plans at the moment though.