ARTEMIS-5725 parameterize project name in the docs

This commit adds a few parameters to the doc build and uses those
parameters throughout the docs. Changes include:

 - Eliminating unnecessary uses of the full project name
 - Updating punctuation to increase clarity
 - Fixing spelling, spacing, & captitalization for consistency

Author: jbertram

artemis-website/pom.xml

@@ -381,6 +381,9 @@
 
                         <!-- Version substitution attributes -->
                         <project-version>${project.version}</project-version>
+                        <project-name-full>Apache ActiveMQ Artemis</project-name-full>
+                        <project-name-full-url>apache-activemq-artemis</project-name-full-url>
+                        <project-name-short>ActiveMQ Artemis</project-name-short>
                         <log4j-version>${log4j.version}</log4j-version>
                      </attributes>
                      <logHandler>

docs/hacking-guide/_building.adoc

@@ -64,11 +64,15 @@ $ mvn -o ...
 
 == Building the ASYNC IO library
 
-ActiveMQ Artemis provides the `ASYNCIO` `journal-type` which interacts with the Linux kernel libaio library. The ASYNCIO journal type should be used where possible as it is far superior in terms of performance.
+The `ASYNCIO` `journal-type` which interacts with the Linux kernel libaio library.
+The ASYNCIO journal type should be used where possible as it is far superior in terms of performance.
 
-ActiveMQ Artemis does not ship with the Artemis Native ASYNCIO library in the _source_ distribution. This need to be built prior to running `mvn install`, to ensure that the ASYNCIO journal type is available in the resulting build. Don't worry if you don't want to use ASYNCIO or your system does not support libaio, ActiveMQ Artemis will check at runtime to see if the required libraries and system dependencies are available, if not it will default to using NIO.
+The ASYNCIO native library is not included in the broker _source_ distribution.
+It needs to be built prior to running `mvn install` to ensure that the ASYNCIO journal type is available in the resulting build.
+Don't worry if you don't want to use ASYNCIO or your system does not support libaio.
+The broker will check at runtime to see if the required libraries and system dependencies are available and, if not, it will default to using NIO.
 
-To build the ActiveMQ Artemis ASYNCIO native libraries, please follow link:https://github.com/apache/activemq-artemis-native[these instructions].
+To build the ASYNCIO native libraries, please follow link:https://github.com/apache/activemq-artemis-native[these instructions].
 
 == Open Web Application Security Project (OWASP) Report
 

docs/hacking-guide/_code-coverage-report.adoc

@@ -19,9 +19,9 @@ $ mvn verify -Pjacoco-generate-report -DskipTests
 For generating JaCoCo reports only run the maven build with profile `jacoco-generate-report` as it is shown in the example above.
 After the command was executed, in directory `target/jacoco-report` you can find reports in HTML and XML formats.
 
-== Merge JaCoCo exec files to one
+== Merge JaCoCo exec files into one
 
-Since ActiveMQ Artemis is divided into several modules, exec files are generated for each module separately.
+JaCoCo exec files are generated for each module separately.
 If you need to merge them together to have all data in one place, you can do it by command below.
 [,console]
 ----

docs/hacking-guide/_code.adoc

@@ -1,6 +1,6 @@
 = Working with the Code
 
-While the canonical Apache ActiveMQ Artemis git repository is hosted on Apache hardware at https://gitbox.apache.org/repos/asf/activemq-artemis.git contributors are encouraged (but not required) to use a mirror on GitHub for collaboration and pull-request review functionality.
+While the canonical git repository is hosted on Apache hardware at https://gitbox.apache.org/repos/asf/activemq-artemis.git contributors are encouraged (but not required) to use a mirror on GitHub for collaboration and pull-request review functionality.
 Follow the steps below to get set up with GitHub, etc.
 
 If you do not wish to use GitHub for whatever reason you can follow the overall process outlined in the "Typical development cycle" section below but instead attach https://git-scm.com/docs/git-format-patch[a patch file] to the related JIRA or an email to the http://activemq.apache.org/mailing-lists.html[dev list].
