Putting the properties file in the jar is not a good approach for the following reasons:
(1) This implies that the new binary (jar) must be built each time when a configuration change is required, implying relatively high overhead.
(2) Security-relevant properties, such as credentials for accessing the underlying database, currently are stored in a properties file directly on the deployment host and are protected by UNIX access permissions. Jar files to be deployed do not contain any security-relevant information and thus do not require especially high protection (corporate Maven repository is OK). Embedding security-relevant properties into Jars makes impossible fully automated builds (corporate policy prohibits keeping production credentials outside of the production environment, i.e. in source control systems, on build servers etc). We have to forget about automated reproduceable builds and have to build and distribute packages manually. That's not acceptable.
(3) Currently the same binary (Jar) may be deployed to different environments (development, test, production) with different local properties files. Embedding configuration files into Jars would require building separate binaries for different environments with potential errors. One could argue that all properties may be collected in the same Jar and choosen in runtime with a spring profile, but this is totally unacceptable from security point of view: as a developer, I must be able to test the binary on Dev, but according to the corporate policy I should not have access to production credentials.