Fix documentation issues in site docs

src/site/apt/examples/class-relocation.apt.vm

@@ -81,10 +81,10 @@ Relocating Classes
       <pattern>org.codehaus.plexus.util</pattern>
       <shadedPattern>org.shaded.plexus.util</shadedPattern>
       <includes>
-        <include>org.codehaud.plexus.util.io.*</include>
+        <include>org.codehaus.plexus.util.io.*</include>
       </includes>
       <excludes>
-        <exclude>org.codehaud.plexus.util.io.*</exclude>
+        <exclude>org.codehaus.plexus.util.io.*</exclude>
       </excludes>
     </relocation>
   ...

src/site/apt/examples/includes-excludes.apt.vm

@@ -154,7 +154,7 @@ Selecting Contents for Uber JAR
 
   As of version 1.6, minimizeJar will respect classes that were specifically marked for inclusion in a filter.
   Note that specifying an include filter for classes in an artifact implicitly excludes all non-specified
-  classes in that artifact. <<<\<excludeDefaults\>false\<\\excludeDefaults\>>>> will override this behavior so that all
+  classes in that artifact. <<<\<excludeDefaults\>false\<\/excludeDefaults\>>>> will override this behavior so that all
   non-specified classes still will be included though.
 
 +-----

src/site/apt/examples/resource-transformers.apt.vm

@@ -25,7 +25,7 @@
 
 Resource Transformers
 
-  Aggregating classes/resources from several artifacts into one uber JAR is straight forward as long as there is no
+  Aggregating classes/resources from several artifacts into one uber JAR is straightforward as long as there is no
   overlap. Otherwise, some kind of logic to merge resources from several JARs is required. This is where resource
   transformers kick in.
 
@@ -47,7 +47,7 @@ Resource Transformers
 *-----------------------------------------+------------------------------------------+
 | {{ManifestResourceTransformer}}         | Sets entries in the <<<MANIFEST>>>       |
 *-----------------------------------------+------------------------------------------+
-| {{PluginXmlResourceTransformer}}        | Aggregates Mavens <<<plugin.xml>>>       |
+| {{PluginXmlResourceTransformer}}        | Aggregates Maven's <<<plugin.xml>>>      |
 *-----------------------------------------+------------------------------------------+
 | {{ResourceBundleAppendingTransformer}}  | Merges ResourceBundles                  | 
 *-----------------------------------------+------------------------------------------+
