Polish GemFire starter and sample.

[jxblum]

There are a few things that should be cleaned up in the existing spring-boot-starter-data-gemfire module:

1. Remove the explicit dependency on GemFire, both in spring-boot-dependencies/pom.xml as well as spring-boot-starters/spring-boot-starter-data-gemfire/pom.xml. This is problematic since the GemFire version declared by Spring Boot may conflict with the version that Spring Data GemFire automatically pulls in when the appropriate Spring Data Release Train (e.g. Hopper) is specified.
2. Use Spring Java-based configuration meta-data inside the SampleDataGemFireApplication class to configure GemFire (keeping the XML for comparison).
3. Other minor cleanup/polish: suppress the verbose logging caused by Spring Boot's starter logging, adding Spring Shell dependency required by GemFire at runtime, etc.

[jxblum]

As a reminder, the following Spring libs-release repository declaration in spring-boot-starters/spring-boot-starter-data-gemfire.pom is necessary since the GemFire artifact (gemfire-8.2.0.jar) does not reside in Maven Central. It is, however, resolvable from the Spring lib-release Maven Repository.

[jxblum]

Two questions I have are...

1. What is the purpose of the spring.provides file in /META-INF?

I recently removed the "gemfire" value in the provides: property based on the removal of the explicit GemFire dependency in the aforementioned Spring Boot POM files. However, even before that, I don't understand/see the significance of this file.

2. I am curious how I was able to refer to GemFire classes in my application classes when my application POM file only declares the spring-boot-starter-data-gemfire dependency, like so...

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-gemfire</artifactId>
      <version>1.4.0.BUILD-SNAPSHOT</version>
    </dependency>

I really thought that if an application using GemFire needed to refer to GemFire classes directly, that it would need an explicit compile dependency declaration in the application POM file on the GemFire dependency (??). But, it seems that just by declaring the spring-boot-starter-data-gemfire dependency in my application POM that I am able to refer to and compile application classes using GemFire classes directly because of the "transitive" nature of the Maven dependencies pulled in by the starter... i.e. spring-boot-starter-data-gemfire -> spring-data-gemfire:1.8.0.RC1 -> gemfire:8.2.0.

This validates 2 things... 1) that the starter is highly convenient for starting Spring applications using GemFire (very cool!), and 2) that the "explicit" GemFire dependency declaration in spring-boot-starters/spring-boot-starter-data-gemfire was definitely not needed.

Is my understanding correct?

Thanks.

[snicoll]

Regarding your questions:

The spring.provides file has two purposes: we use it to auto-generate the doc of the starters (though I can't find the reference right now) and STS apparently uses it to give you hints (but to be honest, I still don't get how it's supposed to parse that file, maybe @kdvolder knows).

The purpose of a starter for acme is that if you add it you get what's required to start working on acme (the viable minimum that is). If you must add something else when you add a starter for which we could reasonably have an opinion, then something is wrong in the starter. In this case gemfire is added with an exclusion and should stay there. It's not about adding gemfire (data gemfire does that already). It's about making sure commons-logging is not added. So it is required for the reason.

[jxblum]

Thanks @snicoll for the information on the spring-provides file; that helps.

You can exclude transitive dependencies of dependencies simply by adding the "commons-logging" exclusion to the outer most, top-level direct dependency of any POM (i.e. the spring-boot-starter-data-gemfire Maven POM SDG dependency declaration), like I have done in my polishing PR...

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-gemfire</artifactId>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Technically, SDG pulls in GemFire (8.2.0) which pulls in org.apache.logging.log4j:log4j-jcl:jar:2.1:runtime which pulls in "commons-logging". See GemFire (8.2.0) Maven POM file for further details. So, if you run...

$mvn -f gemfire-8.2.0.pom dependency:tree | less

On the downloaded (slightly modified; I added Spring libs-release repo declaration to resolve the darn jline-1.0.S2-B.jar) and attached GemFire 8.2.0 Maven POM (for your convenience) to see the dependencies. Search for "/commons-logging" and you see that "commons-logging" is pulled in by the Log4J/JCL bridge JAR.

gemfire-8.2.0.pom.zip

As further evidence of my arguments above concerning exclusion, if you run...

$ mvn -f spring-boot-starters/spring-boot-starter-data-gemfire/pom.xml dependency:tree | less

On the "polished" GemFire starter/sample in my PR, you will notice there is no "commons-logging" dependency, even though the exclusion is on the SDG dependency in the spring-boot-starter-data-gemfire POM.

[jxblum]

@snicoll One final comment...

So, it would seem that declaring only the SDG dependency directly in the spring-boot-starter-data-gemfire POM is enough to get started using GemFire in Spring (Boot) applications.

With the SDG dependency declaration in the starter, and user applications that only declare the spring-boot-starter-data-gemfire starter POM in their application POM, it is enough to even import GemFire classes, as was evident in my external (to Spring Boot) example application (separate IDE project) as well as to the Spring Boot Sample Data GemFire application included with Spring Boot itself.

I.e. the sample POM has no direct dependency on GemFire, only SDG. However, the sample application is still able to import GemFire classes through the transitive dependencies (SDG -> GemFire). That actually surprised me since I thought any application that required a "compile-time" dependency on a transitive dependency of an applications "direct" dependencies (i.e. SDG) would have had to "explicitly" declare the transitive dependency (i.e. GemFire) in the application POM as well.

So, I think my "polish" is correct and very clean/minimal.

Feedback/thoughts welcomed though.