Add hot reload context #2596
Add hot reload context #2596
Conversation
|
@stuartwdouglas I think that we should have an issue for this kind of PRs... |
| * A build item that can be used to query the live reload state. | ||
| * | ||
| * | ||
| * It can also be used to store context that that is persistent between hot reloads. |
| } | ||
|
|
||
| /** | ||
| * If this is a live reload this set contains the set config resources that have changed |
There was a problem hiding this comment.
s/the set config resources/the config resource/ (or the set of)
|
Pull requests are issues on github though (e.g. the path /issues/2596 will take you to this page). They still show up in the release notes same as a non-pr issue, so I don't really see the value in creating a new issue (when using an external system such as JIRA this is different, but with github's integrated model I don't really see what an extra issue gets you). |
Also fixes an issue where it would be extracted on every restart
stuartwdouglas
force-pushed
the
hot-reload-context
branch
from
65cb0c5
to
180ad3f
Compare
I know but I can't say I like this "shortcut design". I prefer to discuss the "important" stuff separately from implementation details. But it's just my 2c. If there are no objections in the team I can live with this kind of development model. |
|
@mkouba I agree with you I prefer separate issues from impl and multiple potential PRs on a subject acting as issues |
This provides additional information about the hot reload state of the application, and provides a caching mechanism to avoid the need to stick things in statics.
This still needs to be expanded to include other extensions, e.g. this will allow hibernate/flyway to only initialize the DB if the SQL files have changed.