Update project coordinates to make the relationship with Spring Boot clear about spring-boot-data-geode HOT 17 CLOSED

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

@jxblum I see that you have M1 scheduled for this Thursday (17 May). Can this issue please be addressed before then?

from spring-boot-data-geode.

@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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

@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.

from spring-boot-data-geode.

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 project
• spring-data-geode-boot for boot support
• spring-data-geode-test for testing support
• spring-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.

from spring-boot-data-geode.

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...

1. Changed the group ID from org.springframework.boot to org.springframework.data even though I don't like it.
2. Changed the artifact ID to geode-spring-boot-starter and gemfire-spring-boot-starter, respectively.
3. Changed the branding to "Spring Boot for", "Spring Session for" and "Spring Test for", Apache Geode and Pivotal GemFire, 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.

from spring-boot-data-geode.

@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.

from spring-boot-data-geode.

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.

from spring-boot-data-geode.

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).

from spring-boot-data-geode.

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...

1. First, I have changed groupId to org.springframework.geode.
2. Second, I have named the following modules:

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

from spring-boot-data-geode.