Document bootstrap config options and tooling

docs/src/main/asciidoc/getting-started-testing.adoc

@@ -302,6 +302,16 @@ it will take effect all the time, not just when testing.
 Note that at present this approach does not work with native image testing, as this would required the test alternatives
 to be baked into the native image.
 
+== Test Bootstrap Configuration Options
+
+There are a few system properties that can be used to tune the bootstrap of the test, specifically its classpath.
+
+* *quarkus-bootstrap-offline* - _(boolean)_ if set by the user, depending on the value, will enable or disable the offline mode for the Maven artifact resolver used by the bootstrap to resolve the deployment dependencies of the Quarkus extensions used in the test. If the property is not set to any value, the artifact resolver will use the system's default (user's `settings.xml`).
+
+* *quarkus-workspace-discovery* - _(boolean)_ controls whether the bootstrap artifact resolver should look for the test dependencies among the projects in the current workspace and use their output (`classes`) directories when setting up the classpath for the test to run. *The default value is true*.
+
+* *quarkus-classpath-cache* - _(boolean)_ enables or disables the bootstrap classpath cache. With the number of the project dependencies growing, the dependency resolution will take more time which could at some point become annoying. The Quarkus bootstrap allows to cache the resolved classpath and store it in the output directory of the project. The cached classpath will be recalculated only after any of the `pom.xml` file in the workspace has been changed. The cache directory is also removed each time the project's output directory is cleaned, of course. *The default value is true*.
+
 == Native Executable Testing
 
 It is also possible to test native executables using `@SubstrateTest`. This supports all the features mentioned in this

docs/src/main/asciidoc/maven-tooling.adoc

@@ -213,6 +213,38 @@ In a separated terminal or the embedded terminal, go to the project root and run
 
 Open the project directory in VS Code. If you have installed the Java Extension Pack (grouping a set of Java extensions), the project is loaded as a Maven project.
 
+== Logging Quarkus application build classpath tree
+
+Usually, dependencies of an application (which is a Maven project) could be displayed using `mvn dependency:tree` command. In case of a Quarkus application, however, this command will list only the runtime dependencies of the application.
+Given that the Quarkus build process adds deployment dependencies of the extensions used in the application to the original application classpath, it could be useful to know which dependencies and which versions end up on the build classpath.
+Luckily, the `quarkus-bootstrap` Maven plugin includes the `build-tree` goal which displays the build dependency tree for the application.
+
+To be able to use it, the following plugin configuration has to be added to the `pom.xml`:
+
+[source,xml,subs=attributes+]
+----
+            <plugin>
+                <groupId>io.quarkus</groupId>
+                <artifactId>quarkus-bootstrap-maven-plugin</artifactId>
+                <version>${quarkus.version}</version>
+            </plugin>
+----
+
+Now you should be able to execute `mvn quarkus-bootstrap:build-tree` on your project and see something like:
+
+[source,shell,subs=attributes+]
+----
+[INFO] --- quarkus-bootstrap-maven-plugin:{quarkus-version}:build-tree (default-cli) @ getting-started ---
+[INFO] org.acme:getting-started:jar:1.0-SNAPSHOT
+[INFO] └─ io.quarkus:quarkus-resteasy-deployment:jar:{quarkus-version} (compile)
+[INFO]    ├─ io.quarkus:quarkus-resteasy-server-common-deployment:jar:{quarkus-version} (compile)
+[INFO]    │  ├─ io.quarkus:quarkus-core-deployment:jar:{quarkus-version} (compile)
+[INFO]    │  │  ├─ commons-beanutils:commons-beanutils:jar:1.9.3 (compile)
+[INFO]    │  │  │  ├─ commons-logging:commons-logging:jar:1.2 (compile)
+[INFO]    │  │  │  └─ commons-collections:commons-collections:jar:3.2.2 (compile)
+...
+----
+
 == Building a native executable
 
 Native executables make {project-name} applications ideal for containers and serverless workloads.