@@ -86,7 +86,7 @@ $ git commit
 [#commitMessageDetails]
 When you commit your changes you will need to supply a commit message.
 We follow the  50/72 git commit message format as recommended in the https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project[official Git book].
-An ActiveMQ Artemis commit message should be formatted in the following manner:
+The commit message should be formatted in the following manner:
 
 .. Add the first line with the summary, using maximum 50 characters.
 Start the summary with the jira key (ARTEMIS-XXX) followed by a brief description of the change.
@@ -184,8 +184,8 @@ You might need to specify `-f` to force the changes.
 Due to incompatibilities between some open source licenses and the Apache v2.0 license (that this project is licensed under) care must be taken when adding new dependencies to the project.
 The Apache Software Foundation 3rd party licensing  policy has more information here: https://www.apache.org/legal/3party.html
 
-To keep track of all licenses in ActiveMQ Artemis, new dependencies must be added in either the top level `pom.xml` or in `test/pom.xml` (depending on whether this is a test only dependency or if it is used in the main code base).
-The dependency should be added under the dependency management section with version and labelled with a comment highlighting the license for the dependency version.
+To keep track of all licenses, new dependencies must be added in either the top level `pom.xml` or in `test/pom.xml` (depending on whether this is a test-only dependency or if it is used in the main code base).
+The dependency should be added under the dependency management section with version and labeled with a comment highlighting the license for the dependency version.
 See existing dependencies in the main `pom.xml` for examples.
-The dependency can then be added to individual ActiveMQ Artemis modules _without_ the version specified (the version is implied from the dependency management section of the top level pom).
-This allows ActiveMQ Artemis developers to keep track of all dependencies and licenses.
+The dependency can then be added to individual modules _without_ the version specified (the version is implied from the dependency management section of the top level pom).
+This allows developers to keep track of all dependencies and licenses.

docs/hacking-guide/_history.adoc

@@ -1,8 +1,7 @@
 = History
 
-The Apache ActiveMQ Artemis project was started in October 2014.
-The Artemis code base was seeded with a code donation granted by Red Hat, of the HornetQ project.
-The code donation process consisted of taking a snapshot of the latest HornetQ code base and contributing this snapshot as an https://issues.apache.org/jira/browse/ARTEMIS-1[initial git commit] into the Artemis git repository.
+In October 2014 the {project-name-full} code-base was seeded with a donation of the HornetQ project from Red Hat.
+The code donation process consisted of taking a snapshot of the latest HornetQ code base and contributing it as the https://issues.apache.org/jira/browse/ARTEMIS-1[initial commit] into the corresponding Git repository.
 
 The HornetQ commit history is preserved and can be accessed here: https://github.com/hornetq/hornetq/tree/apache-donation
 

docs/hacking-guide/_maintainers.adoc

@@ -1,8 +1,8 @@
 = Notes for Maintainers
 
-ActiveMQ Artemis committers have write access to the Apache ActiveMQ Artemis repositories and will be responsible for acknowledging and pushing commits contributed via pull requests on GitHub.
+Committers have write access to all project repositories and will be responsible for acknowledging and pushing commits contributed via pull requests on GitHub.
 
-Core ActiveMQ Artemis members are also able to push their own commits directly to the canonical Apache repository.
+Core members are also able to push their own commits directly to the canonical Apache repository.
 However, the expectation here is that the developer has made a good effort to test their changes and is reasonably confident that the changes that are being committed will not break the build.
 
 What does it mean to be reasonably confident?

docs/hacking-guide/_validating-releases.adoc

@@ -60,7 +60,7 @@ After you configure this, all the maven objects will be available to your builds
 
 == Using the examples
 
-The Apache ActiveMQ Artemis examples will create servers and use most of the maven components as real application were supposed to do.
+The examples will create servers and use most of the maven components as real application were supposed to do.
 You can do this by running these examples after the `.m2` profile installations for the staged repository.
 
-Of course you can use your own applications after you have staged the maven repository.
+Of course, you can use your own applications after you have staged the maven repository.

docs/hacking-guide/index.adoc

@@ -1,6 +1,6 @@
-= Apache ActiveMQ Artemis Hacking Guide
+= {project-name-full} Hacking Guide
 
-This hacking guide outlines how developers can get involved in contributing to the Apache ActiveMQ Artemis project.
+This hacking guide outlines how developers can get involved in contributing to the {project-name-full} project.
 
 include::_code.adoc[leveloffset=1]
 include::_building.adoc[leveloffset=1]

docs/migration-guide/_authentication.adoc

@@ -1,12 +1,12 @@
 = Authentication
 
 Now that we have our acceptors and addresses ready, it's time to deal with broker security.
-Artemis inherited most of the security concepts from ActiveMQ.
-One of the most notable differences is that ActiveMQ _groups_ are now called _roles_ in Artemis.
+{project-name-short} inherited most of the security concepts from ActiveMQ.
+One of the most notable differences is that ActiveMQ _groups_ are now called _roles_ in {project-name-short}.
 Besides that things should be pretty familiar to existing ActiveMQ users.
 Let's start by looking into the authentication mechanisms and defining users and roles (groups).
 
-Both ActiveMQ and Artemis use JAAS to define authentication credentials.
+Both ActiveMQ and {project-name-short} use JAAS to define authentication credentials.
 In ActiveMQ, that's configured through the appropriate broker plugin in `conf/activemq.xml`
 
 [,xml]
@@ -18,18 +18,18 @@ In ActiveMQ, that's configured through the appropriate broker plugin in `conf/ac
 
 The name of the JAAS domain is specified as a configuration parameter.
 
-In Artemis, the same thing is achieved by defining `<jaas-security>` configuration in `etc/bootstrap.xml`
+In {project-name-short}, the same thing is achieved by defining `<jaas-security>` configuration in `etc/bootstrap.xml`
 
 [,xml]
 ----
 <jaas-security domain="activemq"/>
 ----
 
 From this point on, you can go and define your users and their roles in appropriate files, like `conf/users.properties` and `conf/groups.properties` in ActiveMQ.
-Similarly, `etc/artemis-users.properties` and `etc/artemis-roles.properties` files are used in Artemis.
+Similarly, `etc/artemis-users.properties` and `etc/artemis-roles.properties` files are used in {project-name-short}.
 These files are interchangeable, so you should be able to just copy your existing configuration over to the new broker.
 
 If your deployment is more complicated than this and requires some advanced JAAS configuration, you'll need go and change the `etc/login.config` file.
-It's important to say that all custom JAAS modules and configuration you were using in ActiveMQ should be compatible with Artemis.
+It's important to say that all custom JAAS modules and configuration you were using in ActiveMQ should be compatible with {project-name-short}.
 
-Finally, in case you're still using ActiveMQ's _Simple Authentication Plugin_, which defines users and groups directly in the broker's xml configuration file, you'll need to migrate to JAAS as Artemis doesn't support the similar concept.
+Finally, in case you're still using ActiveMQ's _Simple Authentication Plugin_, which defines users and groups directly in the broker's xml configuration file, you'll need to migrate to JAAS as {project-name-short} doesn't support the similar concept.

docs/migration-guide/_authorization.adoc

@@ -22,7 +22,7 @@ In ActiveMQ, authorization is specified using the appropriate broker plugin in `
 </authorizationPlugin>
 ----
 
-The equivalent Artemis configuration is specified in `etc/broker.xml` and should look like this
+The equivalent {project-name-short} configuration is specified in `etc/broker.xml` and should look like this
 
 [,xml]
 ----
@@ -60,24 +60,24 @@ The equivalent Artemis configuration is specified in `etc/broker.xml` and should
 ----
 
 As you can see, things are pretty comparable with some minor differences.
-The most important one is that policies in ActiveMQ are defined on destination names, while in Artemis they are applied to _core queues_ (refresh your knowledge about relation between queues and addresses in previous sections and Artemis user manual).
+The most important one is that policies in ActiveMQ are defined on destination names, while in {project-name-short} they are applied to _core queues_ (refresh your knowledge about relation between queues and addresses in previous sections and {project-name-short} user manual).
 
-The other notable difference is that policies are more fine-grained in Artemis.
-The following paragraphs and tables show Artemis policies that corresponds to ActiveMQ ones.
+The other notable difference is that policies are more fine-grained in {project-name-short}.
+The following paragraphs and tables show {project-name-short} policies that corresponds to ActiveMQ ones.
 
 If you wish to allow users to send messages, you need to define the following policies in the respective brokers.
 
 |===
-| ActiveMQ | Artemis
+| ActiveMQ | {project-name-short}
 
 | write
 | send
 |===
 
-In Artemis, policies for consuming and browsing are separated and you need to define them both in order to control `read` access to the destination.
+In {project-name-short}, policies for consuming and browsing are separated and you need to define them both in order to control `read` access to the destination.
 
 |===
-| ActiveMQ | Artemis
+| ActiveMQ | {project-name-short}
 
 | read
 | consume
@@ -90,7 +90,7 @@ It's the same story with `admin` privileges.
 You need to define separate create and delete policies for durable and non-durable core queues.
 
 |===
-| ActiveMQ | Artemis
+| ActiveMQ | {project-name-short}
 
 | admin
 | createNonDurableQueue
@@ -109,7 +109,7 @@ Finally, there's a topic of using wildcards to define policies.
 The following table shows the wildcard syntax difference.
 
 |===
-| Wildcard | Description | ActiveMQ | Artemis
+| Wildcard | Description | ActiveMQ | {project-name-short}
 
 | Delimiter
 | Separates words in the path
@@ -127,6 +127,6 @@ The following table shows the wildcard syntax difference.
 | #
 |===
 
-Basically, by default only the _any word_ character is different, so that's why we used `GUESTS.#` in Artemis example instead of ActiveMQ's `GUESTS.>` syntax.
+Basically, by default only the _any word_ character is different, so that's why we used `GUESTS.#` in {project-name-short} example instead of ActiveMQ's `GUESTS.>` syntax.
 
-Powered with this knowledge, you should be able to transform your current ActiveMQ authorization policies to Artemis.
+Powered with this knowledge, you should be able to transform your current ActiveMQ authorization policies to {project-name-short}.