diff --git a/plugin-gradle/README.md b/plugin-gradle/README.md
index a5d32e3f1e..c308dbdb1f 100644
--- a/plugin-gradle/README.md
+++ b/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.
-
-
## 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.
+
+
+## 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())
+ }
+}
+```
+
+
+
## Example configurations (from real-world projects)
* [A few thousand github projects](https://github.com/search?l=gradle&q=spotless&type=Code)
diff --git a/plugin-maven/README.md b/plugin-maven/README.md
index f9747282a5..066fa2868c 100644
--- a/plugin-maven/README.md
+++ b/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`.
-
+
+
+## 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
+
+ com.diffplug.spotless
+ spotless-maven-plugin
+ ${spotless-maven-plugin.version}
+
+
+ org.mycompany
+ code-configuration
+ 1.0.0
+
+
+
+
+
+
+ java-import-order.txt
+
+
+ java-formatter.xml
+
+ UNIX
+
+
+```
+
+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)