diff --git a/src/site/apt/examples/class-relocation.apt.vm b/src/site/apt/examples/class-relocation.apt.vm index 0dd62130d..4f571ebcd 100644 --- a/src/site/apt/examples/class-relocation.apt.vm +++ b/src/site/apt/examples/class-relocation.apt.vm @@ -81,10 +81,10 @@ Relocating Classes org.codehaus.plexus.util org.shaded.plexus.util - org.codehaud.plexus.util.io.* + org.codehaus.plexus.util.io.* - org.codehaud.plexus.util.io.* + org.codehaus.plexus.util.io.* ... diff --git a/src/site/apt/examples/includes-excludes.apt.vm b/src/site/apt/examples/includes-excludes.apt.vm index 40b2e6099..400f7186f 100644 --- a/src/site/apt/examples/includes-excludes.apt.vm +++ b/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. <<<\false\<\\excludeDefaults\>>>> will override this behavior so that all + classes in that artifact. <<<\false\<\/excludeDefaults\>>>> will override this behavior so that all non-specified classes still will be included though. +----- diff --git a/src/site/apt/examples/resource-transformers.apt.vm b/src/site/apt/examples/resource-transformers.apt.vm index 4af315a39..cfcd6309d 100644 --- a/src/site/apt/examples/resource-transformers.apt.vm +++ b/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 <<>> | *-----------------------------------------+------------------------------------------+ -| {{PluginXmlResourceTransformer}} | Aggregates Mavens <<>> | +| {{PluginXmlResourceTransformer}} | Aggregates Maven's <<>> | *-----------------------------------------+------------------------------------------+ | {{ResourceBundleAppendingTransformer}} | Merges ResourceBundles | *-----------------------------------------+------------------------------------------+ @@ -100,13 +100,13 @@ Transformers in <<>> (availa +----- - Since plugin version 1.3, this resource transformer will also update the descriptor to account for relocation of + Since plugin version 1.3, this resource transformer also updates the descriptor to account for relocation of component interfaces/implementations (if any). * 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 references to java.lang.Class objects rather than strings containing class names. When you wanted to relocate classes, you had to maintain the <<>> by hand, but now this can be done with the <<>> +----- @@ -176,7 +176,7 @@ Transformers in <<>> (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 of this is aggregating both the spring-context and plexus-spring jars. Both of them have the <<>> 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 <<>> as shown below: @@ -525,7 +525,7 @@ Transformers in <<>> (availa The Apache Groovy language provides extension modules located at <<>>, these modules use the property file format. - <<>> automates the assembly of Groovy extension modules <<>>. + <<>> automates the assembly of Groovy extension module descriptors. For example, to simply merge the extension modules of several jars: diff --git a/src/site/apt/examples/use-shader-other-impl.apt.vm b/src/site/apt/examples/use-shader-other-impl.apt.vm index 83dfa31f2..f9270a123 100644 --- a/src/site/apt/examples/use-shader-other-impl.apt.vm +++ b/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. You can, however, use your own implementation. Create a standard Maven project with your implementation. -+----- - -Dependency to Plexus annotations + Dependency for Plexus annotations: ++----- org.codehaus.plexus plexus-component-annotations 1.5.5 ++----- -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: ++----- org.codehaus.plexus plexus-component-metadata diff --git a/src/site/apt/index.apt.vm b/src/site/apt/index.apt.vm index 697ad00e8..ab2a7bf3e 100644 --- a/src/site/apt/index.apt.vm +++ b/src/site/apt/index.apt.vm @@ -25,39 +25,41 @@ ${project.name} - This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and - to - i.e. rename - the packages of some of the dependencies. + This plugin can package the artifact in an uber-jar, including its dependencies, + and shade — that is, 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 <<>> 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 specific use cases are described in the examples given below. - In case you still have questions regarding the plugin's usage, please feel + If you 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 + If you think the plugin is missing a feature or has a defect, you can file 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 - To provide you with better understanding on some usages of the Shade Plugin, - you can take a look into the following examples: + To help you understand some usages of the Shade Plugin, + look into the following examples: * {{{./examples/includes-excludes.html}Selecting Contents for Uber JAR}} diff --git a/src/site/apt/usage.apt.vm b/src/site/apt/usage.apt.vm index 378b62071..82358215d 100644 --- a/src/site/apt/usage.apt.vm +++ b/src/site/apt/usage.apt.vm @@ -84,6 +84,12 @@ mvn package *-----------------------------------------+--------------------------------------+ | XmlAppendingTransformer | Adds XML content to an XML resource | *-----------------------------------------+--------------------------------------+ -Transformers in <<>> +| 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 <<>> and <<>> For more information, see {{{./examples/resource-transformers.html}samples}}. diff --git a/src/site/fml/faq.fml b/src/site/fml/faq.fml index 61b06e9a5..d8ba25439 100644 --- a/src/site/fml/faq.fml +++ b/src/site/fml/faq.fml @@ -20,7 +20,7 @@ under the License. @@ -28,16 +28,16 @@ under the License. Why Does My Second Shade Include The Results Of The First Execution?

- 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 pom.xml includes two shades, - the second shade execution will (by default) start from the result of the + the second shade execution by default starts from the result of the first shade execution.

- If you're looking for two independent shades then read + If you're looking for two independent shades, then read in shade:shade about - ways choose a different name for your first shade. + ways to choose a different name for your first shade.

- \ No newline at end of file +