Add spotless rules for markdown files

And apply those rules to our markdown files

Author: FSchumacher

CODE_OF_CONDUCT.md

@@ -17,10 +17,10 @@ we invite anyone to participate in our community. We preferably use public metho
 ## **Be empathetic**
 welcoming, friendly, and patient. We work together to resolve conflict, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one. We should be respectful when dealing with other community members as well as with people outside our community.
 
-## **Be collaborative**, 
+## **Be collaborative**,
 our work will be used by other people, and in turn we will depend on the work of others. When we make something for the benefit of the project, we are willing to explain to others how it works, so that they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.
 
-## **Be inquisitive**, 
+## **Be inquisitive**,
 nobody knows everything! Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful, within the context of our shared goal of improving Apache project code.
 
 ## **Be careful in the words that we choose**,
@@ -37,14 +37,14 @@ Whether we are participating as professionals or volunteers, we value profession
 * Repeated harassment of others. In general, if someone asks you to stop, then stop.
 * Advocating for, or encouraging, any of the above behaviour.
 
-## **Be concise**, 
+## **Be concise**,
 keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary.
 
 Try to bring new ideas to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.
 
 Try to stay on topic, especially in discussions that are already fairly large.
 
-## **Step down considerately**, 
+## **Step down considerately**,
 members of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project's goals or achievements. Likewise, community members should respect any individual's choice to leave the project.
 
 # Diversity Statement

build.gradle.kts

@@ -259,6 +259,19 @@ allprojects {
                 trimTrailingWhitespace()
                 endWithNewline()
             }
+            if (project == rootProject) {
+                // Spotless does not exclude subprojects when using target(...)
+                // So **/*.md is enough to scan all the md files in JMeter codebase
+                // See https://github.com/diffplug/spotless/issues/468
+                format("markdown") {
+                    target("**/*.md")
+                    // Flot is known to have trailing whitespace, so the files
+                    // are kept in their original format (e.g. to simplify diff on library upgrade)
+                    targetExclude("bin/report-template/**/flot*/*.md")
+                    trimTrailingWhitespace()
+                    endWithNewline()
+                }
+            }
         }
     }
     plugins.withType<JavaPlugin> {

gradle.md

@@ -17,18 +17,18 @@ Useful commands (`gw` comes from https://github.com/dougborg/gdub, otherwise `./
 
       # Display all submodules
       gw projects
-      
+
       # Different tasks for current module
       gw tasks
 
 ## Cleaning build directories
 
 Technically `clean` should not be required, every time it is required it might be a bug.
-However it might be useful to perform a "clean" build: 
+However it might be useful to perform a "clean" build:
 
       # Cleans current project (submodule)
       gw clean
-      
+
       # Cleans the specified project
       gw :src:core:clean
 
@@ -54,26 +54,26 @@ However it might be useful to perform a "clean" build:
 
       # Run RAT
       gw rat
-      
+
 ### Code Formatting
-      
+
       # Run spotlessApply and checkstyleAll
       gw style
-      
+
       # Run checkstlye for all
       gw checkstyleAll
-      
+
 #### Fine Grained Formatting Commands
-      
+
       # Run checkstyle for main (non-test) code
       gw checkstyleMain
-      
+
       # Run checkstyle for test code
       gw checkstyleTest
-      
+
       # Run Spotless checks
       gw spotlessCheck
-      
+
       # Fix any issues found by Spotless
       gw spotlessApply
 
@@ -87,13 +87,13 @@ However it might be useful to perform a "clean" build:
 
       # Just build jar (see build/libs/*.jar)
       gw jar
-      
+
       # "build" is a default task to "execute all the actions"
       gw build
-      
+
       # Test might be skipped by `-x test` (Gradle's default way to skip task by name)
       gw -x test build
-      
+
       # Build project in parallel
       gw build --parallel
 
@@ -105,26 +105,26 @@ build only the required jars and files.
 
       # Runs all the tests (unit tests, checkstyle, etc)
       gw check
-      
+
       # Runs just unit tests
       gw test
-      
+
       # Runs just core tests
       gw :src:core:test
 
 ## Coverage
 
       # Generates code coverage report for the test task to build/reports/jacoco/test/html
       gw jacocoTestReport
-      
+
       # Generate combined coverage report
       gw jacocoReport
 
 ## Generate Javadocs
 
       # Builds javadoc to build/docs/javadoc subfolder
       gw javadoc
-      
+
       # Builds javadoc jar to build/libs/jorphan-javadoc.jar
       gw javadocJar
 
@@ -152,14 +152,14 @@ build only the required jars and files.
 
 ## Signing
 
-It is implemented via [gradle signing plugin](https://docs.gradle.org/5.2.1/userguide/signing_plugin.html), 
+It is implemented via [gradle signing plugin](https://docs.gradle.org/5.2.1/userguide/signing_plugin.html),
 so it is done automatically provided credentials are specified via
 [signatory credentials](https://docs.gradle.org/5.2.1/userguide/signing_plugin.html#sec:signatory_credentials)
 
       # Signs all the artifacts of the current module
       # see results in build/**/*.asc
       gw sign
-> **Note:** signing is performed as a part of *release artifact build* so it will be 
+> **Note:** signing is performed as a part of *release artifact build* so it will be
 > performed with `gw :src:dist:assemble`
 
 ## Releasing