Spring Boot
Autowired
BuildProperties
Eclipse
Dependency Injection

Failed Autowired of BuildProperties Spring Boot 2.1.5 eclipse

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

If @Autowired BuildProperties fails in Spring Boot, the usual problem is not Eclipse itself. The usual problem is that BuildProperties is only created when META-INF/build-info.properties exists, and that file is generated only if your build plugin is configured to produce it.

What BuildProperties Depends On

Spring Boot can expose build metadata such as:

  • artifact name
  • version
  • group
  • build time

But it does not invent that metadata automatically at runtime. The BuildProperties bean is created only when the application contains the generated build-info.properties resource.

So if you inject this:

java
@Autowired
private BuildProperties buildProperties;

and the file does not exist in the built application, autowiring fails because there is no bean to inject.

Generate build-info.properties

For Maven, configure the Spring Boot plugin to generate build info.

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

Then run a real Maven build, not just an IDE launch that bypasses packaging steps.

After the build, the generated file should appear under META-INF/build-info.properties in the output artifact.

If your project uses Gradle instead of Maven, enable the same metadata generation through the Spring Boot plugin:

groovy
springBoot {
    buildInfo()
}

Then run ./gradlew bootJar or another task that builds the application artifact.

Use The Bean Safely

Once the file is generated, you can inject BuildProperties normally.

java
1import org.springframework.boot.info.BuildProperties;
2import org.springframework.stereotype.Component;
3
4@Component
5public class VersionService {
6    private final BuildProperties buildProperties;
7
8    public VersionService(BuildProperties buildProperties) {
9        this.buildProperties = buildProperties;
10    }
11
12    public String version() {
13        return buildProperties.getVersion();
14    }
15}

This is the clean constructor-injection form and makes the dependency explicit.

Why It Often Looks Like An Eclipse Problem

IDE runs can mislead people because the application may start from compiled classes without the generated build metadata step ever being executed.

So the sequence is often:

  1. code compiles in Eclipse
  2. BuildProperties is injected
  3. bean creation fails because no build-info file was generated
  4. Eclipse gets blamed, even though the missing resource is the real issue

A Maven clean package is the right test.

Optional Injection Is Sometimes Better

If build metadata is nice to have but not mandatory, make the dependency optional.

java
1import java.util.Optional;
2import org.springframework.boot.info.BuildProperties;
3import org.springframework.stereotype.Component;
4
5@Component
6public class VersionService {
7    private final Optional<BuildProperties> buildProperties;
8
9    public VersionService(Optional<BuildProperties> buildProperties) {
10        this.buildProperties = buildProperties;
11    }
12
13    public String version() {
14        return buildProperties.map(BuildProperties::getVersion).orElse("unknown");
15    }
16}

This avoids hard startup failure when the build-info resource is absent.

Verify The Resource Explicitly

If you are unsure whether the resource exists, inspect the built artifact or classpath output. The failure is usually obvious once you confirm that META-INF/build-info.properties was never generated.

That check is more productive than repeatedly reimporting the Eclipse project.

You can also turn on Spring Boot's condition report during startup. Launch the application with --debug and inspect the auto-configuration report to see whether the build properties auto-configuration matched and why it did or did not create the bean.

Common Pitfalls

A common mistake is assuming BuildProperties is always available in every Spring Boot application. It is not. The bean depends on generated build metadata.

Another issue is configuring the plugin but never running a build phase that actually generates the file. An IDE run alone may not do that.

Developers also sometimes use field injection and then get a null-like startup error without understanding the missing bean condition. Constructor injection makes the dependency more explicit.

Finally, do not hard-require BuildProperties unless your application genuinely cannot run without it. Optional injection is often the better design.

Summary

  • 'BuildProperties exists only when META-INF/build-info.properties has been generated and packaged.'
  • Configure the Spring Boot build plugin with the build-info goal.
  • Run a real Maven or Gradle build to generate the resource.
  • Eclipse is often only where the symptom appears, not the true cause.
  • Use optional injection if build metadata is useful but not mandatory.

Course illustration
Course illustration

All Rights Reserved.