Add "start-stop" goals for the spring-boot-maven-plugin

[danpersa]

In order to run integration tests for a spring boot app, you can use the workaround described in #667.

There is a more detailed article here.

But in some cases, this approach can't be used. One example would be running Cucumber tests.

I have two use cases: The first one uses maven. I want to start my spring-boot app, run some Cucumber tests, then stop the spring-boot app, everything within Maven.

Another use case would be: Having the spring-boot running in my IDE and then run the Cucumber tests also from the IDE, by connecting to the already running app.

I wouldn't like to have the deployment phase hardcoded into the test class as in the example article. This is because (as described in the second use case) if I already have an instance of the application running, I should be able to run my cucumber test directly from my IDE, without starting another instance. I'd like to decouple the deployment step and testing step, as they don't really belong together.

Another reason for having the start-stop approach in the maven plugin is that the method of running the tests described in the article doesn't help me, because Cucumber has to be run using a @RunWith(@Cucumber.class) junit annotation, and the spring boot need the @RunWith(SpringJUnit4ClassRunner.class) annotation. And we can't use two @RunWith annotations on one test class.

I managed to start my spring boot app using maven, like this:

    <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
            <mainClass>boot.Main</mainClass>
            <layout>ZIP</layout>
        </configuration>
        <executions>
            <execution>
                <id>boot-run</id>
                <goals>
                    <goal>run</goal>
                </goals>
                <phase>pre-integration-test</phase>
                <configuration>
                    <fork>true</fork>
                </configuration>
            </execution>
        </executions>
    </plugin>

But after the boot-app is started, the maven build is blocked... As soon as you press Ctrl+C, to stop the tomcat, the build resumes.

[chrylis]

This would definitely be helpful.

[ulich]

i am having exactly the same problem. +1

[snicoll]

From what I can see, forking will be hard (thought not impossible) to support. I've been looking for various ways to do this and the JMX route seems the cleanest. The process that starts the application pass an extra internal property that will register an MBean on the platform mbean server (the mbean server of the current VM). Stop will use that reference to request the context to gracefully shutdown.

This works fine but now we have another problem: since we are invoking a main method, we have no good way to know that the application has started. Surely SpringApplicationRunListener sounds like a good choice but there is no way to register that externally.

[snicoll]

Looks like that using JMX to figure out if the app is running is a good choice as well. Trying that.

[snicoll]

okay so those who are interested to try this out are welcome to use a local build of my gh-2525 branch branch. This should work out-of-the-box as long as forking is not enabled (more on that later). For instance, the following configuration should run your integration tests

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>pre-integration-test</id>
                    <goals>
                        <goal>start</goal>
                    </goals>
                </execution>
                <execution>
                    <id>post-integration-test</id>
                    <goals>
                        <goal>stop</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-failsafe-plugin</artifactId>
            <version>2.18.1</version>
            <executions>
                <execution>
                    <goals>
                        <goal>integration-test</goal>
                        <goal>verify</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

We are using a property to trigger an auto-configuration that registers a MBean who serves two purposes:

1. Tell us if the application is ready (so that your integration tests really start when they have to). This is using the new ApplicationReadyEvent (see Add ApplicationReadyEvent #2638)
2. Stop the application gracefully (basically closing the ApplicationContext).

So what's the problem with fork? The short answer is that I don't know. Since we are using JMX, we can also start the process with the necessary system properties to expose the MbeanServer on a given port and connect to that port to invoke the exact same operations. But for some reasons it does not work while the same code outside of the maven plugin works. I am sure I am missing something.

If you want to try it out (code unpolished), check the gh-2525-remote.

[derickfernando]

Nice, I just got this working. I did have to make SpringApplicationLifecycleAutoConfiguration public because I am not using @EnableAutoConfiguration. I hope you can consider that change. I'll provide more feedback once I implement more integration tests.

[snicoll]

Yes, I intend to reuse that for something else actually (windows service that can start/stop a boot app). Can you share a bit more about your use case? (why you're not using auto-config I mean). Thanks for testing!

[derickfernando]

I'm on an earlier version of spring boot (1.1.8) and I recall needing spring-mvc, which in turn brought in the freemarker dependency. I don't actually have any freemarker templates, so the application would complain that it could not find the template location. I would have to add spring.freemarker.checkTemplateLocation=false to the properties. Instead I removed @EnableAutoConfiguration and used just the AutoConfiguration classes I needed.