changed application.properties not taken into account starting devmode
See original GitHub issuemvn quarkus:devmode
picks up .java changes but does not pick up changes to application.properties
for that I need to explicitly do mvn compile quarkus:devmode
.
I would expect it to be picked up if .java changes are OR that all “compilable” source changes will be ignored by quarkus:devmode
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Configuration Reference Guide - Quarkus
In this reference guide we're going to describe various aspects of Quarkus configuration. A Quarkus application and Quarkus itself (core and extensions) are ......
Read more >Spring Boot app: Not picking up application.properties?
When a spring boot application is created it reads application.properties from the resource folder by default. You don't need to import a property...
Read more >A Suggestion on Managing Profiles in Spring Boot
1- Keeps the application.properties file truly for shared properties across all environments. · 2- Explicitly shows configurations that are meant for non- ...
Read more >How to Use Profiles in Spring Boot - DZone Java
This is simple — properties files! We make properties files for each environment and set the profile in the application accordingly, so it...
Read more >Kogito Documentation - Red Hat on GitHub
When you pass an add-on to the property, the add-on name does not require the ... starts the application in devmode $ mvn...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@stuartwdouglas, The only reason I can think of why the user might have changed the value is probably because that port is already being used by some other process. In that case the dev mode startup itself would (should) fail and that would mean changing the port in the application.properties will actually be hot deployed. So I personally don’t see any genuine use case where we might want to support changing this port after a successful dev mode startup. But, maybe we should at least log a WARN if we do detect this change in port during hot deployment, so that at least users are aware that the new port isn’t being used?
http.port will never work, as hot replacement is based on HTTP requests. I could make it work if we really want it but I don’t really think it is worth it?