Add documentation showing how to share configuration (#2643)

Author: nedtwigg

plugin-gradle/README.md

@@ -93,6 +93,7 @@ Spotless supports all of Gradle's built-in performance features (incremental bui
   - [Dependency resolution modes](#dependency-resolution-modes)
   - [How do I preview what `spotlessApply` will do?](#how-do-i-preview-what-spotlessapply-will-do)
   - [Can I apply Spotless to specific files?](#can-i-apply-spotless-to-specific-files)
+  - [How to centralize Spotless configuration](#central-configuration)
   - [Example configurations (from real-world projects)](#example-configurations-from-real-world-projects)
 
 ***Contributions are welcome, see [the contributing guide](../CONTRIBUTING.md) for development info.***
@@ -1913,8 +1914,6 @@ If you use this feature, you will get an error if you use a formatter in a subpr
 - If you don't like what spotless did, `git reset --hard`
 - If you'd like to remove the "checkpoint" commit, `git reset --soft head~1` will make the checkpoint commit "disappear" from history, but keeps the changes in your working directory.
 
-<a name="examples"></a>
-
 ## Can I apply Spotless to specific files?
 
 You can target specific files by setting the `spotlessFiles` project property to a comma-separated list of file patterns:
@@ -1925,6 +1924,31 @@ cmd> gradle spotlessApply -PspotlessFiles=my/file/pattern.java,more/generic/.*-p
 
 The patterns are matched using `String#matches(String)` against the absolute file path.
 
+<a name="central-configuration"></a>
+
+## How to centralize Spotless configuration
+
+If you want to centralize your Spotless configuration for use across many projects, you might want to consider the [Blowdryer](https://github.com/diffplug/blowdryer) plugin.
+
+If you are content with only centralizing configuration files, it is possible to define a common configuration that is deployed as a standard artifact so that it can be then be reused by each project. For example:
+
+```kotlin
+val spotlessConfig by configurations.creating
+dependencies {
+  // the files `java-import-order.txt` and `java-formatter.xml` should be at the root of the deployed `org.mycompany:code-configuration:1.0.0` jar.
+  spotlessConfig("org.mycompany:code-configuration:1.0.0")
+}
+spotless {
+  java {
+    removeUnusedImports()
+    importOrder(resources.text.fromArchiveEntry(spotlessConfig, "java-import-order.txt").asString())
+    eclipse().configXml(resources.text.fromArchiveEntry(spotlessConfig, "java-formatter.xml").asString())
+  }
+}
+```
+
+<a name="examples"></a>
+
 ## Example configurations (from real-world projects)
 
 * [A few thousand github projects](https://github.com/search?l=gradle&q=spotless&type=Code)

plugin-maven/README.md

@@ -72,6 +72,7 @@ user@machine repo % mvn spotless:check
   - [Disabling warnings and error messages](#disabling-warnings-and-error-messages)
   - [How do I preview what `mvn spotless:apply` will do?](#how-do-i-preview-what-mvn-spotlessapply-will-do)
   - [Can I apply Spotless to specific files?](#can-i-apply-spotless-to-specific-files)
+  - [How to centralize Spotless configuration](#central-configuration)
   - [Example configurations (from real-world projects)](#example-configurations-from-real-world-projects)
 
 ***Contributions are welcome, see [the contributing guide](../CONTRIBUTING.md) for development info.***
@@ -2068,7 +2069,39 @@ You can adjust this with
 
 Note that for Incremental build support the goals have to be bound to a phase prior to `test`.
 
-<a name="examples"></a>
+<a name="central-configuration"></a>
+
+## How to centralize Spotless configuration
+
+Rather than copying the formatter files across many projects, it is possible to define a common configuration that is deployed as a standard artifact so that it can be then be reused by each project; for example:
+
+```xml
+<plugin>
+  <groupId>com.diffplug.spotless</groupId>
+  <artifactId>spotless-maven-plugin</artifactId>
+  <version>${spotless-maven-plugin.version}</version>
+  <dependencies>
+    <dependency>
+      <groupId>org.mycompany</groupId>
+      <artifactId>code-configuration</artifactId>
+      <version>1.0.0</version>
+    </dependency>
+  </dependencies>
+  <configuration>
+    <java>
+      <removeUnusedImports/>
+      <importOrder>
+        <file>java-import-order.txt</file>
+      </importOrder>
+      <eclipse>
+        <file>java-formatter.xml</file>
+      </eclipse>
+      <lineEndings>UNIX</lineEndings>
+    </java>
+  </configuration>
+```
+
+In this example, the files `java-import-order.txt` and `java-formatter.xml` should be at the root of the deployed `org.mycompany:code-configuration:1.0.0` jar.
 
 ## Example configurations (from real-world projects)