@@ -105,8 +105,8 @@ Transformers in <<<org.apache.maven.plugins.shade.resource.properties>>> (availa
 
 * Relocate classes of the Maven Plugin Descriptor with the {PluginXmlResourceTransformer}
 
-  With {{{http://maven.apache.org/plugin-tools/index.html}Plugin Tools 3.0}} annotations have been introduced. Now references 
-  to classes are no longer classnames as String, but the actual Class reference. When you wanted to relocate classes, you had to
+  With {{{https://maven.apache.org/plugin-tools/index.html}Plugin Tools 3.0}}, annotations were introduced. References 
+  to classes are now real Class references rather than class names as strings. When you wanted to relocate classes, you had to
   maintain the <<<META-INF/maven/plugin.xml>>> by hand, but now this can be done with the <<<PluginXmlResourceTransformer>>>  
 
 +-----
@@ -176,7 +176,7 @@ Transformers in <<<org.apache.maven.plugins.shade.resource.properties>>> (availa
 * Merging Content of Specific Files with {AppendingTransformer}, XmlAppendingTransformer and ResourceBundleAppendingTransformer
 
   Some jars contain additional resources (such as properties files) that have the same file name. To avoid overwriting, you can
-  opt to merge them by appending their content into one file. One good example for this is when aggregating both the spring-context 
+  merge them by appending their content. One good example for this is when aggregating both the spring-context 
   and plexus-spring jars. Both of them have the <<<META-INF/spring.handlers>>> file which is used by Spring to handle XML schema 
   namespaces. You can merge the contents of all the files with that specific name using the <<<AppendingTransformer>>> as shown below:
 
@@ -525,7 +525,7 @@ Transformers in <<<org.apache.maven.plugins.shade.resource.properties>>> (availa
 
   The Apache Groovy language provides extension modules located at
   <<<META-INF/services/org.codehaus.groovy.runtime.ExtensionModule>>>, these modules use the property file format.
-  <<<GroovyResourceTransformer>>> automates the assembly of Groovy extension modules <<<NOTICE>>>.
+  <<<GroovyResourceTransformer>>> automates the assembly of Groovy extension module descriptors.
 
   For example, to simply merge the extension modules of several jars:
 

src/site/apt/examples/use-shader-other-impl.apt.vm

@@ -1,5 +1,5 @@
  ------
- Using an other Shader Implementation
+ Using another Shader Implementation
  ------
  Olivier Lamy
  ------
@@ -25,31 +25,34 @@
 
 Using your own Shader implementation
 
-  By default, the plugin provide a DefaultShader implementation but with version 1.6 you can use your own implementation.
+  By default, the plugin provides a DefaultShader implementation but with version 1.6 you can use your own implementation.
 
   Create a standard Maven project with your implementation.
 
-+-----
-
-Dependency to Plexus annotations
+  Dependency for Plexus annotations:
 
++-----
     <dependency>
       <groupId>org.codehaus.plexus</groupId>
       <artifactId>plexus-component-annotations</artifactId>
       <version>1.5.5</version>
     </dependency>
++-----
 
-Create your Shader
+  Create your Shader:
 
++-----
 @Component( role = Shader.class, hint = "mock" )
 public class MockShader
     implements Shader
 {
   // implement the interface here
 }
++-----
 
-// Use the plexus component metadata plugin in your job to generate Plexus metadata
+  Use the Plexus Component Metadata plugin in your build to generate Plexus metadata:
 
++-----
       <plugin>
         <groupId>org.codehaus.plexus</groupId>
         <artifactId>plexus-component-metadata</artifactId>

src/site/apt/index.apt.vm

@@ -25,16 +25,18 @@
 
 ${project.name}
 
- This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and
- to <shade> - i.e. rename - the packages of some of the dependencies.
+ This plugin provides the capability to package the artifact in an uber-jar, including its dependencies,
+ and to shade -- i.e. relocate -- the packages of some of the dependencies.
 
 * Goals Overview
 
-  The Shade Plugin has a single goal:
+  The Shade Plugin has 2 goals:
 
   * {{{./shade-mojo.html}shade:shade}} is bound to the <<<package>>> phase and
   is used to create a shaded jar.
 
+  * {{{./help-mojo.html}shade:help}} displays help information about the plugin.
+
 * Usage
 
   General instructions on how to use the Shade Plugin can be found on the {{{./usage.html}usage page}}. Some more
@@ -43,15 +45,15 @@ ${project.name}
   In case you still have questions regarding the plugin's usage, please feel
   free to contact the {{{./mailing-lists.html}user mailing list}}. The posts to the mailing list are archived and could
   already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching
-  the {{{./mail-lists.html}mail archive}}.
+  the {{{./mailing-lists.html}mail archive}}.
 
   If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our
   {{{./issue-management.html}issue tracker}}. When creating a new issue, please provide a comprehensive description of your
   concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason,
   entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated.
   Of course, patches are welcome, too. Contributors can check out the project from our
   {{{./scm.html}source repository}} and will find supplementary information in the
-  {{{http://maven.apache.org/guides/development/guide-helping.html}guide to helping with Maven}}.
+  {{{https://maven.apache.org/guides/development/guide-helping.html}guide to helping with Maven}}.
 
 
 * Examples

src/site/apt/usage.apt.vm

@@ -84,6 +84,12 @@ mvn package
 *-----------------------------------------+--------------------------------------+
 | XmlAppendingTransformer                 | Adds XML content to an XML resource  | 
 *-----------------------------------------+--------------------------------------+
-Transformers in <<<org.apache.maven.plugins.shade.resource>>>
+| PropertiesTransformer                   | Merges properties files using an ordinal to resolve conflicts |
+*-----------------------------------------+--------------------------------------+
+| OpenWebBeansPropertiesTransformer       | Merges Apache OpenWebBeans configuration files |
+*-----------------------------------------+--------------------------------------+
+| MicroprofileConfigTransformer           | Merges Microprofile Config properties based on an ordinal |
+*-----------------------------------------+--------------------------------------+
+Transformers in <<<org.apache.maven.plugins.shade.resource>>> and <<<org.apache.maven.plugins.shade.resource.properties>>>
 
   For more information, see {{{./examples/resource-transformers.html}samples}}.

src/site/fml/faq.fml

@@ -28,14 +28,14 @@ under the License.
      <question>Why Does My Second Shade Include The Results Of The First Execution?</question>
      <answer>
        <p>
-       By default, shade replaces with original jar with the result of shading.
+       By default, shade replaces the original jar with the result of shading.
        So, when a <code>pom.xml</code> includes two shades, 
        the second shade execution will (by default) start from the result of the 
        first shade execution.
        </p><p>
        If you're looking for two independent shades then read 
        in <a href='shade-mojo.html'>shade:shade</a> about
-       ways choose a different name for your first shade.
+       ways to choose a different name for your first shade.
        </p>
      </answer>
    </faq>