Introduction

Spring Boot can display application metadata in banner.txt, but ${application.version} often shows as blank when build metadata is not generated or not loaded at runtime. Developers expect Maven/Gradle project versions to appear automatically, yet Boot only resolves placeholders that exist in the environment, manifest, or generated build-info. This article explains how version placeholders are resolved, how to wire build metadata correctly, and how to verify banner output in local and CI builds.

How Banner Placeholders Are Resolved

banner.txt supports placeholders such as ${spring-boot.version} and ${application.version}. The important difference is that spring-boot.version is built-in, while application.version needs to come from your project metadata.

Example banner.txt:

${AnsiColor.GREEN}My Service${AnsiColor.DEFAULT}
Version: ${application.version}
Boot: ${spring-boot.version}

If application.version is empty, Boot did not find it in environment properties.

Generate Build Metadata with Maven or Gradle

For reliable version exposure, generate build-info.properties.

Maven:

1<plugin>
2  <groupId>org.springframework.boot</groupId>
3  <artifactId>spring-boot-maven-plugin</artifactId>
4  <executions>
5    <execution>
6      <goals>
7        <goal>build-info</goal>
8      </goals>
9    </execution>
10  </executions>
11</plugin>

Gradle:

springBoot {
    buildInfo()
}

Then Boot can expose values from BuildProperties and environment mapping.

Expose Version as Property Explicitly

If your banner expects ${application.version}, provide it via application.properties or build filtering.

application.version=@project.version@

With Maven resource filtering enabled, @project.version@ is replaced during build.

1<resources>
2  <resource>
3    <directory>src/main/resources</directory>
4    <filtering>true</filtering>
5  </resource>
6</resources>

Alternative for Gradle:

1processResources {
2    filesMatching("application.properties") {
3        expand(version: project.version)
4    }
5}

Then use application.version=${version} pattern.

Troubleshooting Runtime Differences

Many teams see correct output in IDE runs but not in packaged jars, or vice versa. Verify actual runtime artifact contents:

jar tf build/libs/myapp.jar | grep -E "banner|build-info|application.properties"

Also log resolved properties at startup:

1@Bean
2ApplicationRunner check(Environment env) {
3    return args -> System.out.println("application.version=" + env.getProperty("application.version"));
4}

This confirms whether property resolution or banner interpolation is failing.

Practical Verification Workflow

A strong way to avoid regressions is to validate changes in three stages: baseline, targeted change, and repeatability. First, capture a baseline command/output before applying fixes so you can prove improvement. Second, apply one focused change at a time, then rerun the exact same check to confirm causality. Third, rerun the validation multiple times (or with nearby input variants) to ensure behavior is stable and not a one-off pass.

A simple validation template:

1# 1) capture baseline behavior
2./run_case.sh > before.txt
3
4# 2) apply one targeted fix
5# edit code/config based on this article
6
7# 3) validate after change
8./run_case.sh > after.txt
9diff -u before.txt after.txt

If your stack has tests, add at least one regression test that fails before the fix and passes after it. This turns troubleshooting knowledge into durable protection against future changes. In team environments, including the exact commands used for verification in pull requests or runbooks makes results reproducible across machines and CI.

Operational Checklist for Production Use

Before shipping a fix or optimization, confirm environment parity and observability. Verify toolchain/runtime versions, capture key metrics, and define rollback criteria. A technically correct local fix can still fail in production if infrastructure assumptions differ.

1# Example pre-release checks
2./lint.sh
3./test.sh
4./smoke_test.sh

A minimal release checklist usually includes: compatible dependency versions, representative test coverage, explicit monitoring signals, and a rollback plan. This discipline reduces the chance that a local solution introduces new issues under real traffic or larger datasets.

Common Pitfalls

• Assuming ${application.version} is built-in like ${spring-boot.version}.
• Forgetting to generate build info during packaging.
• Enabling placeholders in banner.txt without injecting matching properties.
• Verifying only IDE runs instead of packaged artifact behavior.
• Using resource filtering incorrectly and shipping unresolved tokens.

Summary

If application version is missing in banner.txt, the root issue is usually missing build metadata or unresolved property mapping. Generate build info, inject project version explicitly, and validate final jar contents. With those steps, banner version display becomes deterministic across local, CI, and production deployments.