geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: Spring Boot with Geode 1.10
Date Wed, 25 Sep 2019 20:24:55 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message