fix readme typos

Author: TheSnoozer

README.md

@@ -41,7 +41,7 @@ In order to understand the ideology and intention here are some pretty usefull i
 With the current version of the validation the user can decide if the build should fail if *at least one* of the defined criterias do not match with the desired values.
 
 For flexibility and due to the fact that this validation has a different scope than the maven-git-commit-id-plugin this validation needs to be configured as additional execution inside the configuration of the pom.xml.
-Once configured, the validation is executed during the verification-phase. However since the validation is done in a seperate execution the phase can easily be changed by adding the desired phase to the execution configuration.
+Once configured, the validation is executed during the verification-phase. However since the validation is done in a separate execution the phase can easily be changed by adding the desired phase to the execution configuration.
 
 Usage Example:
 
@@ -72,7 +72,7 @@ Usage Example:
 
 Required Configuration:
 If you plan to use this feature you'll want to know that the validation will be executed inside an additional mojo.
-Inside you pom you thus may want to add an additional execution tag that triggers the execution of the validation plugin.
+Inside your pom you thus may want to add an additional execution tag that triggers the execution of the validation plugin.
 You can also change the default phase of each execution by adding a `phase` definition.
 
 ```xml
@@ -362,7 +362,7 @@ It's really simple to setup this plugin; below is a sample pom that you may base
                         The token can be seen as the needle and the value as the text to be written over any found tokens. If using regular expressions the value can reference grouped regex matches by using $1, $2, etc.
 
                         Since 2.2.4 the plugin allows to define a even more sophisticated ruleset and allows to set an `propertyOutputSuffix` within each replacement property. If this option is empty the original property will be overwritten (default behaviour in 2.2.3). however when this configuration is set to `something` and a user wants to modify the `git.branch` property the plugin will keep `git.branch` as the original one (w/o modifications) but also will be creating a new `git.branch.something` property with the requested replacement.
-                        Furthermore with 2.2.4 the plugin allows to perform certain types of string manipulation either before or after the evaluation of the replacement. With this feature a user can currently easily manipulate the case (e.g. lower case VS upper case) of the input/output property. This behaviour can be achieved by defining a list of `transformationRules` for the property where those rules should take effect. Each `transformationRule` consist of two required fields `apply` and `action`. The `apply`-tag controls when the rule should be applied and can be set to `BEFORE` to have the rule being applied before or it can be set to `AFTER` to have the rule being applied after the replacement. The `action`-tag determines the string conversion rule that should be applied. Currenlty supported is `LOWER_CASE` and `UPPER_CASE`. Potential candidates in the feature are `CAPITALIZATION` and `INVERT_CASE``(open a ticket if you need them...).
+                        Furthermore with 2.2.4 the plugin allows to perform certain types of string manipulation either before or after the evaluation of the replacement. With this feature a user can currently easily manipulate the case (e.g. lower case VS upper case) of the input/output property. This behaviour can be achieved by defining a list of `transformationRules` for the property where those rules should take effect. Each `transformationRule` consist of two required fields `apply` and `action`. The `apply`-tag controls when the rule should be applied and can be set to `BEFORE` to have the rule being applied before or it can be set to `AFTER` to have the rule being applied after the replacement. The `action`-tag determines the string conversion rule that should be applied. Currently supported is `LOWER_CASE` and `UPPER_CASE`. Potential candidates in the feature are `CAPITALIZATION` and `INVERT_CASE``(open a ticket if you need them...).
 
                         Please note that the replacement will *only be applied to properties that are being generated by the plugin*.
                         If you want to replace properties that are being generated by other plugins you may want to use the maven-replacer-plugin or any other alternative.
@@ -766,7 +766,7 @@ git.build.time=${git.build.time}
 Yet another way to use the plugin
 =================================
 
-Rather than reading properties files at runtime or injecting with spring, you can filter a Java source file directly and place it into src/main/java with an ignore, or into generated sources directory within the target directory. This has some minor advantages and disadvantages, but is useful for avoiding runtime injection or lookup from properties files that might get lost during repackaging later if used within a library. 
+Rather than reading properties files at runtime or injecting with spring, you can filter a Java source file directly and place it into `src/main/java` with an ignore, or into generated sources directory within the target directory. This has some minor advantages and disadvantages, but is useful for avoiding runtime injection or lookup from properties files that might get lost during repackaging later if used within a library.
 
 Git describe - short intro to an awesome command
 ==================================================
@@ -942,7 +942,7 @@ Instead of using the Plugin Prefix Resolution add an execution tag that calls th
 How to contribute to the project
 -------------------------------
 In general pull requests and support for open issues is always welcome!
-If you open a pull request or want to help out in any way please keep in mind that we currently use `checkstyle` to ensure that the project somehow maintains a uniform code base. Fortunately the most common IDEs support the integration of `checkstyle` via plugins. On top of more or less native integration into modern development tools the `checkstyle` rules are currently also being verified by using the [maven-checkstyle-plugin](https://maven.apache.org/plugins/maven-checkstyle-plugin/) during the build. it should be worth to highlight that you are not required to install `checkstyle` inside your IDE. if you feel more comfortable running the checks via maven this would to the trick!
+If you open a pull request or want to help out in any way please keep in mind that we currently use `checkstyle` to ensure that the project somehow maintains a uniform code base. Fortunately the most common IDEs support the integration of `checkstyle` via plugins. On top of more or less native integration into modern development tools the `checkstyle` rules are currently also being verified by using the [maven-checkstyle-plugin](https://maven.apache.org/plugins/maven-checkstyle-plugin/) during the build. it should be worth to highlight that you are not required to install `checkstyle` inside your IDE. If you feel more comfortable running the checks via maven this would to the trick!
 The checkstyle rules for this project are currently residing in `src/test/resources/checks` and for some IDEs those rules need to be imported manually (unfortunately there is no better solution available for this yet). The current rule set is pretty much the same as the `google_checks.xml` with certain checks disabled (e.g. line length). If you choose to integrate `checkstyle` inside your IDE feel free to checkout some high level requirements to get started with checkstyle within your IDE:
 * eclipse -- for eclipse / STS you would need to install the `checkstyle plug-in` via `Help -> Eclipse Marketplace -> Search` after restarting eclipse it should pick-up the rules automatically. If this does not work out of the box checkout the [official integration guide](http://checkstyle.sourceforge.net/eclipse.html) or use google to trace down your error message.
 * IntelliJ IDEA -- for IntelliJ you would need to install the `CheckStyle-IDEA` via `File -> Settings -> Plugins -> Search`. After restarting IntelliJ you would need to import the `checkstyle` rules manually via `File -> Settings -> Checkstyle`. As checkstyle version you may choose `6.11.2` or `8.2` and then click on the plus-sign on the right. As description you may choose `maven-git-commit-id-plugin` and as local checkstyle file you may choose one of the checkstyle rule residing in `src/test/resources/checks`. Please note that the rule-file depend on the version you have selected in the previous step and thus it is essential to ensure that the version numbers match up. As next-step you unfortunately will be prompted to enter the **full directory** of the `checkstyle-suppressions.xml`-File. If this does not work out of the box checkout the [official integration guide](http://checkstyle.sourceforge.net/idea.html) or use google to trace down your error message.