Polish Pivotal GemFire starter and sample.

[jxblum]

Closes gh-5439.

[snicoll]

Merged with a polish commit. Thanks!

[wilkinsona]

Reopening as we need to get rid of the dependency management for Spring Shell

[wilkinsona]

Reopening once again. The dependency management for Gemfire needs to be reinstated. We shouldn't rely on the transitive dependency pulling in the right version as it's then possible that another dependency would down or upgrade the version to one that isn't supported.

[jxblum]

@wilkinsona

We shouldn't rely on the transitive dependency pulling in the right version as it's then possible that another dependency would down or upgrade the version to one that isn't supported.

Understood; that makes sense. However, I fail to see any reason why an explicit dependency declaration is needed in the spring-boot-starter-data-gemfire/pom.xml at all if...

1. GemFire is appropriately managed by Spring Boot in the spring-boot-dependencies/pom.xml, as it was here and here.
2. And, regardless if Spring Data GemFire (using the starter), or another Spring Boot Starter (e.g. integration) or even say, an application dependency, pulls in GemFire transitively, as long as the starter or the application POM, (indirectly) inherits from the spring-boot-dependencies/pom.xml appropriately, such as through the spring-boot-parent (for the spring-boot-starter-data-gemfire, the hierarchy is spring-boot-starters -> spring-boot-parent -> spring-boot-dependencies), then the explicit GemFire dependency declaration should not be needed, yet the right version of GemFire for Spring Boot, and specifically SDG, or any other module (e.g. integration) requiring GemFire, will be used.

I would also caution that Spring Data GemFire has a very specific requirement on the version of GemFire used. It was both a mistake and naive that SDG supported multiple simultaneous versions of GemFire at once in the past, something I have corrected since then.

So, it is absolutely paramount that the gemfire.version managed by Spring Boot is kept in-sync with the version that Spring Data GemFire expects, which is determined by the Spring Data Release Train version pulled in by Spring Boot (e.g. for Hopper, SDG 1.8 uses GemFire 8.2). Of course, this is manageable, but will require a bit of extra care and attention.

[wilkinsona]

However, I fail to see any reason why an explicit dependency declaration is needed in the spring-boot-starter-data-gemfire/pom.xml at all

You've linked to the starter from M1. As things stand, there's no such dependency in the starter.

I would also caution that Spring Data GemFire has a very specific requirement on the version of GemFire used.

Thanks. We understand that. It's no different to several other dependencies for which we also provide dependency management.

[jxblum]

As things stand, there's no such dependency in the starter.

I saw that, actually (I only referenced M1 assuming we wanted tor revert back to how it was).

So is there anything that needs to be done with this PR, or that I should redo? I suppose not since it is now closed.

[wilkinsona]

Nothing more needs to be done. I took care of the last two niggles in the two commits that are referenced above (e0f9da5 and b4ea90c)

[jxblum]

Thanks @wilkinsona!