Currently we are putting all configuration in application.properties.EXAMPLE. There are some issues with this:
It is unclear which of the configuration in EXAMPLE is for a user to change and which isn't (e.g. spring configuration that shouldn't be changed is in the EXAMPLE file)
When a new default is introduced that requires a value, it will currently break the pipeline for anybody that's upgrading which already has a properties file
Using application.properties for a command line client is in general questionable imo, everything should be a command line parameter. If we really want to use a configuration file it might be better to pass it as a command line argument and handle missing values etc elegantly with clear user output of what values are missing. Using spring properties files directly can result in very hard to understand errors for users unfamiliar with Java (there might be a way to override the way spring throws missing config errors, that could be another approach)
Currently we are putting all configuration in
application.properties.EXAMPLE. There are some issues with this:application.propertiesfor a command line client is in general questionable imo, everything should be a command line parameter. If we really want to use a configuration file it might be better to pass it as a command line argument and handle missing values etc elegantly with clear user output of what values are missing. Using spring properties files directly can result in very hard to understand errors for users unfamiliar with Java (there might be a way to override the way spring throws missing config errors, that could be another approach)