Sync documentation of main branch

_versions/main/guides/deploying-to-heroku.adoc

@@ -17,16 +17,16 @@ This guide covers:
 * Install the Heroku CLI
 * Deploy the application to Heroku
 * Deploy the application as container image to Heroku
-  * Using Docker
-  * Using Podman
+** Using Docker
+** Using Podman
 * Deploy the native application as container image to Heroku
 
 == Prerequisites
 
 :prerequisites-time: 1 hour for all modalities
 :prerequisites-no-graalvm:
 include::{includes}/prerequisites.adoc[]
-* https://www.heroku.com/[A Heroku Account]. Free accounts work.
+* https://www.heroku.com/[A Heroku Account]. You need at least an Eco account to deploy an application.
 * https://devcenter.heroku.com/articles/heroku-cli[Heroku CLI installed]
 
 == Introduction
@@ -46,10 +46,20 @@ Luckily, there's a dynamic configuration property for it.
 
 == Common project setup
 
-This guide will take as input an application developed in the xref:getting-started.adoc[Getting Started guide].
+This guide will take as input a simple application created with the Quarkus tooling:
 
-Make sure you have the getting-started application at hand, or clone the Git repository: `git clone {quickstarts-clone-url}`,
-or download an {quickstarts-archive-url}[archive]. The solution is located in the `getting-started` directory.
+:create-app-artifact-id: getting-started-with-heroku
+:create-app-code:
+include::{includes}/devtools/create-app.adoc[]
+
+This command will create a new REST application in the `getting-started-with-heroku` directory.
+
+Let's make this application a Git repository:
+
+1. Change to the application directory: `cd getting-started-with-heroku`.
+2. Initialize a new Git repository: `git init -b main`.
+3. Add all files to the repository: `git add .`.
+4. Commit the files: `git commit -a -m 'Initial copy of getting-started'`.
 
 Heroku can react on changes in your repository, run CI and redeploy your application when your code changes.
 Therefore, we start with a valid repository already.
@@ -110,25 +120,39 @@ git add Procfile
 git commit -am "Add a Procfile."
 ----
 
-Your application should already be runnable via `heroku local web`.
+Your application should already be runnable via `heroku local web` from the repository root directory. You need to have run `mvn package` before to create the runnable jar for this to succeed.
 
-Let's create an application in your account and deploy that repository to it:
+Now let's create an application in your account and deploy that repository to it:
 
 [source,bash]
 ----
 heroku create
-git push heroku master
-heroku open
 ----
 
-The application will have a generated name and the terminal should output that. `heroku open` opens your default browser to access your new application.
+This will create a remote repository in your Heroku account, and it should have also added a heroku remote url to your local repository which you can view using `git remote -v`:
+[source,bash]
+----
+starksm@Scotts-Mac-Studio getting-started % git remote -v
+heroku	https://git.heroku.com/young-shelf-58876.git (fetch)
+heroku	https://git.heroku.com/young-shelf-58876.git (push)
+----
+
+Now you can push your application to Heroku and open it in your browser.
+[source,bash]
+----
+git push heroku main
+heroku open hello
+----
+
+The application will have a generated URL and the terminal should output that. `heroku open hello` opens your default browser to access your new application using the '/hello' context. That page should output the text 'hello'.
 
-To access the REST endpoint via curl, run:
+To access the REST endpoint via curl, get the app URL from the heroku info command:
 
 [source,bash]
 ----
-APP_NAME=`heroku info | grep  "=== .*" |sed "s/=== //"`
-curl $APP_NAME.herokuapp.com/hello
+heroku info | grep  "Web URL:"
+APP_NAME=<https url info>
+curl $APP_NAME/hello
 ----
 
 Of course, you can use the Heroku CLI to connect this repo to your GitHub account, too, but this is out of scope for this guide.
@@ -137,18 +161,23 @@ Of course, you can use the Heroku CLI to connect this repo to your GitHub accoun
 
 The advantage of pushing a whole container is that we are in complete control over its content and maybe even choose to deploy a container with a native executable running on GraalVM.
 
+
 First, login to Heroku's container registry:
 
 [source,bash]
 -----
 heroku container:login
 -----
 
-We need to add an extension to our project to build container images via the Quarkus Maven plugin:
+We need to add an extension to our project to add the capability to build container images:
+
+:add-extension-extensions: container-image-docker
+include::{includes}/devtools/extension-add.adoc[]
+
+Then, let's commit this change:
 
 [source,bash]
 ----
