Awesome job! Way to go John and SDG team, your contributions and diligence are much appreciated. We are going to get started applying these updates and look forward to Geode 1.0.0 GA soon to follow!
-Roger Lead Engineer Ticketmaster From: John Blum <jb...@pivotal.io<mailto:jb...@pivotal.io>> Reply-To: "user@geode.incubator.apache.org<mailto:user@geode.incubator.apache.org>" <user@geode.incubator.apache.org<mailto:user@geode.incubator.apache.org>> Date: Tuesday, October 11, 2016 at 4:00 PM To: "d...@geode.incubator.apache.org<mailto:d...@geode.incubator.apache.org>" <d...@geode.incubator.apache.org<mailto:d...@geode.incubator.apache.org>>, "user@geode.incubator.apache.org<mailto:user@geode.incubator.apache.org>" <user@geode.incubator.apache.org<mailto:user@geode.incubator.apache.org>> Subject: Spring Data Geode 1.0.0.APACHE-GEODE-INCUBATING-M3 Released! Now, many Moons overdue, and for that, I apologize to both the Spring and Apache Geode communities for the delay, however, I am extremely pleased to officially announce the release of Spring Data Geode with support for Apache Geode 1.0.0-incubating.M3. Bits in Maven Central [1]. So, why should Apache Geode developers use Spring to build enterprise applications that use Apache Geode? 1. Spring has highly consistent, robust and comfortable/familiar programming model that is second to none. 2. But, more importantly, SDG protects developers from unexpected changes, such as API breaking changes introduced between versions of Apache Geode, or for instance, GEODE-37 [2], the new package structure (com.gemstone.gemfire -> org.apache.geode), which will affect your applications. 3. SDG makes it easy to switch between Apache Geode and Pivotal GemFire if the time ever arises where you need the added support. It is as simple as switching the dependency from... <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-geode</artifactId> <version>1.0.0.APACHE-GEODE-INCUBATING-M3</version> </dependency> To... <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-gemfire</artifactId> <version>1.8.4.RELEASE</version> </dependency> NOTE: versions very after time. 4. By using Spring, and SDG specifically, you can easily integrate with the vast array of other powerful Spring technologies, all OSS (e.g. Spring Session [Data GemFire|Geode] [3] for Session replication, or Spring XD [4] for streaming). See Luke Shannon and I's presentation [5] (slides 6-14) on all ways in which Apache Geode (and/or Pivotal GemFire) has been weaved into the fabric of Spring. 5. Finally, SDG has just answered the question on how to "get up and running as quickly and easily as possible" by combing Spring Boot with SDG's new, but complimentary Annotation configuration model. For instance, to create a "managed"/Manager, Geode peer/cache server application with an embedded Locator that you can easily and quickly connect to using Gfsh in order to inspect or get/put data into the declared (Example) Region, just define... @SpringBootApplication @CacheServerApplication @EnableLocator @EnableManager @Import(ExampleApplicationConfiguration.class) public class ExampleApplication { public static void main(String[] args) { SpringApplication.run(ExampleApplication.class, args); } @Configuration static class ExampleApplicationConfiguration { @Bean(name = "Example") LocalRegionFactoryBean<String, String> exampleRegion(GemFireCache gemfireCache) { LocalRegionFactoryBean<String, String> exampleRegion = new LocalRegionFactoryBean<>(); exampleRegion.setCache(gemfireCache); exampleRegion.setClose(false); return exampleRegion; } } } In subsequent releases, this configuration will be simplified even further by introducing convenient configuration for Regions based on the application domain model classes and/or when using the SD Repository abstraction [6]. I.e. this configuration will become something like... @SpringBootApplication @CacheServerApplication @EnableLocator @EnableManager @WithLocalRegions({ "Example" }) public class ExampleApplication { public static void main(String[] args) { SpringApplication.run(ExampleApplication.class, args); } } The @WithLocalRegions with even allow a entityScan attribute referring to either a class (used as the root), or package containing your application domain objects to "determine" the required Regions. Your application domain objects would typically be annotated with the @Region annotation anyway when using the SD Repository abstraction, like so... @Region("People") class Person { ... } By inspecting this class, or the package (and sub-packages) this class is in, we can determine the Regions your application will need to persist your data. Simple, quick and easy! To see more information on the release, see my blog post on spring.io<http://spring.io> [7]. We are planning a series of blogs and examples to really help solidify the use of Apache Geode in your applications. Stay tuned for more! -- -John [1] http://search.maven.org/#search%7Cga%7C1%7Cspring-data-geode [2] https://issues.apache.org/jira/browse/GEODE-37 [3] http://docs.spring.io/spring-session/docs/1.2.2.RELEASE/reference/html5/#httpsession-gemfire [4] http://projects.spring.io/spring-xd/ [5] http://www.slideshare.net/john_blum/spring-data-and-inmemory-data-management-in-action [6] http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#gemfire-repositories [7] https://spring.io/blog/2016/10/11/spring-data-geode-1-0-0-apache-geode-incubating-m3-released
