5. Overriding Spring IO Platform’s dependency management

One of the major benefits of the Spring IO Platform is that it provides a set of versions that are known to work together, while also allowing you to override those versions to suit the needs of your project.

Both the Spring IO Platform bom, and the Spring Boot bom from which it inherits, use properties to define the versions of the managed dependencies. To change the version of a dependency the value of its version property can be overridden. To identify the property that you wish to override, consult the <properties> sections of the Spring IO Platform bom and the Spring Boot bom from which it inherits. Exactly how the property is overridden depends on whether your project is built with Maven or Gradle.

5.1 Overriding a version using Maven

To override a property in Maven, declare the property in your pom’s <properties> section with the desired value:

<properties>
    <foo.version>1.1.0.RELEASE</foo.version>
</properties>

5.2 Overriding a version using Gradle

To override a property in Gradle, configure its value in your build.gradle script:

ext['foo.version'] = '1.1.0.RELEASE'

Or in gradle.properties:

foo.version=1.1.0.RELEASE

5.3 Logging

Spring IO Platform builds on top of Spring Boot which takes a somewhat opinionated view about logging in that it aims to prevent Commons Logging from being used by default. Instead, it encourages the use of Logback via its spring-boot-starter-logging module. Support for other logging frameworks, including Log4J and Log4J2, is also provided. Wherever possible, applications built using Spring IO Platform adopt this approach.

If you choose not to use Spring Boot’s spring-boot-starter-logging module but still wish to avoid the use of Commons Logging, using SLF4J and its jcl-over-slf4j module is recommended along with a logging backend such as Logback or Log4J2.