Provide more flexible strategy for loading specific `@Configuration`'s for integration testing

[jgrandja]

If we configure the following authorizationServer() @Bean for integration testing purposes:

@Bean
public CommonsExecWebServerFactoryBean authorizationServer() {
	return CommonsExecWebServerFactoryBean.builder()
		.mainClass(TestAuthorizationServerApplication.class.getName())
		.classpath((classpath) -> classpath
			.entries(MavenClasspathEntry.springBootStarter("oauth2-authorization-server"))
			.recursive(TestAuthorizationServerApplication.class)
		);
}

And we also need to load specific @Configuration's for the integration tests, then we need to ensure they are placed in the specific package testjars.authorizationserver. The testjars package is fixed and the authorizationserver sub-package corresponds to the @Bean name.

If we have 10x different integration tests that have their own specific @Configuration's then it appears we would also need to define 10x authorizationServer @Bean?

I wonder if we can come up with a more flexible strategy for loading specific @Configuration's and reusing the same authorizationServer() @Bean?

[rwinch]

This is a great suggestion and I think that we could/should use it internally for things like the defaultSpringBootApplicationMain().

Would it work if we added support for something like:

.classpath((classpath) -> classpath
	// ...
	.classes(Config1.class,Config2.class, ...)
);

NOTE Adding the configurations to the class path does not mean that they will be used by Spring. For that to work, you need to ensure that there is something loading the configurations too (e.g. a @ComponentScan that picks up the configurations).