[maven-shared-utils] 01/01: docs: grammar

[el...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

elharo pushed a commit to branch elharo-patch-1
in repository https://gitbox.apache.org/repos/asf/maven-shared-utils.git

commit 29fddbc11d3e1520a310e5c9190a071e169b59d0
Author: Elliotte Rusty Harold <el...@users.noreply.github.com>
AuthorDate: Sun Feb 23 10:57:30 2020 -0500

    docs: grammar
    
    @hboutemy
---
 src/site/apt/index.apt.vm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/site/apt/index.apt.vm b/src/site/apt/index.apt.vm
index 0e035b7..0ee0872 100644
--- a/src/site/apt/index.apt.vm
+++ b/src/site/apt/index.apt.vm
@@ -40,12 +40,12 @@ ${project.name}
 
 Why?
 
-   plexus-utils consisted mostly of code that was forked from various apache projects. 
+   plexus-utils consisted mostly of code that was forked from various Apache projects. 
    maven-shared-utils is based on the original from the Apache sources.
 
 Why not commons?
 
-    We would prefer code to use commons-* code where appropriate, but the plexus-utils became
+    We would prefer code to use commons-* where appropriate, but the plexus-utils became
     slightly incompatible (different) from the commons over the years, so migrating is not
     always a 1:1 operation. Migrating to maven-shared-utils is a 1:1 operation in most cases.
 
@@ -55,7 +55,7 @@ Relation to Commons-*
   classes into our own private package to prevent classpath clashes.
 
   This is the reason why any public API in maven-shared-utils must
-  avoid to expose commons-io classes directly. Most times it's sufficient
-  to just create an empty subclass and expose that instead.
+  avoid exposing commons-io classes directly. Most times it's sufficient
+  to create an empty subclass and expose that instead.
 
   []