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)