-mvn quarkus:add-extension -Dextensions="container-image-docker"
 git add pom.xml
 git commit -am "Add container-image-docker extension."
 ----
@@ -159,7 +188,7 @@ We get the generated name via `heroku info` and pass it on to the (local) build:
 [source,bash]
 ----
 APP_NAME=`heroku info | grep  "=== .*" |sed "s/=== //"`
-mvn clean package\
+./mvnw clean package\
   -Dquarkus.container-image.build=true\
   -Dquarkus.container-image.group=registry.heroku.com/$APP_NAME\
   -Dquarkus.container-image.name=web\
@@ -183,6 +212,7 @@ With Docker installed, these steps are simple:
 [source,bash]
 ----
 docker push registry.heroku.com/$APP_NAME/web
+heroku stack:set container
 heroku container:release web --app $APP_NAME
 ----
 
@@ -238,12 +268,12 @@ We opt in to compiling a native image inside a local container, so that we don't
 [source,bash]
 ----
 APP_NAME=`heroku info | grep  "=== .*" |sed "s/=== //"`
-mvn clean package\
-  -Dquarkus.container-image.build=true\
-  -Dquarkus.container-image.group=registry.heroku.com/$APP_NAME\
-  -Dquarkus.container-image.name=web\
-  -Dquarkus.container-image.tag=latest\
-  -Dnative\
+./mvnw clean package \
+  -Dquarkus.container-image.build=true \
+  -Dquarkus.container-image.group=registry.heroku.com/$APP_NAME \
+  -Dquarkus.container-image.name=web \
+  -Dquarkus.container-image.tag=latest \
+  -Dnative \
   -Dquarkus.native.container-build=true
 ----
 

_versions/main/guides/getting-started-reactive.adoc

@@ -36,7 +36,7 @@ include::{includes}/prerequisites.adoc[]
 
 NOTE: Verify that Maven is using the Java version you expect.
 If you have multiple JDKs installed, make sure Maven is using the expected one.
-You can verify which JDK Maven uses by running `mvn --version.`
+You can verify which JDK Maven uses by running `mvn --version`.
 
 == Imperative vs. Reactive: a question of threads
 

_versions/main/guides/maven-tooling.adoc

@@ -652,7 +652,7 @@ Uber-Jar's final name is configurable via a Maven's build settings `finalName` o
 
 ==== Uber-Jar file name suffix
 
-By default the generated uber JAR file name will have the `-runner` suffix, unless it was overridden by configuring a custom one with `quarkus.package.runner-suffix` configuration option.
+By default the generated uber JAR file name will have the `-runner` suffix, unless it was overridden by configuring a custom one with `quarkus.package.jar.runner-suffix` configuration option.
 If the runner suffix is not desired, it can be disabled by setting `quarkus.package.jar.add-runner-suffix` configuration option to `false`, in which case the uber JAR will replace the original JAR
 file generated by `maven-jar-plugin` for the application module.
 

_versions/main/guides/smallrye-fault-tolerance.adoc

@@ -576,7 +576,7 @@ implementation("io.quarkus:quarkus-smallrye-fault-tolerance")
 == Additional resources
 
 SmallRye Fault Tolerance has more features than shown here.
-Please check the link:https://smallrye.io/docs/smallrye-fault-tolerance/6.7.1/index.html[SmallRye Fault Tolerance documentation] to learn about them.
+Please check the link:https://smallrye.io/docs/smallrye-fault-tolerance/6.7.2/index.html[SmallRye Fault Tolerance documentation] to learn about them.
 
 In Quarkus, you can use the SmallRye Fault Tolerance optional features out of the box.
 
@@ -608,7 +608,7 @@ quarkus.fault-tolerance.mp-compatibility=true
 ----
 ====
 
-The link:https://smallrye.io/docs/smallrye-fault-tolerance/6.7.1/reference/programmatic-api.html[programmatic API] is present and integrated with the declarative, annotation-based API.
+The link:https://smallrye.io/docs/smallrye-fault-tolerance/6.7.2/reference/programmatic-api.html[programmatic API] is present and integrated with the declarative, annotation-based API.
 You can use the `Guard`, `TypedGuard` and `@ApplyGuard` APIs out of the box.
 
 Support for Kotlin is present (assuming you use the Quarkus extension for Kotlin), so you can guard your `suspend` functions with fault tolerance annotations.