You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Jacob Barrett <jb...@pivotal.io> on 2019/09/25 19:43:15 UTC
Spring Boot with Geode 1.10
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 <on...@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 <jb...@pivotal.io> wrote:
>>
>>
>>
>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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
>>
>
Re: Spring Boot with Geode 1.10
Posted by Owen Nichols <on...@pivotal.io>.
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 <jb...@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 <on...@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 <jb...@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 <on...@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 <jb...@pivotal.io>
>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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)
Re: Spring Boot with Geode 1.10
Posted by John Blum <jb...@pivotal.io>.
Additionally, I would encourage others to read...
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-plugin
And, when using Gradle (instead)...
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-gradle-plugin
This section of Spring Boot's Maven/Gradle Plugin explains it best...
https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/gradle-plugin/reference/html/#managing-dependencies
-j
On Wed, 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 <jb...@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 <on...@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 <jb...@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 <on...@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 <jb...@pivotal.io>
>> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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)
>
--
-John
john.blum10101 (skype)
Re: Spring Boot with Geode 1.10
Posted by John Blum <jb...@pivotal.io>.
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 <jb...@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 <on...@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 <jb...@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 <on...@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 <jb...@pivotal.io>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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)
Re: Spring Boot with Geode 1.10
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <on...@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 <jb...@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 <on...@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 <jb...@pivotal.io> wrote:
>>>>
>>>>
>>>>
>>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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
>>>>
>>>
>>
>
Re: Spring Boot with Geode 1.10
Posted by Owen Nichols <on...@pivotal.io>.
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 <jb...@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 <on...@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 <jb...@pivotal.io> wrote:
>>>
>>>
>>>
>>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols <on...@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
>>>
>>
>