-
Notifications
You must be signed in to change notification settings - Fork 41.5k
Use a configurable location to load global Devtools settings #17924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This allows separate projects to keep their own settings where common settings such as spring.* or server.* don't conflict. spring-projects#17923
@scottmf Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@scottmf Thank you for signing the Contributor License Agreement! |
@@ -61,6 +61,17 @@ public void postProcessEnvironment(ConfigurableEnvironment environment, SpringAp | |||
} | |||
} | |||
|
|||
protected File getProjectRootFolder() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a breaking change.
When PropertyFile
of HomeFolder
have a property which not exist in ProjectRootFolder
, after this change the property will be invalid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a breaking change as you have to opt in to looking in the new location by setting that system property or environment variable.
This allows separate projects to keep their own settings where common settings such as spring.* or server.* don't conflict. See spring-projectsgh-17924
While not a breaking change, this comment raises the question of whether we should use the user's home directory to create property sources with lower precedence than those created for the custom home directory. A benefit of this is that it would allow project-specific settings to be set in the custom location and for common settings to be set in the user's home directory. A downside is that it would then be impossible for a property in the user's home directory to be unset. I'm leaning towards keeping things simple and only using one location as in this branch. Flagging for team attention to set what everyone else thinks. |
We discussed this today and decided not to use the default global location as a lower-precedence property source when a custom global location is configured. |
This allows separate projects to keep their own settings where common settings such as spring.* or server.* don't conflict. See gh-17924
@scottmf Thanks very much for your patience and for making your first contribution to Spring Boot. |
This allows separate projects to keep their own settings where common settings
such as spring.* or server.* don't conflict.
#17923