Improve support for standalone mode

[georgeharley]

This relates to issue #34

My Spring Boot application uses a backend PostgreSQL database. When the "test" profile is active it uses an embedded H2 database driver rather than the PostgreSQL one. Hence, the H2 driver is a testImplementation dependency.

When the generateOpenApiDocs task is run (either on my laptop or in a CI pipeline) it would be preferable to stick with the embedded H2 rather than requiring some remote PostgreSQL database server. Supplying -Dspring.profiles.active=test in the task's forkProperties makes that possible.

When the generateOpenApiDocs task in introduced into the CI build it always fails to start the Boot application because the H2 driver class can't be found. That's because - being a testImplementation dependency - it is not included in the assembled Spring Boot Jar. In order for the task to work the H2 driver Jar needs to be added to the Spring Boot application's runtime classpath. But because the task runs the Boot application using the java -jar command I can't find a way to accomplish this unless test dependencies are added to the Boot Jar.

To overcome this problem I'd like to propose that the generateOpenApiDocs task runs the Boot application using the java -cp command and the Spring Boot PropertiesLauncher feature.

AFAICT the proposed change would have no impact on existing uses of the plugin but would provide an opportunity to make use of PropertiesLauncher properties to specify additions to the runtime classpath with -Dloader.path=... as one of the forkProperties.

Happy to supply a PR for consideration in order to show the code changes that have made the above suggestion work in my local environment.

[Picazsoo]

Hello @georgeharley , Do you think it would be possible to give some pointers on how you managed to put the H2 database on the classpath with your changes in place? Some snippets of the build.gradle? I have exactly the same scenario as you and have more or less struggled for 2 days trying to get this to work properly without the testImplementation dependency. In my case it is even bit more complex because the build.gradle is implemented in Kotlin DSL but that is my cross to bear 😅 .
I see that there is at miminum one more person commenting on this repository who is trying to solve the same?

I would really appreciate it 😓

[georgeharley]

Hi @Picazsoo, it looks like things have moved on since the code change I submitted was merged. That made use of the plugin's forkProperties extension property which seems to have been removed.

Not having had the opportunity to use this plugin recently, I do not know what provision the new customBootRun parameter makes for using Spring Boot PropertiesLauncher properties or else if it supports some other mechanism for adding entries to the runtime classpath.

[Picazsoo]

HI @georgeharley , thanks a bunch for the quick reply even though it was not exactly what I hoped to hear 😄 .
I will try a couple more things then and will report here definitely if I get it to work somehow.

[Picazsoo]

Ok, so I did not manage to get it to work with the PropertiesLauncher. However I was able to include the H2 jar on the classpath by defining it as a developmentOnly("com.h2database:h2") dependency. This means that the jar is available when running the bootRun task, but does not get packaged into the fat jar.

[PhilippS93]

Hey, any news on the feature? We are also struggling to get it run with a production ready app having database connections etc. Mocking everything is way too much work and it would be good to specify custom sourcesets or classpaths, so in-memory dependencies could be used. Or even start the tool to use test dependencies.

[bnasslahsen]

Hey, there is ongoing task about this.
Please feel free to propose a PR, if you have any enhancements .