There were a couple of alternative titles for this post like “Application.Properties File Integrity in Referenced Spring Projects” and “Retaining Spring Dependency Project Application.Properties Awareness” but they seemed a little too academic. The crux of the matter is that your referenced Spring Project can’t find its application.properties keys so you duplicate them in the project that’s referencing it to make the null property exceptions go away.
If you’ve been following along with NixMash Spring development we recently added a Mail Module that we reference from our MVC Web Module for generating a Contact Form email. All was jake with a Gradle mail:bootRun, but mvc:bootRun was spitting out “missing property” exceptions. Duplicating the necessary Mail Application.Properties settings in the MVC module was a fix, but was oh-so wrong.
To retain application.properties awareness in the Spring Dependency Project (or however you want to say it), we explicitly define a properties file in our Spring Mail Module. It’s also important to name it something other than application.properties.
With that simple addition, we can populate our Velocity Templates, even specify their location within our Mail Module, without adding a statement to our MVC Application.Properties file or, worse case, duplicating our Velocity Templates in the MVC Module.