When we extend spring-boot-starter-parent, our project inherits dependency management from spring-boot-dependencies (spring-boot-dependencies is the parent POM of spring-boot-starter-parent). That means we can declare many libraries, both Spring modules and popular third-party ones, without a version tag. Spring Boot picks a version that was tested with the Boot release we use.
In this tutorial we are going to see how to find those managed versions, how to add a third-party library, and how to override a managed version or another default property of the parent POM. If you are new to starters, see the previous tutorial first.
Finding the managed versions
We can find all the third-party libraries and their default versions in the spring-boot-dependencies POM or in the Dependency Versions appendix of the reference documentation. spring-boot-dependencies is the parent of spring-boot-starter-parent.
We can also browse the parent POMs from an IDE to find the answers.
Another way is to run mvn help:effective-pom from the project root, or better, save the output to a file for investigation: mvn help:effective-pom > myEffectivePom.txt
Overriding a managed dependency version
The version of a managed dependency can be changed by adding the appropriate property element to our POM. The property name follows the pattern <artifactId>.version, as declared in spring-boot-dependencies.
Let's add a dependency on another third-party library, commons-codec, and change its managed version to 1.18.0 by overriding the commons-codec.version property. Notice that the dependency itself has no version tag.
pom.xml<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>4.1.1</version>
<relativePath></relativePath>
</parent>
<groupId>com.logicbig.example</groupId>
<artifactId>boot-overriding-properties</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<java.version>25</java.version>
<commons-codec.version>1.18.0</commons-codec.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</dependency>
</dependencies>
</project>
Let's modify our Java code (from last tutorial) a little to use Apache Commons Codec:
package com.logicbig.example;
import org.apache.commons.codec.binary.Hex;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import java.nio.charset.StandardCharsets;
@SpringBootApplication
public class ApplicationExample {
@Bean
public MyBean myBean() {
return new MyBean();
}
public static void main(String[] args) {
ApplicationContext ctx =
SpringApplication.run(ApplicationExample.class, args);
MyBean bean = ctx.getBean(MyBean.class);
bean.doSomething();
}
private static class MyBean {
public void doSomething() {
System.out.println("Doing something in MyBean");
System.out.println(Hex.encodeHexString(
"ONE".getBytes(StandardCharsets.UTF_8)));
System.out.println(Hex.class.getProtectionDomain()
.getCodeSource()
.getLocation());
}
}
}
Output
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v4.1.1)
2026-10-13T03:03:21.238-05:00 INFO 10272 --- [ main] c.logicbig.example.ApplicationExample : Starting ApplicationExample using Java 25 with PID 10272 (D:\LogicBig\example-projects\spring-boot\boot-overriding-properties\target\classes started by joe2 in D:\LogicBig\example-projects\spring-boot\boot-overriding-properties)
2026-10-13T03:03:21.240-05:00 INFO 10272 --- [ main] c.logicbig.example.ApplicationExample : No active profile set, falling back to 1 default profile: "default"
2026-10-13T03:03:21.570-05:00 INFO 10272 --- [ main] c.logicbig.example.ApplicationExample : Started ApplicationExample in 0.565 seconds (process running for 0.78)
Doing something in MyBean
4f4e45
file:/C:/Users/Joe/.m2/repository/commons-codec/commons-codec/1.18.0/commons-codec-1.18.0.jar
Verifying that the override took effect
To confirm which version Maven actually resolved, we can filter the dependency tree:
$ mvn dependency:tree -Dincludes=commons-codec
[INFO] Scanning for projects...
[INFO]
[INFO] ---------< com.logicbig.example:starter-overriding-properties >---------
[INFO] Building starter-overriding-properties 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- dependency:2.10:tree (default-cli) @ starter-overriding-properties ---
[INFO] com.logicbig.example:starter-overriding-properties:jar:1.0-SNAPSHOT
[INFO] \- commons-codec:commons-codec:jar:1.18.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.326 s
[INFO] Finished at: 2026-10-12T05:10:30-05:00
[INFO] ------------------------------------------------------------------------
When to override a managed version
A common reason is to pick up a bug or security fix in a library before the next Spring Boot patch release includes it. Overriding is safe for most leaf libraries, but be careful with libraries that Spring Boot or the Spring Framework depend on closely. The managed versions are the ones tested together, so after an override, run the full test suite. Overriding the Spring Framework version itself is possible with the spring-framework.version property, but upgrading Spring Boot is usually the better option.
Overriding other properties
The same mechanism works for the other defaults defined by the parent POM. For example, the parent defaults the Java version to the minimum supported by the Boot release (Java 17 for Spring Boot 4). To compile for a newer Java version, such as Java 21 (or 25, which Spring Boot 4 also supports), we can set:
<java.version>25</java.version>
The parent uses this property to configure the Maven compiler plugin, so we do not have to set the compiler options ourselves. To see every property the parent defines, look at the effective POM as shown above.
What's next?
In the next tutorial, we are going to discuss how to use Spring Boot without inheriting the spring-boot-starter-parent POM.
Example ProjectDependencies and Technologies Used: - Spring Boot 4.1.1
Corresponding Spring Version 7.0.9
Version Compatibility: 1.4.0.RELEASE - 4.1.1
- spring-boot-starter (Core starter, including auto-configuration support, logging and YAML)
- commons-codec 1.18.0 (The Apache Commons Codec component contains encoders and decoders for
formats such as Base16, Base32, Base64, digest, and Hexadecimal. In addition to these
widely used encoders and decoders, the codec package also maintains a
collection of phonetic encoding utilities. [Description from commons-codec-1.18.0.pom])
- JDK 25
- Maven 3.9.11
|
