Have you ever created a project and had someone say (maybe that person was yourself) “we better put that file in an external place so I can be changed at runtime just in case”? Chances are if you did and followed through on it without a specific requirement for it then I would be willing to bet you ended up never changing the file at runtime (presuming you have a relatively strict change process at your shop). I have put myself in the same situation many times creating overly complex software which involved many random file system structures external to the central package (in JEE the WAR file) because of the “in case we need it” rationale. I want to convince people that we should stop unless its required.
When you start creating file system dependencies or other dependencies on your code outside the package you are basically trading increased complexity for flexibility. In most cases I have seen this trade off made (outside of requirements) because people are trying to anticipate issues with the code but it actually just heightens the probability for issues in the future because of the increased complexity. It’s not that you won’t code it right the first time but in the future it can and probably will cause confusion and problems with new developers without a lot of extra work. The extra work being creating hooks in the build process, handling potential environment differences, and deployment issues beyond the initial build.
In the end if you have the belief you can code it write in the first place then just code the simplest solution right, don’t over shot the mark. Unless you have a compelling need avoid creating external dependencies on your application.