Closed wilkinsona closed 6 years ago
spring-data-geode-autoconfigure
has my preference over an unqualified boot
. IMO boot
in informal conversation is fine but it's not correct in official names.
@jxblum I see that you have M1 scheduled for this Thursday (17 May). Can this issue please be addressed before then?
@wilkinsona - Most likely, I will not make my planned May 17th release date given the SD Lovelace release this week. Additionally, I have already addressed this, before.
Let me explain...
The "branding" name is "Spring Boot for Apache Geode and Pivotal GemFire". This is not unlike "Spring Session for Apache Geode and Pivotal GemFire" here, which has a GitHub Repo name of spring-session-data-geode
as well. However, unlike this project, the Artifact names are also spring-session-data-gemfire
& spring-session-data-geode
, respectively.
There is also "Spring Test Framework for Pivotal GemFire and Apache Geode", here.
Even Spring Data GemFire and Spring Data Geode must be branded Spring Data for Pivotal GemFire and Spring Data for Apache Geode, respectively, now.
I don't really have any intentions on changing the GitHub Repo name at this point, but I have already changed the artifact name from, spring-boot-data-geode
and spring-boot-data-gemfire
to geode-spring-boot-starter
and gemfire-spring-boot-starter
as recommended in "What's in a name", which was the resolution for Issue #2. This is evident from Artifactory (here and here).
@wilkinsona - what do you suggest if not org.springframework.boot
?
I am not sure org.springframework.data
is the right place either. E.g. Spring Session for Apache Geode/Pivotal GemFire is under org.springframework.session
, which would make this project inconsistent.
@snicoll - This project concerns a great deal more than just "auto-configuration". Right now, the focus may be on auto-config since it includes the PRs I submitted for Spring Boot proper all those years ago in addition to many other auto-configured features now, beyond my original PRs. But, it will not end there. I have intentions of adding Health Indicators, extensions to Spring Boot Actuator for Apache Geode and Pivotal GemFire and many other great things Boot provides.
what do you suggest if not
org.springframework.boot
?
I consider the code in this repository to be part of Spring Data; it's Spring Data code that integrates with Spring Boot. This is analogous to the Spring Security OAuth auto-configuration that I linked to above; it's Spring Security OAuth code that integrates with Spring Boot. It uses org.springframework.security.oauth.boot
as its group id (a sub-group of the main Security OAuth code which uses org.springframework.security.oauth
) so I'd suggest doing something similar. That could either be just org.springframework.data
or it could be org.springframework.data.boot
or even org.springframework.data.geode.boot
.
I don't really have any intentions on changing the GitHub Repo name at this point
Can you please reconsider? Similar to module names, I think we should keep spring-projects/spring-boot*
for repositories that are part of Spring Boot. GitHub will automatically set up a redirect so previous links to the repository will continue to work.
I consider the code in this repository to be part of Spring Data;
Well, quite frankly, this project could have been done rather naively without SDG (e.g. using GemFire/Geode's API directly), but it makes more sense to leverage all the experience and effort (for example) that went into building SDG to build the extensions and support in Boot for Apache Geode/Pivotal GemFire.
The reason I don't think this belongs in org.springframework.data
is because this project is not a proper SD "module" (Pivotal led or even community-based). It is not part of the SD Release Train, nor should it be. And, like Spring Session for Apache Geode/Pivotal GemFire, it is an "extension", which in my mind, is more than just a starter, samples, or even "auto-configuration".
This is not to say this project does not have ties with Spring Data, in general, just like it has ties with Spring Boot, but it's focus is more related to how "Boot" itself is leveraged to simplify the overall experience when working with either Apache Geode, or Pivotal GemFire, in a Spring context, which is simply not just "data access related", but also includes things such as: configuration, security, session state management (M2), health & monitoring with metrics (M2|M3), among other things yet to come.
Ok. How about org.springframework.geode
or org.springframework.geode.boot
? The key thing, from the Boot team's perspective, is that the group ID must not be or start with org.springframework.boot
.
Can you please reconsider? Similar to module names, I think we should keep spring-projects/spring-boot* for repositories that are part of Spring Boot. GitHub will automatically set up a redirect so previous links to the repository will continue to work.
Regardless of GitHub's ability to setup redirects, my position on this is, the "repo name" (i.e. spring-boot-data-geode
) is consistent with my spring-session-data-geode
and spring-test-data-geode
GH repos, and I would prefer to maintain this pattern since it has already been widely communicated.
Never-the-less, I will think on this more. So far, I have not heard nor seen a name suggestion I like.
@wilkinsona - I just committed a change to regroup this project under org.springframework.data
for the time being. Therefore, it will no longer live under the org.springframework.boot
namespace to appease the Boot team/project.
However, don't mistake this as the final word on this matter; the org.springframework.data
namespace is also not acceptable. It is also not appropriate to base this repo on "geode" alone in the naming conventions (e.g. org.springframework.geode[.*]
) since this equally pertains to Pivotal GemFire.
FWIW I think it's generally preferable if the start of the project name indicates when it might be released. I see the spring-session-data-geode
and spring-session-data-gemfire
are both part of the spring session BOM so naming these the way they are make sense to me.
For the spring-test-data-geode
and spring-boot-data-geode
projects I think the name would be better switched since it's more likely that a Spring Framework and Spring Boot will not drive releases of those projects. My preference for names would be:
spring-data-geode
for the core projectspring-data-geode-boot
for boot supportspring-data-geode-test
for testing supportspring-session-geode
for Spring Session support.If you're no longer planning to support Spring Boot 1.5 (and I probably wouldn't) then I'd be tempted to go further and move spring-data-geode-boot
and spring-data-geode-test
into spring-data-geode
and make them modules. This would mean they'd all get released at the same time which would probably make it easier for users to know which versions work together.
The Geode/Gemfire naming is a little unfortunate since there's no clear name that covers both. I'd probably be tempted to use geode
as the top level name and consider gemfire secondary.
Thanks for the feedback @philwebb .
FWIW I think it's generally preferable if the start of the project name indicates when it might be released.
I don't entirely agree with this logic.
Clearly the Spring Framework affects the release cycles of all down stream projects as does Spring Data and other Spring projects (e.g. Spring Security, Spring Integration, Spring Batch, to name but a few) affects Boot's release cycle, but those clearly are not reflected in "Spring Boot's" name since that would not make sense anyway.
On the contrary, Spring Session does not necessarily drive the release of Spring Session for Apache Geode/Pivotal GemFire (SSDG), either.
Previously, SSDG was part of Spring Session core. However, @rwinch wanted to remove both Pivotal GemFire and MongoDB support out of core so that they could evolve independently, hence the BOM file. While all modules involved line up on the 2.0.x release currently, that won't necessarily always be the case.
Additionally, I am planning a release of SSDG^2 soon, without a version change in Spring Session core, if I must, in order to support the M2 release of SDBD, namely for this, which requires me to make some modifications to SSDG. This means SSDG will be at 2.0.3 (or higher) while Spring Session core remains at 2.0.2, for instance.
SDBD has never included supported for Spring Boot 1.5 since Spring Boot 1.x already includes support for Pivotal GemFire (namely this and this).
By your recommendation, it would be more logical to name Spring Session support for Apache Geode and Pivotal GemFire... spring-data-geode-session
. However, the focal point is not on "data", but on "session management". Similarly, "boot" in spring-boot-data-geode
focuses on Boot capabilities ("for" Apache Geode or Pivotal GemFire).
The Geode/Gemfire naming is a little unfortunate since there's no clear name that covers both. I'd probably be tempted to use geode as the top level name and consider gemfire secondary.
Hence GitHub "Repository" names here, which, quite frankly, is all this argument is boiling down to at the moment.
I have already...
org.springframework.boot
to org.springframework.data
even though I don't like it.geode-spring-boot-starter
and gemfire-spring-boot-starter
, respectively.For consistency sakes, I have named all extension project repos: spring-boot-data-geode
, spring-session-data-geode
and spring-test-data-geode
.
Ironically, as previously stated, the "data" portion of the name is a bit of a misnomer, but because the spring-session-data-geode
module has long (already) existed, I went with it. Otherwise these would have been: spring-boot-geode
, spring-session-geode
and spring-test-geode
, to more closely match spring-data-geode
, which IMO, makes the most sense.
Finally, while these projects are not strictly tied to Spring Boot, Spring Session or even the core Spring Framework, I do plan to closely (as possible) align on releases (not necessarily version numbers) to keep users current. Version numbers have never been aligned anyway, on much of anything, really, for example. It's not like the version of Spring Data for Pivotal GemFire matches either Spring Framework or Pivotal GemFire.
@wilkinsona, @snicoll, @philwebb, @olivergierke -
Please understand, I am not trying to be difficult. I am just trying to be/stay consistent and also promote parity between projects where I think it makes sense to do so. Doing so immediately promotes familiarity, comfort and reassurance on the foundation for which these bits are derived.
In this case, as well as Spring Session and Spring Test, I am trying to bridge the relationship so that it is clear to our users.
If the end result is that I have to rename something as trivial as the GH Repo name, then this will only add to users confusion, IMO. Already, there is some divergence (and growing confusion, or minimally, inconsistency) given the spring-session-data-geode
and spring-session-data-gemfire
artifacts live under the org.springframework.session
namespace (i.e. group ID), while geode-spring-boot-starter
and gemfire-spring-boot-starter
will not live under org.springframework.boot
.
One final thought...
I could, and just maybe would, be willing to rename all repos to:
geode-spring-boot-starter
(for Boot)geode-spring-session-starter
(for Session)goede-spring-test-starter
(for Test)But, I will seriously need to think on this; I am not sold on the "starter" name in these projects. And, unfortunately, this does not solve the group ID/artifact name, inconsistency problem between all these projects now.
Another option (even though I hesitate to mention it) is to move all of these projects out of the spring-projects
org, but that is even worse than repo renaming IMO, since these are (I hope) official Spring projects.
Please understand, I am not trying to be difficult. I am just trying to be/stay consistent and also promote parity between projects where I think it makes sense to do so.
I think consistency is important but if we look at other "test" projects in the portfolio they are named spring-<project>-test
. For example:
spring-batch-test
spring-integration-test
spring-boot-test
spring-data-hadoop-test
spring-integration-test
spring-security-test
spring-kafka-test
Likewise, technology specific integration also follows the same pattern:
spring-integration-webflux
spring-clould-task-batch
spring-restdocs-mockmvc
given the spring-session-data-geode and spring-session-data-gemfire artifacts live under the org.springframework.session namespace
This also makes sense to me. I expect the spring-<project>
to own the package that it contains. So I'd expect spring-batch
to own org.springframework.batch
, spring-boot
to own org.springframework.boot
etc.
In the geode case I would expect spring-session-geode
to contain the org.springframework.session.geode
package. I'd expect spring-data-geode-boot
to contain org.springframework.data.geode.boot
.
Another option (even though I hesitate to mention it) is to move all of these projects out of the spring-projects org, but that is even worse than repo renaming IMO, since these are (I hope) official Spring projects.
I'd prefer that that didn't happen. I think it will add to the confusion. I consider these to be "spring" projects providing geode integration, rather than "geode" projects providing spring integration.
The key difference between the projects you cited (e.g. Spring Batch, Spring Integration, Spring Security, Spring for Apache Hadoop, Spring for Apache Kafka, etc) and SDG^2, is that those Spring projects are all multi-module projects; SDG^2 is not.
Even spring-data-gemfire
and spring-data-geode
are separate spring-project
repos, and for good reason. Spring Data for Apache Geode is OSS, based on the Apache 2 License, while Spring Data for Pivotal GemFire is not. While spring-data-geode
is completely resolvable from Maven Central, the other is not. 1 has "Pivotal Legal" implications (e.g. branding, this and that), the other, Apache. #ugh
So, rather than duplicate the test framework supporting code, I felt it was better to separate the bits out, hence the spring-test-data-geode
project.
1 thought I had was to completely get rid of the spring-data-gemfire
repo and just make spring-data-gemfire
a module of the spring-data-geode
repo, much like the spring-boot-data-geode/gemfire
and spring-session-data-geode/gemfire
modules in their respective projects/repos, now.
However, there is a lot of "history" in the spring-data-gemfire
repo (branches, tags, build infrastructure in spring-data-build
, etc, etc). And, it is an interesting proposition given the above making both the Spring Boot/Spring Session Apache Geode/Pivotal GemFire projects a rather interesting conundrum.
As for packaging, well, technically Session Session for Apache Geode is spring-session-data-geode
(not spring-session-geode
) and therefore, the packaging is org.springframework.session.data.gemfire
. Yes, ..data.gemfire
, which was not arbitrary, either.
First, Spring Session was original based on Pivotal GemFire before there was a spring-data-geode
repo/project. To be consistent with package naming, it followed SDG, therefore, it is org.springframework.session.data.gemfire
, even for the spring-session-data-geode
module in the repo. This must not be changed, as explained here.
The "data" part, which GemFire, MongoDB and Redis followed (notice the module names, and now the packaging), as opposed to Hazelcast (module and package) was to signify that GemFire, MongoDB and Redis were proper Spring Data modules and not "community" modules.
Anyway, none of this is meant to justify what is, but merely to explain what has been and why this is not easy to resolve.
Again, at this point, it really only boils down to the repo name. I have already resolved the groupId and artifact name. I definitely won't budge on project branding (i.e. "Spring Boot for", "Session Session for", "Spring Data for", and so on).
Gentlemen (@philwebb, @wilkinsona, @snicoll, @olivergierke, @dussab)-
I had a discussion with @olivergierke about the Spring Boot for Apache Geode & Pivotal GemFire project coordinates, naming conventions and repo.
The following actions have been taken...
org.springframework.geode
.geode-spring-boot
geode-spring-boot-autoconfigure
geode-spring-boot-starter
gemfire-spring-boot-starter
The intent is to mimic the structure of Spring Boot as closely as possible. Hopefully the names clearly communicate the intent.
The project will be branded as "Spring Boot for Apache Geode" and "Spring Boot for Pivotal GemFire", respectively.
Finally, for the time being, I have decide not to rename the Repository. This may change down the road, but for now it will stay as is.
If you have anymore questions or concerns, feel free to reopen this issue.
Thank you, @jxblum
Thanks for the renames, John. Much appreciated.
First, I have changed groupId to
org.springframework.geode
.
Excellent.
Second, I have named the following modules:
geode-spring-boot
geode-spring-boot-autoconfigure
geode-spring-boot-starter
gemfire-spring-boot-starter
Given that all three modules are Spring projects, I think it would be better if the module names followed the convention of beginning with spring-
. Perhaps the following:
spring-geode-spring-boot
spring-geode-spring-boot-autoconfigure
spring-geode-spring-boot-starter
spring-gemfire-spring-boot-starter
In addition to being consistent with other module names across the Spring portfolio, the spring-
prefix also lessens the chance of a clash with another non-Spring project that does something with Geode or GemFire and Spring Boot.
Finally, for the time being, I have decide not to rename the Repository.
In the interests of consistency, can you please reconsider renaming the repository as well? I think it's inconsistent at the moment for reasons similar to those already covered above by Phil. If we expand Phil's reasoning to repository names, there's a consistent pattern of spring-<project>-<qualifier>
:
spring-data-build
spring-data-commons
spring-integration
spring-integration-aws
spring-security
spring-security-oauth
spring-session
spring-session-data-gemfire
spring-session-data-geode
I include the last three in particular as I think they get to the crux of the matter. I think the naming of spring-session
, spring-session-data-gemfire
, and spring-session-data-geode
is consistent with the general approach as the -data-geode
and data-gemfire
modules are part of the Spring Session umbrella as shown by their inclusion in Spring Session's bom. In other words, the name is qualifying that this repository is the Data GemFire and Data Geode parts of Spring Session.
By contrast I think both this repository (spring-boot-data-geode
) and spring-test-data-geode
are not consistent with the general approach. They're not the same as the spring-session-data-gemfire
and spring-session-data-geode
projects as they're not part of Spring Boot or Spring Framework's testing support. Rather, they're part of the Spring (Data) Geode support that integrates with Spring Boot and Spring Framework's testing support. As such I think it would be more consistent if they were named something like spring-data-geode-spring-boot
and spring-data-geode-test
or perhaps even spring-geode-spring-boot
and spring-geode-test
. Dropping data
would, perhaps, align better with the org.springframework.geode
group id.
Can you please update this project to align with the recommendations in Boot's documentation? Rather than being called
spring-boot-data-geode
,spring-data-geode-boot
or similar would be more appropriate and would be consistent with other projects that are in a similar position. The group ID should also be something other thanorg.springframework.boot
.