geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: Spring Boot with Geode 1.10
Date Wed, 25 Sep 2019 20:36:16 GMT
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 <jblum@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 <jbarrett@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 <onichols@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 <jbarrett@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 <onichols@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 <jbarrett@pivotal.io>
>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <onichols@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)


Mime
View raw message