I am fairly new to java using Spring boot and maven. I was assigned a task to get the revision number and timestamp for the current revision from the project and put them into an app.properties file . Most of the demonstrations I have found displayed the templates as such, version=${version} revision=${buildNumber} date=${timestamp}. I tried these all in a seperate application and they worked properly, however it the release notes for spring boot 1.3 state that the templates now have to be written such as, @version@.

Version works properly using that information, however the build number and timestamp do not print out anything except for the template that should be replaced with that information. I have googled and checked stack overflow but i am not finding any way to get these two things working properly. I have also tried to pull the information from SVN but it is also just returning the template on commit

Dani AI

Generated

— short answer: Spring Boot 1.3 intentionally switches Maven filtering for config files to the @...@ style, and the blank placeholders you see for build number / timestamp usually mean those values were not generated by the time Maven filtered resources. The release notes/documentation explain the @ delimiter change. (github.com)

Typical root cause and fix

  • The Maven resources filtering happens in the process-resources phase. Any properties that are generated by plugins must be created before that phase (for example in validate/initialize). If the build-number/timestamp plugin runs too late the tokens are left untouched. Bind the build-number plugin so it runs before process-resources. (sonatype.com)

Example POM actions (apply to your pom.xml)

  • Add/confirm a build-number execution that runs in validate (so the property exists before filtering) and create a timestamp if needed. For example, configure the mojo to run in the validate phase so it populates properties early. Then enable resource filtering (or inherit spring-boot-starter-parent which already sets the delimiter to @). (mojohaus.org)

Content filtering notes and pitfalls

  • If you do not inherit the starter parent, you must enable filtering and set the maven-resources-plugin delimiters (useDefaultDelimiters=false and add the @ delimiter) so Spring placeholders (${...}) are left alone while Maven replaces the @...@ tokens. Also remember that running spring-boot:run can behave differently with classpath/resources — build the project (process-resources / package) to confirm filtered files in target/classes. (docs.spring.io)

Quick checks

  • Inspect target/classes/application.properties after mvn package.
  • Run mvn -X to see whether the build-number plugin executed and which properties it set.
  • Ensure your POM has a correct <scm> section if you expect the plugin to read the SVN revision (or use Subversion keyword substitution deliberately — that is a separate SVN feature requiring svn:keywords on the file). (visualsvn.com)

Note for and : stamping builds is optional but common in CI; this advice only covers making those auto-generated values available to application.properties via Maven filtering.

Recommended Answers

All 2 Replies

The thing is, I don't see this being a standard in the system you are asking about. Maybe I'm missing it but the app version number is something we decide on when we begin a project. I can't tell you how to do this since on each project we let the owner of the project tell us how they want to run the version numbers.

Not to mention the fact that there is no "law" that states a project HAS TO provide information about it's version or build.

commented: This area is one I let the owner make the rule (or law.) Something about the owner of the gold makes the rules. +10
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.