There is no version of Spring Boot (SBDG) currently built on Apache Geode 1.10 at the moment.
In general, you should understand 2 things. 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent on is indirectly (transitively) determined by upstream dependencies. SBDG -> Spring Boot -> SDG -> Apache Geode. E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x. SBDG 1.2 pulls in SDG Moore/2.2. Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and Spring Boot must agree on the version of SD[G] that they use. So, it is not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9. E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6. SBDG 1.1 pulls in SDG Lovelace/2.1. Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2. Both SBDG and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1 respectively. 2. Next, Spring Boot's dependency management extends beyond simply Spring Data, to other (upstream, from Boot) Spring projects/dependencies (e.g. Spring Framework, Spring Batch, Spring Integration, Spring Security, etc) as well as 3rd party libraries. Any, and I mean ANY (!) properly managed Java project, not just Spring, must manage dependencies in a consistent and responsible way to avoid conflicts that would cause end users issues (especially with their applications that consume our dependencies) given multiple transitive dependencies are likely to share the same dependencies (e.g. logging is always usually the most common example). You should not assume you can just simply change dependencies at random (e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer versions, or whatever). The stars must align so to speak, and for good reason. Again, this is why tools like Apache Maven exists in the first place. In some cases, this might work, but it is not normal to think you can do this in general, and most of the Java community understands this. It must be a conscious choice and users are aware that they must manually exclude/override a dependency and/or declare their own dependencyManagement section in their application POM to declare their choices. Anyway, this 1 of the many reasons why Spring Boot so eloquently handles this concern for you. SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches GA. Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot 2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies at that time. The fact that Micrometer 1.0.3 was mention would mean that you are using `spring-geode-starter` 1.0.x since Spring Boot has not be based on Micrometer 1.0.x since 2.0 [3], which is now EOL. -j [1] https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243 [2] https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153 [3] https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127 On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > Offline discovery… > > Looking at ./gradlew dependencies shows that micrometer is being > downgraded by spring dependency plugin to 1.0.3. Attempting different > versions of spring boot. > > -Jake > > > > On Sep 25, 2019, at 1:04 PM, Owen Nichols <onich...@pivotal.io> wrote: > > > > This still pulls in micrometer 1.0.3 > > > > dependencies { > > compile('org.springframework.boot:spring-boot-starter') > > > > implementation(platform('org.apache.geode:geode-client-bom:1.10.0')) > > implementation('org.apache.geode:geode-core') > > implementation('org.apache.geode:geode-cq') > > > > testCompile('org.springframework.boot:spring-boot-starter-test') > > testCompile 'junit:junit:4.+' > > } > > > > > >> On Sep 25, 2019, at 12:43 PM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > >> > >> Changing subject… > >> > >> > >> Try > >> dependencies { > >> > implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’)) > >> implementation(‘org.apache.geode:geode-core’) > >> implementation('org.apache.geode:geode-cq’) > >> } > >> > >> Does that make a difference? > >> > >> > >>> On Sep 25, 2019, at 12:35 PM, Owen Nichols <onich...@pivotal.io> > wrote: > >>> > >>> My build.gradle is pretty simple: > >>> > >>> repositories { > >>> mavenCentral() > >>> maven { > >>> url ' > https://repository.apache.org/content/repositories/orgapachegeode-1059' > >>> } > >>> } > >>> > >>> dependencies { > >>> compile('org.springframework.boot:spring-boot-starter') > >>> compile 'org.apache.geode:geode-core:1.10.0' > >>> compile 'org.apache.geode:geode-cq:1.10.0' > >>> } > >>> > >>> > >>>> On Sep 25, 2019, at 12:29 PM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > >>>> > >>>> > >>>> > >>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <onich...@pivotal.io> > wrote: > >>>>> > >>>>> ⚠️ to run my spring boot client for above test, I had to manually > add compile 'io.micrometer:micrometer-core:1.2.0' , otherwise local region > creation blows up with “java.lang.NoSuchMethodError” due to > spring-boot-starter pulling in micrometer 1.0.3 by default. This never > happened with previous versions. Not sure if this is outside Geode’s > control, but it felt like a poor out-of-the-box experience... > >>>> > >>>> Is your spring app including geode via maven/gradle dependency > management? This may be pointing to a greater issue with dependency exports > in the new release's POM. > >>>> > >>>> -Jake > >>>> > >>> > >> > > > > -- -John john.blum10101 (skype)
