SpringBoot Consider adding banner.txt to the list of default filtered resources

Why is banner not filtered by default?

<resources>
      <resource>
        <filtering>true</filtering>
        <includes>
          <include>**/application*.yml</include>
          <include>**/application*.yaml</include>
          <include>**/application*.properties</include>
        </includes>
      </resource>

I know we can use properties from environment, but neither manifest properties nor build-info goal ones seem to be available/injectable from test classpath, and I would to avoid creating domain properties for such generic maven ones

Is there any fundamental blocker for this?

Thanks and regards!

Comment From: snicoll

I was about to mention that filtering only banner*.txt could be quite limited as the name of the banner could be something else entirely, but it strikes me that the current arrangement is also at odds here now that we have spring.config.import that could refer to a file that doesn't match our initial conventions.

Regardless of the above, I think the reference documentation should be improved as the current phrasing doesn't make it obvious that values from the environment can be used.

Flagging for team attention to get some more feedback from the team.

Comment From: nightswimmings

Thanks for your answer @snicoll ! The problem with environment is that I have to expressly create application properties to map maven properties when it would be much easier to simply filter banner by default. (If someone changes the convention then they need to override default resources config, but that is the point of convention over configuration in the end)

Comment From: wilkinsona

What's the motivation for including build-system-specific information in the banner? I'm not sure that a user seeing the banner will be interested in, for example, the group ID coming from Maven. There's a small chance the enabling filtering for the banner will be a breaking change for people so we'd need a good reason to do so.

Comment From: nightswimmings

For me, personally, I usually set up @project.version@

Comment From: wilkinsona

Thanks. As described in the documentation that Stéphane linked to above, you can already use ${application.version} for that. It shouldn’t require any build-time filtering.

Comment From: nightswimmings

Hi Andy! Thanks, I am being quite picky but as I said in the opening comment: I know we can use properties from environment, but neither manifest properties nor build-info goal ones seem to be available/injectable from test classpath, and I would like to avoid creating domain properties for such generic maven ones.

But I understand if it's something complex, the cost/benefit of touching it only for a missing test property is not worthwhile, I dont want to make you loose your time

Comment From: snicoll

Reviewing the discussion above, I think the cost/benefit is not worth it, particularly as I am not keen to expand the default maven filtering rules at this point. I've opened #29920 for the improvement in the documentation.