Use Case
I have the need to configure serverURL differently not only in different environments, but also for different developer environments. Currently, I'm using "grails.config.locations" to allow developers to put overrides in their home directory, e.g. to run on a different port. However, the port needs to be referenced in certain other URLs we configure; at present, I find that I need to override all other values that may use the port, e.g. in GStrings - port=8989; mySvc = "http://localhost:${port}". Additionally, in order to not have to repeat the custom port on the command line (grails -Dserver.port=8989 run-app), I can copy the port config to BuildConfig.groovy.
Ideally, developers can place their port override once in their ~/grails/${appName}-config.groovy and be done with it.
First, is there already a better way?
Second, I've a few thoughts and am requesting comments, assuming there's not already a better solution.
RFC
As to adding "config parameters", it seems that each config script could use a "configParameters" property that would be set as ConfigSlurper's binding. This allows one to reference those values in GStrings. However, it appears that Grails' ConfigurationHelper would need to modified in several ways.
One issue is that ConfigurationHelper needs to understand the "configParameters" property and do the assignment. Second, I think it may be necessary, or useful, to rearrange the parse-order so that the sequential nature of grails.config.locations is made more intuitive with respect to assigning and referencing such "config parameters". For example, if I define a default config parameter port in grails-app/conf/Config, it should be overridden by the one found in my ~/.grails/${appName}-config.groovy. Perhaps it makes sense to define the locations outside the "main config" s.t. ConfigurationHelper already knows which set of resources and merge order to use (without having to say, reparse grails-app/conf/Config).
Lastly, and something I've not figured out, is how to deal with BuildConfig.groovy; I'm not sure if it respects grails.config.locations.