Grammar and other changes

docs/developer-guide/building-strongbox-against-strongbox.md

@@ -2,7 +2,7 @@
 
 We like our dog food and we try it all the time! :smiley:
 
-There will be many cases where you need to test things against either a full-blown Strongbox (via `strongbox-distribution`), 
+There will be many cases where you need to test things against either a full-blown Strongbox (via `strongbox-distribution`)
 or the `strongbox-web-core`. The following article shows you how to do so.
 
 ## Pre-requisites
@@ -64,14 +64,13 @@ You will need to use the following Maven settings file (that we've called `setti
 </settings>
 ```
 
-This settings file will ensure that all required artifacts, plugins and extensions are resolved via the running instance 
-of Strongbox. In addition, it will override Maven Central as a fallback repository, so everything required will indeed 
+This settings file will ensure that all required artifacts, plugins and extensions are resolved via the running instance of Strongbox. In addition, it will override Maven Central as a fallback repository, so everything required will indeed 
 be resolved through `http://localhost:48080/storages/public/public-group/` which is a group repository that includes 
 all the hosted repositories in Strongbox, as well as all defined proxy repositories.
 
 ## Building Strongbox Against The `strongbox-web-core`
 
-1. Checkout and build the `strongbox` project (either with `mvn clean install`, or `mvn clean install -DskipTests`, based on your needs)
+1. Check out and build the `strongbox` project (either with `mvn clean install`, or `mvn clean install -DskipTests`, based on your needs)
 2. In the `strongbox-web-core` module, execute the following in order to start Strongbox inside a Jetty instance waiting for connections:
    ```
    mvn clean install spring-boot:run

docs/developer-guide/building-the-code-with-docker.md

@@ -3,17 +3,17 @@
 ## Introduction
 
 Docker is awesome and we are using it to build and test almost everything. 
-It has proven to be quite fast and convenient way to easily reproduce issues.
-We encourage you to have a decent version of Docker installed on your machine 
+It has proven to be quite a fast and convenient way to easily reproduce issues.
+We encourage you to have a recent version of Docker installed on your machine 
 so that you can debug or reproduce issues easier.
 
-You should note that we are mostly using Linux so this guide is more focused on how to do things on Linux distributions.
+You should note that we are mostly using Linux, so this guide is more focused on how to do things on Linux distributions.
 However, things under Windows shouldn't be that different.
 
 ## Docker installation
 
-Depending on your OS and distribution you can install different versions of Docker CE (Community Edition).
-In most cases your distribution will have it's own package of Docker which works fine. 
+Depending on your OS and distribution, you can install different versions of Docker CE (Community Edition).
+In most cases, your distribution will have its own package of Docker which works fine. 
 
 Please head to the docker [installation manual](https://docs.docker.com/install/) pages to check how to install it on your machine:
 
@@ -49,7 +49,7 @@ uid=1000(your-username) gid=1000(your-username) groups=1000(your-username)
 ```
 
 If you see another `uid/gid` you will likely hit a permission issue. Unfortunately [docker/compose#3328][issue-3328], 
-[docker/compose#4700][issue-4700] and [docker/cli#1318][issue-1318] are preventing `docker-compose` from being able to 
+[docker/compose#4700][issue-4700], and [docker/cli#1318][issue-1318] are preventing `docker-compose` from being able to 
 automatically fix the group id. There are two workarounds which you can apply for things to work as expected:
 
 1. Instead of using `docker-compose`, you can use plain `docker` and pass ```--group-add `id -g` ``` to the arguments. 
@@ -127,7 +127,7 @@ This might take a while, but in the end you should have a successful build.
 
 ## Making life easier
 
-If you have already checked out our [strongboxci/alpine] repository you would have noticed the amount of 
+If you have already checked out our [strongboxci/alpine] repository you would have noticed the number of 
 different images we have. Trying to remember all of them and the way you need to setup the container is tedious and 
 unnecessary. We have created a [.bashrc]({{resources}}/docker/bashrc-strongbox) with commands you can execute to easily 
 get a container up and running
@@ -137,7 +137,7 @@ Our `.bashrc` has two types of commands which:
 1. Start a container by mounting the current working directory as `workspace` (i.e `dockerMvn35`, `dockerGradle45`, etc)
 2. Start a container and automatically clone a project from github and use that as the `workspace`. (i.e. `dockerMvn35Checkout`, `dockerGradle45Checkout`, etc) 
 
-If you don't remember arguments the command needs you can always execute `dockerMvn35 --help` and it will print them to you as well as an example.
+If you don't remember arguments the command needs, you can always execute `dockerMvn35 --help` and it will print them to you as well as an example.
 
 ### Setting up `~/.bashrc`
 
@@ -151,7 +151,7 @@ echo "\$HOME/.bashrc-strongbox" >> ~/.bashrc
 ```
 
 You can now either open up a new terminal or execute `source ~/.bashrc`  
-Have fun building things in docker :smile:
+Have fun building things in docker! :smile:
 
 
 ### Example commands
@@ -166,7 +166,7 @@ Have fun building things in docker :smile:
     dockerMvn35Checkout strongbox master/branch/PR-1234 "mvn clean install"
     ```
 
-* Use current working directory to build project
+* Use the current working directory to build the project
     ```
     cd /some/path
     dockerMvn35

docs/developer-guide/building-the-code.md

@@ -77,7 +77,7 @@ Then please make sure that:
 
 * You don't have any other test in progress (e.g. halted by debugger process)
 
-The reason for this failure is that OrientDB can't start, if another OrientDB process is running an listening on the same port.
+The reason for this failure is that OrientDB can't start, if another OrientDB process is running and listening on the same port.
 
 ### Filename too long (Windows 7 and 10)
 
@@ -96,7 +96,7 @@ If you are getting one of these errors:
 
 
 Then you are likely hitting a well-known issue with long paths under Windows. 
-Executing command below should fix the issue:
+Executing the command below should fix the issue:
 
 ```
 git config --system core.longpaths true

docs/developer-guide/coding-convention.md

@@ -3,7 +3,7 @@
 ## Reasoning
 
 It is important to have consistency across the codebase. This won't necessarily make your code work better, but it might 
-help make it more understandable, time-consuming and less irritating to go through when doing a code review of your changes.  
+help make it more understandable, time-consuming, and less irritating to go through when doing a code review of your changes.  
 
 While to some this will seem like a nuisance, with no real benefit to the actual code, and while we do understand 
 this point of view, we think that reading `diff`-s should be quick and easy. Accepting a pull request requires for it to
@@ -62,13 +62,13 @@ and whether, or not it will impact something else. All of this takes time, which
         ```
 
 * When re-indenting code, please make a single commit with just the indentation changes and make sure you describe that 
-  this is just an re-indentation change in the commit message. Mixing reformatting and actual functional changes in the 
+  this is just a re-indentation change in the commit message. Mixing reformatting and actual functional changes in the 
   same commit makes things much more obscure to track and figure out.
 
 * Don't reformat entire files, unless absolutely necessary! This makes it harder (and more time-consuming) to check what 
   changes you've actually made.
 
-* Try not to re-order code imports. Sometimes, while optimizing imports this is not possible, but re-ordering a long 
+* Try not to re-order code imports. Sometimes, while optimizing imports, this is not possible, but re-ordering a long 
   list of imports can make a diff hard to read.
 
 ## Code Example

docs/developer-guide/git/rebase-vs-merge.md

@@ -3,7 +3,7 @@
 ## Conceptual Overview
 
 The first thing to understand about `git rebase` is that it solves the same problem as git merge. Both of these commands 
-are designed to integrate changes from one branch into another branch—they just do it in very different ways.  
+are designed to integrate changes from one branch into another branch. They just do it in very different ways.  
 
 Consider what happens when you start working on a new feature in a dedicated branch, then another team member updates 
 the `master` branch with new commits. This results in a forked history, which should be familiar to anyone who has used 
@@ -18,7 +18,7 @@ new commits into your `feature` branch, you have two options: `merging` or `reba
 
 ??? danger "Please avoid using this option!"
     Please avoid using this option. It creates unnecessary noise in your PRs and makes it ***extremely*** hard to 
-    follow your real changes. We have included this information because it will give you better understanding of why we 
+    follow your real changes. We have included this information because it will give you a better understanding of why we 
     prefer `rebasing` over `merging`.
 
 The easiest option is to merge the `master` branch into the feature branch using something like the following:
@@ -51,15 +51,15 @@ to understand the history of the project or branch you are working on.
 
 !!! success "We prefer this option over `merging`"
 
-As an alternative to merging, you can rebase the feature branch onto master branch using the following commands:
+As an alternative to merging, you can rebase the feature branch onto the master branch using the following commands:
 
 ```
 git checkout feature
 git rebase master
 ```
 
 This moves the entire `feature` branch to begin on the tip of the master branch, effectively incorporating all of 
-the new commits in `master`. But, instead of using a `merge` commit, `rebasing` re-writes the project history by 
+the new commits in `master`. Instead of using a `merge` commit, `rebasing` re-writes the project history by 
 creating brand new commits for each commit in the original branch.
 
 ![](images/03.svg)
@@ -97,7 +97,7 @@ However, before executing this command, please be **sure** nobody else is workin
 ## But how do I rebase?
 
 Before you start, it is a good idea to backup your current project. If this is your first time doing a rebase, you can 
-screw things up and loose/damage the work you've already done. So better safe, than sorry. (If you are a pro - what are
+screw things up and lose/damage the work you've already done. So better safe than sorry. (If you are a pro - what are
 you even doing here? :smile: )  
 
 
@@ -114,10 +114,10 @@ Steps:
   ```linenums="1"
   $ git remote add upstream git@github.com:strongbox/strongbox.git
   $ git remote -v
-    origin  	git@github.com:your-username/strongbox.git (fetch)
-    origin  	git@github.com:your-username/strongbox.git (push)
-    upstream	git@github.com:strongbox/strongbox.git (fetch)
-    upstream	git@github.com:strongbox/strongbox.git (push)
+    origin    git@github.com:your-username/strongbox.git (fetch)
+    origin    git@github.com:your-username/strongbox.git (push)
+    upstream  git@github.com:strongbox/strongbox.git (fetch)
+    upstream  git@github.com:strongbox/strongbox.git (push)
   ```
 
 * Sync your fork   
@@ -156,7 +156,7 @@ You can also check Idea's manual for [Resolving Conflicts]
 
 #### Command line
 
-If you are command line lover, you can execute the commands manually:
+If you are a command line lover, you can execute the commands manually:
 
 ```linenums="1"
 git checkout feature-branch
@@ -167,7 +167,7 @@ However, when conflicts arise, it could be a bit challenging to fix them from yo
 
 #### Finally
 
-Once you are done rebasing and you have ensured that the code builds as well as the tests are passing, then you will 
+Once you are done rebasing and you have ensured that the code builds and the tests are passing, then you will 
 need to force push your branch (remember the [Force Pushing](#force-pushing) section?)
 
 ```

docs/developer-guide/ide-setup/eclipse.md

@@ -1,6 +1,6 @@
 # Eclipse
 
-!!! tip "Before continuing, please make sure you've built the code using [Building the code] section."
+!!! tip "Before continuing, please make sure you've built the code using the [Building the code] section."
 
 ## Choose Eclipse distribution
 The `Eclipse IDE for Java Developers` package is a sufficient base for strongbox project development.
@@ -23,7 +23,7 @@ You should already have created an empty workspace - this is the default behavio
 ### Import Maven project
 * Choose `File -> Import -> Maven -> Existing Maven Projects`
 * Point the `Root Directory` to the strongbox cloned repository.
-* Click `Finish` button.
+* Click the `Finish` button.
 ![Import -> Existing Maven Project -> Finish][Import Maven Project]
 
 ### Workaround m2e connectors
@@ -42,11 +42,11 @@ If a popup `Discover m2e connectors` appears - click `Resolve All Later` and `Fi
     ![strongbox-storage-nuget-layout-provider/src/main/antlr4 -> Build Path -> Use as Source Folder][Nuget ANTLR Build Path]
 
 ### Configure `strongbox-aql` project
-* Expand the `src/main` directory and select `groovy` and `twig` folders, then right click and pick `Build path -> Use as Source Folder`
+* Expand the `src/main` directory and select the `groovy` and `twig` folders, then right click and pick `Build path -> Use as Source Folder`
     ![strongbox-aql/src/main/groovy & twig ->  Build Path -> Use as Source Folder][AQL groovy and twig Build Path]
 
-* Right click the project and pick Properties 
-    * `Java Build Path -> Libraries -> Add Library -> Groovy Runtime Libraries`. Note that if on right click you pick directly Build path adding the groovy libraries gives an error
+* Right click the project and cick Properties 
+    * `Java Build Path -> Libraries -> Add Library -> Groovy Runtime Libraries`. Note that if on right click you pick Build path directly, adding the groovy libraries gives an error
         ![strongbox-aql -> Properties -> Java Build Path -> Add Library -> Groovy Runtime Libraries][AQL groovy project nature]
     * `Project Natures -> Add -> Groovy Nature`
         ![strongbox-aql -> Properties -> Project Natures -> Add -> Confirm Project Nature update -> Groovy Nature][AQL groovy libraries in Build Path]

docs/developer-guide/project-structure.md

@@ -5,7 +5,7 @@
 ### Core Modules
 
 All the core modules are located under the [Strongbox] project. Each of these modules has a `README.md` file explaining 
-briefly what kind of code contains. New modules should also follow the same format.
+briefly what kind of code it contains. New modules should also follow the same format.
 
 This is a brief breakdown of the modules:
 
@@ -43,7 +43,7 @@ This is a brief breakdown of the modules:
 * [strongbox-resources]  
 
     * [strongbox-common-resources]    
-        This is the place where common resources which can be used by multiple projects reside. The idea is not have to 
+        Contains common resources that can be used by multiple projects. The idea is not to have to 
         duplicate things such as `logback*xml`, keystores and so on across the other modules. These resources are copied 
         using the `maven-dependency-plugin`.
 
@@ -76,7 +76,7 @@ This is a brief breakdown of the modules:
     Contains the code for the storage related modules.
 
     * [strongbox-storage-api]  
-        Contains the the storage API.
+        Contains the storage API.
 
     * [strongbox-storage-core]  
         Contains the core classes for the storage API.
@@ -99,7 +99,7 @@ This is a brief breakdown of the modules:
 
     * [strongbox-storage-p2-layout-provider]  
         This is an incomplete early draft implementation of the P2 OSGi layout provider. This module needs a lot more 
-        work, before the P2 layout provider could be usable.
+        work before the P2 layout provider could be usable.
 
     * [strongbox-storage-raw-layout-provider]  
         This is the implementation of the [Raw layout provider].
@@ -127,10 +127,10 @@ All the [Strongbox] modules are organized under the [Strongbox organization].
 
 ### Creating New Modules/Projects
 
-* Each new modules needs to extend the `strongbox-parent`, from where it should be extending the dependencies and the 
+* Each new module needs to extend the `strongbox-parent`, from where it should be extending the dependencies and the 
   configuration for Maven plugins. Modules should not contain any artifact or plugin versions.
 
-* All modules need to have a `README.md` file describing in brief what the module is and give brief pointers 
+* All modules need to have a `README.md` file describing, in brief, what the module is and give brief pointers 
   on what classes and tests are of primary interest.
 
 * Each project in the [Strongbox organization] needs to have a copy of the [LICENSE] file.
@@ -144,12 +144,11 @@ All the [Strongbox] modules are organized under the [Strongbox organization].
 The web integration tests are located in the [strongbox-web-integration-tests] project. 
 They are using the [maven-invoker-plugin] to execute various tests 
 against a Strongbox instance which is started for this purpose. These tests start Maven processes via the [maven-invoker-plugin]
-and are literally mimicking Maven behaviour. The outcome of the tests is validated using Groovy scripts.
+and are literally mimicking Maven behavior. The outcome of the tests is validated using Groovy scripts.
 
 ## Packaging Modules
 
-For a much more lightweight build the modules which carry out the actual packaging into assemblies and distributions, 
-these have been extracted into separate projects under the organization.
+For a much more lightweight build the modules, which carry out the actual packaging into assemblies and distributions, have been extracted into separate projects under the organization.
 
 ## See Also
 * [Writing Tests](./writing-tests.md)

docs/user-guide/application-properties.md

@@ -67,7 +67,7 @@ The following is a list of configuration properties, which can be used to custom
 
 ??? info "export STRONGBOX_DOWNLOAD_INDEXES_\${storageId}\_\* or <br> -Dstrongbox.download.indexes_\${storageId}_*"
 
-    Whether, or not to download the Maven indexes for all remote repositories in the `$storageId`.
+    Whether to download the Maven indexes for all remote repositories in the `$storageId`.
 
     Can be passed as `-Dstrongbox.download.indexes_${storageId}_*` or set via the env variable `STRONGBOX_DOWNLOAD_INDEXES_${storageId}_*`     
 

docs/user-guide/artifact-query-language.md

@@ -33,10 +33,10 @@ needs to work the same across all layouts:
 
 ### Values
 
-* _**Values**_ can be strings:
+* _**Values**_ can be strings
 
   * Quoted with single quotes `'` when the value is more than one word (for example: `storage: storage0`, `layout: 'Maven 2'`)
-  * Separated with comma `,` for multiple values; you can consider this the same as `IN` operator in SQL  (for example: `repository: releases, snapshots`, `layout: 'Maven 2', NuGet`)
+  * Separated by a comma `,` for multiple values; you can consider this the same as `IN` operator in SQL  (for example: `repository: releases, snapshots`, `layout: 'Maven 2', NuGet`)
   * Wildcards are supported `*` (for example: `group: org.carlspring.*`)
 
 * _**Values**_ can be dates in Unicode format: `2018-03-21 13:00:00`, `2018-03-21` (for example: `updated: 2018-03-21`, `updated: '2018-03-21 13:00'`)
@@ -94,8 +94,7 @@ needs to work the same across all layouts:
 
 ## How to use
 
-The easiest way to AQL is by using the search bar in the user interface. Once you start writing, you will see suggestions
-based on what you've typed. You could also directly search via the REST API Endpoint.  
+The easiest way to use the AQL is by using the search bar in the user interface. As soon as you start typing, you will see suggestions based on what you've typed. You could also directly search via the REST API end-point.  
 
 Example `curl` request: