quarkusio · gsmet · Mar 5, 2019 · Mar 4, 2019
diff --git a/docs/src/main/asciidoc/extension-authors-guide.adoc b/docs/src/main/asciidoc/extension-authors-guide.adoc
@@ -163,7 +163,7 @@ Configuration in Quarkus is based on SmallRye Config, an implementation of the M
 All of the standard features of MP-Config are supported; in addition, there are several extensions which are made available
 by the SmallRye Config project as well as by Quarkus itself.
 
-The value of these properties is configured in a `META-INF/microprofile-config.properties` file that conforms to the MicroProfile config format.
+The value of these properties is configured in a `application.properties` file that follows the MicroProfile config format.
 
 Configuration of Quarkus extensions is injection-based, using annotations.
 
@@ -344,7 +344,7 @@ key type.
 <2> The `@ConfigRoot` annotation indicates that this object is a configuration root group, whose property names will have a parent only of `quarkus.`.  In this case the properties within the group will begin with `quarkus.log.*`.
 <3> Here the `LoggingProcessor` injects a `LogConfiguration` instance automatically by detecting the `@ConfigRoot` annotation.
 
-A corresponding `META-INF/microprofile-config.properties` file for the `File` values could be:
+A corresponding `application.properties` file for the `File` values could be:
 [source%nowrap,properties]
 ----
 quarkus.log.file.enable=true
@@ -496,13 +496,13 @@ public class PersistenceAndQuarkusConfigTest {
             .setExpectedException(ConfigurationError.class)                     <1>
             .setArchiveProducer(() -> ShrinkWrap.create(JavaArchive.class)
                     .addAsManifestResource("META-INF/some-persistence.xml", "persistence.xml")
-                    .addAsManifestResource("META-INF/microprofile-config.properties"));
+                    .addAsResource("application.properties"));
 
     @Test
     public void testPersistenceAndConfigTest() {
         // should not be called, deployment exception should happen first:
         // it's illegal to have Hibernate configuration properties in both the
-        // microprofile-config.properties an in the persistence.xml
+        // application.properties and in the persistence.xml
         Assertions.fail();
     }
 

diff --git a/docs/src/main/asciidoc/hibernate-orm-guide.adoc b/docs/src/main/asciidoc/hibernate-orm-guide.adoc
@@ -1,5 +1,5 @@
 = {project-name} - Using Hibernate ORM and JPA
-:config-file: microprofile-config.properties
+:config-file: application.properties
 
 Hibernate ORM is the de facto JPA implementation and offers you the full breath of an Object Relational Mapper.
 It works beautifully in {project-name}.

diff --git a/docs/src/main/asciidoc/infinispan-client-guide.adoc b/docs/src/main/asciidoc/infinispan-client-guide.adoc
@@ -25,8 +25,8 @@ This will add the following to your pom.xml
     </dependency>
 ----
 
-The Infinispan client is configurable in the `microprofile-config.properties` file that can be
-provided in the `META-INF` directory. These are the properties that
+The Infinispan client is configurable in the `application.properties` file that can be
+provided in the `src/main/resources` directory. These are the properties that
 can be configured in this file:
 
 [cols=3*,options="header"]

diff --git a/docs/src/main/asciidoc/jwt-guide.adoc b/docs/src/main/asciidoc/jwt-guide.adoc
@@ -265,12 +265,12 @@ Excellent, we have not provided any JWT in the request, so we should not be able
 
 == Configuring the {extension-name} Extension Security Information
 
-In the <<Configuration>> section we introduce the microprofile-config.properties that affect the {extension-name} extension.
+In the <<Configuration>> section we introduce the `application.properties` file that affect the {extension-name} extension.
 
-=== Setting up microprofile-config.properties
- For part A of step 1, create a using-jwt-rbac/src/main/resources/META-INF/microprofile-config.properties with the following content:
+=== Setting up application.properties
+ For part A of step 1, create a using-jwt-rbac/src/main/resources/application.properties with the following content:
 
-.META-INF/microprofile-config.properties for TokenSecuredResource
+.application.properties for TokenSecuredResource
 [source, properties]
 ----
 mp.jwt.verify.publickey.location=publicKey.pem #<1>

