[felix-antora-site] branch main updated: Update release-management-nexus.adoc

[ro...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rotty3000 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git


The following commit(s) were added to refs/heads/main by this push:
     new 8da4ff16 Update release-management-nexus.adoc
8da4ff16 is described below

commit 8da4ff160312d3daed9e232f5ffd58a5e26a56bd
Author: Raymond Augé <ro...@apache.org>
AuthorDate: Mon Apr 4 22:26:55 2022 -0400

    Update release-management-nexus.adoc
---
 .../development/release-management-nexus.adoc      | 27 ++++++++++++++++++----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/modules/ROOT/pages/development/release-management-nexus.adoc b/modules/ROOT/pages/development/release-management-nexus.adoc
index eed8e917..a5a8ed30 100644
--- a/modules/ROOT/pages/development/release-management-nexus.adoc
+++ b/modules/ROOT/pages/development/release-management-nexus.adoc
@@ -70,7 +70,11 @@ Remember to update the copyright year.
 . Make sure you have an updated change log file, typically in `doc/changelog.txt` but in the project root is also acceptable.
 . Make sure there are no snapshots in the POMs to be released
 . Check that your POMs will not lose content when they are rewritten during the release process
- ** `mvn release:prepare -DdryRun=true`
++
+[source,bash]
+----
+mvn release:prepare -DdryRun=true
+----
  ** diff the original `pom.xml` with the one called `pom.xml.tag` to see if the license or any other info has been removed.
 This has been known to happen if the starting `<project>` tag is not on a single line.
 The only things that should be different between these files are the `<version>` and `<scm>` elements.
@@ -79,8 +83,14 @@ If there are any other changes, you must fix the original `pom.xml` file and com
 This is useful for existing builds that still depend on a snapshot version of this artifact.
 It means that the snapshot they will be getting is effectively the same as the released version.
 +
-`+$ mvn deploy     ...
-[INFO] [deploy:deploy]    [INFO] Retrieving previous build number from apache.snapshots.https    ...+`
+[source,bash]
+----
+$ mvn deploy
+...
+[INFO] [deploy:deploy]
+[INFO] Retrieving previous build number from apache.snapshots.https
+...
+----
  ** if you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the _Prerequisites_
  ** be sure that the generated artifacts respect the Apache release https://www.apache.org/dev/release.html[rules]: NOTICE and LICENSE files should be present in the META-INF directory within the jar.
 For -sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken.
@@ -88,11 +98,18 @@ The recommended version at this time is 2.0.4
  ** you should verify the deployment under the https://repository.apache.org/content/groups/snapshots/org/apache/felix[snapshot] repository on Apache
 . Prepare the release
 +
-`$ mvn release:clean      $ mvn release:prepare`
+[source,shell]
+----
+$ mvn release:clean
+$ mvn release:prepare
+----
  ** preparing the release will create the new tag in git, automatically checking in on your behalf
 . Stage the release for a vote
 +
-`$ mvn release:perform`
+[source,shell]
+----
+$ mvn release:perform
+----
  ** the release will automatically be inserted into a temporary staging repository for you, see the Nexus https://www.sonatype.com/books/nexus-book/reference/staging.html[staging documentation] for full details
  ** you can continue to use `mvn release:prepare` and `mvn release:perform` on other sub-projects as necessary on the same machine and they will be combined in the same staging repository - this is useful when making a release of the Felix framework and its associated bundles.
 . Close the staging repository