That was the problem ... I had an old reference to Spring Boot v2.0.1. Updated it to 2.1.9 and now the micrometer versions line up. But I appreciate your broader point: even that version of Spring Boot is only intended to work with Geode 1.9, so trying to mix-and-match with 1.10 is ill-advised at best. Maybe for the purpose of validating Geode release candidates, the best thing for me would be to un-boot-ify my client app.
Thanks everyone for helping me figure out my dependency management puzzle. -Owen > On Sep 25, 2019, at 1:24 PM, John Blum <jb...@pivotal.io> wrote: > > 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)