diff --git a/docs/src/main/asciidoc/native-and-ssl-guide.adoc b/docs/src/main/asciidoc/native-and-ssl-guide.adoc
@@ -24,7 +24,7 @@ The project is located in the `rest-client` {quickstarts-tree-url}/rest-client[d
 
 == Looks like it works out of the box?!?
 
-If you open the application's configuration file (`src/main/resources/META-INF/microprofile-config.properties`), you can see the following line:
+If you open the application's configuration file (`src/main/resources/application.properties`), you can see the following line:
 ```
 org.acme.restclient.CountriesService/mp-rest/url=https://restcountries.eu/rest
 ```
@@ -78,7 +78,7 @@ So if you are sure you don't need it, you can disable it entirely.
 
 First, let's disable it without changing the REST service URL and see how it goes.
 
-Open `src/main/resources/META-INF/microprofile-config.properties` and add the following line:
+Open `src/main/resources/application.properties` and add the following line:
 ```
 quarkus.ssl.native=false
 ```
@@ -95,7 +95,7 @@ Exception handling request to /country/name/greece: com.oracle.svm.core.jdk.Unsu
 
 This error is the one you obtain when trying to use SSL while it was not explicitly enabled in your native image.
 
-Now, let's change the REST service URL to **not** use SSL in `src/main/resources/META-INF/microprofile-config.properties`:
+Now, let's change the REST service URL to **not** use SSL in `src/main/resources/application.properties`:
 ```
 org.acme.restclient.CountriesService/mp-rest/url=http://restcountries.eu/rest
 ```
@@ -132,7 +132,7 @@ And there's more to it.
 
 Let's revert the changes we made to the configuration file and go back to SSL with the following command:
 ```
-git checkout -- src/main/resources/META-INF/microprofile-config.properties
+git checkout -- src/main/resources/application.properties
 ```
 
 And let's build the native image again:

diff --git a/docs/src/main/asciidoc/panache-jpa-guide.adoc b/docs/src/main/asciidoc/panache-jpa-guide.adoc
@@ -1,5 +1,5 @@
 = {project-name} - Simplified Hibernate ORM and JPA with Panache
-:config-file: microprofile-config.properties
+:config-file: application.properties
 
 Hibernate ORM is the de facto JPA implementation and offers you the full breadth of an Object Relational Mapper.
 It makes complex mappings possible, but it does not make simple and common mappings trivial.

diff --git a/docs/src/main/asciidoc/rest-client-guide.adoc b/docs/src/main/asciidoc/rest-client-guide.adoc
@@ -172,7 +172,7 @@ It will allow to narrow down the number of JAX-RS providers (which can be seen a
 
 == Create the configuration
 
-In order to determine the base URL to which REST calls will be made, the REST Client uses configuration from `META-INF/microprofile-config.properties`.
+In order to determine the base URL to which REST calls will be made, the REST Client uses configuration from `application.properties`.
 The name of the property needs to follow a certain convention which is best displayed in the following code:
 
 [source]

diff --git a/docs/src/main/asciidoc/security-guide.adoc b/docs/src/main/asciidoc/security-guide.adoc
@@ -85,7 +85,7 @@ The property files realm supports mapping of users to password and users to role
 |quarkus.security.file.roles|roles.properties|Classpath resource name of properties file containing user to role mappings; see <<Roles.properties>>
 |===
 
-.example microprofile-config.properties file section for property files realm
+.example application.properties file section for property files realm
 [source,properties]
 --
 quarkus.security.file.enabled=true
@@ -127,7 +127,7 @@ noadmin=user
 Given these role mappings, only user `scott` would be allowed to access the `/subject/secured` endpoint from the <<SubjectExposingResource Example>>.
 
 ### Embedded Realm Configuration
-The embedded realm also supports mapping of users to password and users to roles. It uses the main microprofile-config.properties Quarkus configuration file to embed this information. To enable and configure it, the following configuration properties are used:
+The embedded realm also supports mapping of users to password and users to roles. It uses the main application.properties Quarkus configuration file to embed this information. To enable and configure it, the following configuration properties are used:
 
 |===
 |Property Name|Default|Description
@@ -138,9 +138,9 @@ The embedded realm also supports mapping of users to password and users to roles
 |quarkus.security.embedded.roles.*|none|Prefix for the properties that specify user to role mappings; see <<Embedded Roles>>
 |===
 
-The following is an example microprofile-config.properties file section illustrating the embedded realm configuration:
+The following is an example application.properties file section illustrating the embedded realm configuration:
 
-.example microprofile-config.properties file section for embedded realm
+.example application.properties file section for embedded realm
 [source,properties]
 ----
 quarkus.security.embedded.enabled=true
@@ -156,7 +156,7 @@ quarkus.security.embedded.auth-mechanism=CUSTOM
 ----
 
 #### Embedded Users
-The user to password mappings are specified in the microprofile-config.properties by property names of the form `quarkus.security.embedded.users.<user>=<password>`. The following <<Example Passwords>> illustrates the syntax with the 4 user to password mappings shown in lines 2-5:
+The user to password mappings are specified in the `application.properties` file by property names of the form `quarkus.security.embedded.users.<user>=<password>`. The following <<Example Passwords>> illustrates the syntax with the 4 user to password mappings shown in lines 2-5:
 
 .Example Passwords
 [source,properties,linenums,highlight='2-5']
@@ -175,7 +175,7 @@ quarkus.security.embedded.roles.noadmin=user
 <2> User `stuart` has password `test`
 
 #### Embedded Roles
-The user to role mappings are specified in the microprofile-config.properties by property names of the form `quarkus.security.embedded.roles.<user>=role1[,role2[,role3[,...]]]`. The following <<Example Roles>> illustrates the syntax with the 4 user to role mappings shown in lines 6-9:
+The user to role mappings are specified in the `application.properties` file by property names of the form `quarkus.security.embedded.roles.<user>=role1[,role2[,role3[,...]]]`. The following <<Example Roles>> illustrates the syntax with the 4 user to role mappings shown in lines 6-9:
 
 .Example Roles
 [source,properties,linenums,highlight='6-9']

diff --git a/docs/src/main/asciidoc/spring-di-guide.adoc b/docs/src/main/asciidoc/spring-di-guide.adoc
@@ -119,7 +119,7 @@ public class NoOpSingleStringFunction implements StringFunction {
 ----
 
 {project-name} also provides support for injecting configuration values using Spring's `@Value` annotation.
-To see that in action, first edit the `src/main/resources/META-INF/microprofile-config.properties` with the following content:
+To see that in action, first edit the `src/main/resources/application.properties` with the following content:
 
 [source]
 ----
@@ -189,7 +189,7 @@ public class GreeterBean {
 ----
 
 In the code above, we see that both field injection and constructor injection are being used (note that constructor injection does not need the `@Autowired` annotation since there is a single constructor).
-Furthermore, the `@Value` annotation on `suffix` has also a default value defined, which in this case will be used since we have not defined `greeting.suffix` in `microprofile-config.properties`.
+Furthermore, the `@Value` annotation on `suffix` has also a default value defined, which in this case will be used since we have not defined `greeting.suffix` in `application.properties`.
 
 
 === Update the JAX-RS resource