Configuration defines how an application and its extensions receive and access settings. Quarkus consolidates framework and application properties in application.properties, normally under src/main/resources, instead of requiring separate configuration styles for each framework. section 1.4 section 3.2
Quarkus configuration supports several practical uses:
- Configure extension behavior and built-in features through extension-provided properties, while keeping application-specific settings in the same file. section 3.2
- Access declared properties from application code through the MicroProfile Config API. section 3.2
- Override properties with environment variables or system properties using names derived from the configuration keys. section 3.2
- Separate build-time settings from runtime settings when an extension must act during application construction. section 12.1.3
A build-time extension property
An extension can define quarkus.metadata.path with a default of /metadata. Marking the configuration root as BUILD_TIME makes the endpoint path available during build and prevents meaningful runtime changes. section 12.3.2
Build-time versus runtime
A Swagger UI title is build-time configuration because Quarkus generates the HTML during the build. quarkus.http.port is runtime configuration because the application binds its HTTP interface only when it starts. section 12.1.3
Figure 1.3 An overview of the Quarkus architecture in layers. Extensions that provide support for various frameworks are built around the core layer.
Use the layered architecture view to place unified configuration in Quarkus’s core alongside extensions that contribute configurable behavior. section 1.4
