Skip to content

Add auto-configuration support for Spring Data Geode Repositories. #6952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

jxblum
Copy link
Contributor

@jxblum jxblum commented Sep 19, 2016

This PR replaces PR #6224, which added auto-configuration support for Spring Data GemFire Repositories. However, SD GemFire depends on Pivotal GemFire, which is not Open Source (and thus NOT freely available in Maven Central) and binds the user to legal agreements that a user must accept and sign before Pivotal will allow a user to download and use Pivotal GemFire.

As such, Spring Boot cannot directly (or indirectly with Spring Data GemFire) include support for Pivotal GemFire OOTB, therefore, this PR replaces PR #6224 in order to replace Spring Data GemFire, and subsequently Pivotal GemFire, with Spring Data Geode and Apache Geode, which are both *Open Source * and are both freely available in Maven Central.

It is widely known that Apache Geode is the successor and predecessor of Pivotal GemFire. Meaning, Apache Geode is based on Pivotal GemFire 8.2.0's codebase and was released to the Apache Software Foundation (ASF) by Pivotal in April of 2015 as an incubating project. Additionally, the upcoming Pivotal GemFire 9.0 release will be rebased on Apache Geode (~1.0.0-incubating-GA) prior to release. So, in that sense, it is both a successor (first) and predecessor (second).

However, this PR SHOULD NOT BE MERGED until @philwebb and I have had a chance to discuss the future direction of Spring Boot's support for (either/both) Pivotal GemFire and Apache Geode.

<artifactId>jcl-over-slf4j</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate why you removed the exclusion?

Copy link
Contributor Author

@jxblum jxblum Sep 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake... fixing now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

@jxblum jxblum force-pushed the autoconfigure-repo-data-geode branch 2 times, most recently from 962cb6c to b151f7c Compare September 20, 2016 18:29
@philwebb philwebb added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Oct 19, 2016
@jxblum jxblum force-pushed the autoconfigure-repo-data-geode branch from b151f7c to 05c8022 Compare November 3, 2016 08:04
jxblum added a commit to jxblum/spring-boot that referenced this pull request Nov 3, 2016
@jxblum jxblum force-pushed the autoconfigure-repo-data-geode branch from 05c8022 to 5a4d36d Compare November 3, 2016 08:08
jxblum added a commit to jxblum/spring-boot that referenced this pull request Nov 3, 2016
@jxblum
Copy link
Contributor Author

jxblum commented Nov 3, 2016

@snicoll, @philwebb & Spring Boot team-

This PR to add auto-configuration support for Spring Data Geode Repositories has been updated with the latest release of Spring Data Geode 1.0.0.INCUBATING-RELEASE (here), which is now based on Apache Geode 1.0.0-incubating GA release (here; more details here).

If you have questions, let me know.

Thanks!

@jxblum jxblum force-pushed the autoconfigure-repo-data-geode branch from 5a4d36d to 565fbca Compare November 4, 2016 05:49
@philwebb
Copy link
Member

philwebb commented Nov 4, 2016

Thanks but I don't think we should consider merging this until there's a non incubating release of Geode.

@philwebb philwebb added the status: on-hold We can't start working on this issue yet label Nov 4, 2016
@jxblum
Copy link
Contributor Author

jxblum commented Nov 5, 2016

@philwebb - Why? What is the concern?

@philwebb
Copy link
Member

@jxblum Primarily stability between releases. I'm assuming that whilst the project is incubating there's no commitment to compatibility with previous releases. It does appear that the graduation vote was successful so hopefully we'll get a non incubating release soon.

@philwebb philwebb added the for: team-attention An issue we'd like other members of the team to review label Nov 15, 2016
@jxblum
Copy link
Contributor Author

jxblum commented Nov 15, 2016

@philwebb - Well, there are no previous releases, hence Apache Geode 1.0.0-incubating; this is the first, "official" GA release. While there were no such guarantees between "Milestone" releases (i.e. M[1-3]), which is what they have been up to this point (see here), going forward, Geode must ensure a level of compatibility between versions since GemFire 9 will be based on Apache Geode 1.0.0-incubating. Additionally, as I told @dussab, it is not like once Apache Geode graduates there is going to be a 1.0.0 (or what we call 1.0.0.RELEASE, as in "non-incubating" version). The version will be 1.1.0 or later, without the "incubating" version qualifier. Finally, for the most part, the API changes introduced are largely shielded from users by SDG, so there is very little to no impact on users when using SDG and SDG's APIs/Functionality. Can discuss/explain more Thursday. Thanks.

@jxblum
Copy link
Contributor Author

jxblum commented Nov 15, 2016

@philwebb - One more point... I just reviewed the code changes in my pertinent Spring Boot PRs (this PR (#6952) and PR #6967) and the dependencies on and usage of Apache Geode classes in Spring Boot is very minimal, nothing that should affect backwards compatibility for Spring Boot users.

@wilkinsona
Copy link
Member

As discussed, this code is going to be delivered in a separate module outside of Spring Boot.

@wilkinsona wilkinsona closed this Nov 22, 2016
@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed for: team-attention An issue we'd like other members of the team to review status: on-hold We can't start working on this issue yet labels Nov 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants