The Spring IO Platform Released to Simplify Dependency Management

Pivotal last week released the first version of their new Spring IO Platform 1.0. At its core, the Spring IO Platform is a list of dependencies (and their versions) that work well together. Its implementation is a Maven POM file that you can import into your projects to set the versions for dependencies. These dependencies are curated and harmonized across Spring projects, as well as many open source projects. For example, the following open source libraries are included: Logback, Jackson, Guava, JSF, JSTL, JUnit, Derby, Hadoop, Solr, Tomcat, Groovy, EclipseLink JPA, Neo4j and TestNG.

From the platform announcement:

Spring IO is, ultimately, just libraries on the CLASSPATH of your application. You can choose to use specific versions of dependencies using your build tools' <dependencyManagement/> facility. The version management is ultimately a suggestion and a convenience, not a requirement.

Spring IO is certified to work with Java 1.7 and 1.8, though specific projects under Spring IO will often work with even older JDKs, too. It requires only Java SE and supports Groovy, Grails, and some Java EE. As a platform, it can be deployed in embedded runtimes, classic applications server deployments, and PaaS environments.

To learn more about this release, InfoQ sat down with Spring Developer Advocate, Josh Long.

InfoQ: What problem does this solve exactly?

The Spring IO release is a logical way to think about the various frameworks/libraries that we've always provided - pieces to a larger puzzle that fit together nicely - and a much easier way to consume those frameworks. In practice, we've released the Spring IO bill-of-materials Maven artifact which - when included in a client Maven build as an imported dependency, it predefines all the versions of the dependencies of all Spring projects (like Spring Boot, Spring framework, etc.) and of common third-party ecosystem libraries like Hibernate, for you.

Simply declare a dependency on an artifact (like, for example the Spring Boot web support (whose Maven 'groupId' is 'org.springframework.boot' and whose Maven 'artifactId' is 'spring-boot-starter-web') and leave off the version. The Spring IO BOM ensures that all libraries you chose are known to work with each other, and that if common shared dependencies are normalized to be the same version. In practice, this should mean that it's easy to use the latest-known, integrated, updated libraries by simply updating your Maven build dependency on the platform BOM.

Example 1: using the Spring IO BOM in your Maven build.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.spring.platform</groupId>
            <artifactId>platform-bom</artifactId>
            <version>1.0.0.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

This is, of course, still just a build-tool feature. You're more than welcome to use any version of any library you want. We've even defined common library versions as Maven properties (like 'hibernate.version') so that you can quickly override configured dependency versions.

Including the Spring IO BOM in your Maven build doesn't load all the dependencies it defines. Instead, your build will be using it to specify the version numbers. You can still override version numbers, as well as exclude dependencies. To override the version of Spring, you define a <spring.version> property. To exclude dependencies, add the dependency like you normally would and its exclusions (or Maven 3's wildcard exclusion mechanism).

To further illustrate how this works, let's look at an Apache Camel project with CXF and Spring. After importing the Spring IO BOM, you can strip the versions for dependencies and remove properties that it defines. For those dependencies it does not manage (e.g. Apache Camel and CXF), you'll still need to define their versions. The gist below shows how a pom.xml file would change. NOTE: Apache Camel 2.14-SNAPSHOT will only work with Spring 4 if you integrate pull request 199.

The reaction on Reddit was mixed. One commentor mentioned it seemed a lot like Grails, but for the entire Spring stack. Others were enthusiastic, saying that Spring 4 was nice to work with, particularly because it no longer requires any XML. The folks who criticized Spring seemed to recommend Java EE as an alternative.

The Pivotal P.O.V. Blog calls this release the "The Consumerization of Java". Stacy Schneider, managing editor of the GoPivotal blog, compares this move to something Apple does with their hardware. She notes a famous Steve Jobs quote:

"As you know, Apple strives for the integrated model so that the user isn't forced to be the systems integrator."

She goes on to list the benefits of using the Spring IO Platform 1.0 release:

• Testing is simpler - The baseline download includes a set of modules and versions that already work together.
• Configuration is easier - There is no time wasted checking compatibility of modules or versions.
• Flexibility remains - Developers can use what is needed in a lightweight fashion and only need to embed the parts of Spring IO Platform needed in their application.
• Regular release cadence - Spring IO Platform will release at predictable, six month intervals.

Schneider also mentions that this release now includes additional modules that have traditionally been considered different from the core Spring projects; in particular, the domain specific runtimes (DSRs) for applications. A DSR can run standalone without requiring deployment to an external container. Currently, there are three DSRs: Spring XD, Spring Boot, and Grails. Spring XD will join the Spring IO Platform when it goes GA soon.