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:
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.
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:
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.
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:
- code compiles in Eclipse
BuildPropertiesis injected- bean creation fails because no build-info file was generated
- 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.
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
- '
BuildPropertiesexists only whenMETA-INF/build-info.propertieshas been generated and packaged.' - Configure the Spring Boot build plugin with the
build-infogoal. - 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.

