Projects that use a single Spring Cloud Zookeeper starter do not compile as the starter does not meet the requirement of depending on spring-boot-starter

[kdvolder]

To reproduce you can use STS (or use initializer with whatever IDE or CLI tools that you prefer) and create a new project using the "New Spring Starter" wizard.

Select these two dependencies:

• cloud-starter-zookeeper-config[Zookeeper Configuration]
• session[Session]

When the project is created it seems to have problems with its classpath. Types such as SpringBootApplication and SpringApplication cannot be resolved in the main application class's source code.

I get the same error when running mvn package on the commandline so I assume this is an actual problem with the generated project rather than a bug in STS or Eclipse.

Problem is reproducible for me on both start.spring.io as well as start-development.spring.io.

[kdvolder]

Attaching the generated project as it may help diagnose the issue. I'm think the problem seems to be that, althoug the types that cannot be resolved are actually on the classpath, they are only test-scoped and so do not resolve from the main class.

demo.zip

[wilkinsona]

Thanks, Kris. This is a bug in Spring Cloud Zookeeper as its starters do not meet this requirement:

Either way, your starter must reference the core Spring Boot starter (spring-boot-starter) directly or indirectly (i.e. no need to add it if your starter relies on another starter). If a project is created with only your custom starter, Spring Boot’s core features will be honoured by the presence of the core starter.

I've opened spring-cloud/spring-cloud-zookeeper#230. We can use this issue to either disable the broken starters or see if we can work around the problem by leaving spring-boot-starter in place.

[kdvolder]

These other cross-selections with 'session' also look broken:

• data-rest-hal[Rest Repositories HAL Browser] + session[Session]
• cloud-starter-consul-config[Consul Configuration] + session[Session]

[wilkinsona]

I think we can take Session out of the picture as you can use the dependencies without involving Session and still have the same problem.

data-rest-hal[Rest Repositories HAL Browser]

This is an error in our metadata as we haven't marked data-rest-hal as starter: false. I've opened #195.

cloud-starter-consul-config[Consul Configuration]

This is caused by cloud-starter-consul-config not depending on spring-boot-starter.

[kdvolder]

I think we can take Session out of the picture...

I'm sure you are right, I am just reporting what I found and these 'problems' come out of some testing I was doing specifically trying out all combinations of 'session' + X. And those were simply the cases where my test is failing because the resulting project doesn't compile.

Whether or not this problem comes from session, from X, or from the combination of X + session... from my point of view, it could be either. All I know is that I observed a problem when both X and session are present.

If it is true this is not a 'cross selection' specific problem but something attributable to just one starter / dependency, then II am surprised you don't have tests that catch these problems. I can understand that trying all possible combinations in a test is infeasible (I was trying something like that actually in STS, but the number of combinations is just too great). Just testing each starter in isolation (and check whether it produces a project that builds without errors) seems like it would be not that hard, and would have caught these problems.

[wilkinsona]

I opened #194 yesterday to look at adding some tests. While writing the tests is not that hard (we already have some that verify that the project builds successfully for all the combinations of Boot version, packaging, and build system that we support), not making the build take too long is hard. We'll have to see what we can do without slowing things down too much such that it then takes too long to get changes into production.

[kdvolder]

We'll have to see what we can do without slowing things down too much such that it then takes too long to get changes into production.

Yeah, I understand, that problem is only too familiar :-). You'll have to decide if catching those kinds of bugs in the future is worth the extra build times or not, which is not an obvious yes or no question.