Consider reinstating auto-configuration for Spring Session Mongo DB

[wilkinsona]

This commit could, largely, be reverted. The project now lives on separately. A 2.0.0.M1 release is available from repo.spring.io.

[vpavic]

👍

Project's coordinates have changes (it's spring-session-data-mongodb now, instead of spring-session-data-mongo) and it will require a separate version property in dependency management.

However note that we're strongly considering splitting the Spring Session into modules by session repository implementation (update: see spring-projects/spring-session#806), meaning there will be a spring-session-core artifact while existing Redis, JDBC and Hazelcast artifacts (which are basically BOMs currently) will include the respective session repository implementation and related code.

This will require some changes in Boot's auto-config support for Spring Session so it might be a good idea to handle that change before reverting old MongoDB related code.

/cc @rwinch

[wilkinsona]

@rwinch Can you please help us to understand the motivation for splitting out the Mongo DB support from Spring Session? We're curious about the benefits of splitting things up. Is jumping straight in and supporting it again in Spring Boot the right thing for us to do? Put another way, is it going to be maintained in the long term?

[vpavic]

@wilkinsona The background of these changes were explained in depth in spring-projects/spring-session#768 and https://spring.io/blog/2017/05/11/spring-session-2-0-0-m1-released.

The new spring-session-data-mongodb should also be considered officially supported since it was picked up by @gregturn.

[rwinch]

@wilkinsona I think this was explained quite well by @vpavic

One thing to add is I view Spring Session as shaping to be a little like Spring Data team in that different data stores are owned by different teams. The data stores supported by the Spring Team are officially supported by their respective team and those that are not are community supported.

[gregturn]

@wilkinsona I'm all in favor of adding the managed version to Boot's listing of versions, yet holding off autoconfiguration until the dust settles. For example, I know Rob is working on core changes that haven't been picked up yet in Spring Session MongoDB. So if he and @vpavic need to hammer out some artifact details, by all means let them proceed.

But in the meantime, let's not hold back people that want access to this officially supported product from picking up the right version a la Boot.

Again, this is akin to Spring Data, so I didn't realize there was yet controversy over divvying up into separate repos.

[wilkinsona]

Thank you, @vpavic and @rwinch

But in the meantime, let's not hold back people that want access to this officially supported product from picking up the right version a la Boot.

Generally speaking, we only provide dependency management for something that Boot's using and won't just provide a version for something.

I've subscribed to spring-projects/spring-session#806. Let's wait for that to land before we tackle this.

[snicoll]

let's not hold back people that want access to this officially supported product from picking up the right version a la Boot.

@rwinch if that module is officially supported, why isn't it part of the bom? We shouldn't have a separate entry in dependency management for this IMO

[gregturn]

@snicoll BOM? Are you referring to the Spring IO platform BOM or to a Spring Session BOM that doesn't exist at this stage?

[snicoll]

There is a reference to a bom in the description of spring-projects/spring-session#806