You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maven.apache.org by hb...@apache.org on 2018/12/20 06:42:45 UTC
[maven-site] branch master updated: Fix various typos using a spell checker ✅
This is an automated email from the ASF dual-hosted git repository.
hboutemy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
The following commit(s) were added to refs/heads/master by this push:
new 0ef5df9 Fix various typos using a spell checker ✅
0ef5df9 is described below
commit 0ef5df99b60c3c2087eed48f89ab112ee489f757
Author: Nicolas Kosinski <ni...@yahoo.com>
AuthorDate: Thu Dec 20 06:11:57 2018 +0100
Fix various typos using a spell checker ✅
All IDEs and text editors have a spell checking feature (or plug-ins). 😇
I have used this one to detect and fix typos in the 'content/markdown' folder:
https://github.com/bartosz-antosik/vscode-spellright
---
content/markdown/background/history-of-maven.md | 4 ++--
content/markdown/ide.md | 2 +-
content/markdown/maven-ci-friendly.md | 12 ++++++------
content/markdown/maven-conventions.md | 2 +-
content/markdown/maven-jsr330.md | 2 +-
content/markdown/project-roles.md | 6 +++---
content/markdown/reference/maven-classloading.md | 2 +-
content/markdown/run.md | 2 +-
content/markdown/security-plexus-archiver.md | 6 +++---
9 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/content/markdown/background/history-of-maven.md b/content/markdown/background/history-of-maven.md
index 13e30df..20a0735 100644
--- a/content/markdown/background/history-of-maven.md
+++ b/content/markdown/background/history-of-maven.md
@@ -26,7 +26,7 @@ It reminds me of one of my favourite quotes from Ralph Johnson and Don Roberts i
> People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction
> on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a
-> resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples
+> reusable design, so you develop it by looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
I didn't really know what the final result would look like I just knew there had to be a better way.
@@ -47,7 +47,7 @@ as Gump was not trying to standardize anything at the time but trying to continu
get its hands on. My goals were different and I wanted to make an
[opinionated][8] piece of software and I preferred the notion of convention over configuration. I wanted a project's infrastructure to
look the same and work the same so I continued to pursue my own model for a project and decided to disagree with
-Gump's particular tact at project modelling which I thought was too flexible. I wanted to save people time by being
+Gump's particular tact at project modeling which I thought was too flexible. I wanted to save people time by being
able to find things in the same place. Again the value in a project is the final result: how it is constructed
and built predictable and easy. I fully admit some warts in Maven 1.x sometimes made things harder but that is
par for the course with first generation tools.
diff --git a/content/markdown/ide.md b/content/markdown/ide.md
index 4443bfb..6d1d645 100644
--- a/content/markdown/ide.md
+++ b/content/markdown/ide.md
@@ -26,7 +26,7 @@ Eclipse workspace with those changes.
## JetBrains IntelliJ IDEA
-Intelli IDEA has a [feature-rich integration for Maven](https://www.jetbrains.com/idea/help/maven.html).
+IntelliJ IDEA has a [feature-rich integration for Maven](https://www.jetbrains.com/idea/help/maven.html).
## Netbeans IDE
diff --git a/content/markdown/maven-ci-friendly.md b/content/markdown/maven-ci-friendly.md
index 7328552..d91c4bc 100644
--- a/content/markdown/maven-ci-friendly.md
+++ b/content/markdown/maven-ci-friendly.md
@@ -41,7 +41,7 @@ mvn clean package
mvn -Drevision=1.0.0-SNAPSHOT clean package
```
- This wil become cumbersome over the time. So the other solution for this is
+ This will become cumbersome over the time. So the other solution for this is
to simply use a property inside the pom file which looks like this:
```xml
@@ -71,7 +71,7 @@ mvn -Drevision=1.0.0-SNAPSHOT clean package
mvn -Drevision=2.0.0-SNAPSHOT clean package
```
- Of cource you can use the `.mvn/maven.config` file for this.
+ Of course you can use the `.mvn/maven.config` file for this.
A note about the used properties. You can only use those named
`${revision}`, `${sha1}` and/or `${changelist}` and not other
@@ -96,7 +96,7 @@ mvn -Drevision=2.0.0-SNAPSHOT clean package
</project>
```
- The above example will *not work as expeced*. If you like
+ The above example will *not work as expected*. If you like
to have more flexibility you can use a combination of the
different properties like this:
@@ -128,7 +128,7 @@ mvn -Drevision=2.0.0-SNAPSHOT clean package
mvn -Drevision=2.0.0 clean package
```
- Another usage example can be do make a release which can be
+ Another usage example can be to make a release which can be
done via (version 1.3.1):
```
@@ -146,7 +146,7 @@ mvn -Drevision=2.7.8 -Dchangelist= clean package
## Multi Module Setup
So now let us take a look into a situation where we have a multi module
- build. We have a parent pom and one or more childs.
+ build. We have a parent pom and one or more children.
The parent pom will look like this:
```xml
@@ -196,7 +196,7 @@ mvn -Drevision=2.7.8 -Dchangelist= clean package
If you like to install or deploy artifacts by using the above setup you **have to use**
the [flatten-maven-plugin][flatten-maven-plugin] otherwise you will install/deploy artifacts
- in your repository which will not be cosumable by Maven anymore. Such kind of setup
+ in your repository which will not be consumable by Maven anymore. Such kind of setup
will look like this:
diff --git a/content/markdown/maven-conventions.md b/content/markdown/maven-conventions.md
index cf33796..4a1d305 100644
--- a/content/markdown/maven-conventions.md
+++ b/content/markdown/maven-conventions.md
@@ -33,7 +33,7 @@ As previously mentioned, the artifact ID should be the basis of the
filename for the project, as by default Maven will use that and the
version to assemble the filename. Having the version as part of the
filename is strongly recommended to ensure that the version can be
-determined at a glance without having to check a possibly non-existant
+determined at a glance without having to check a possibly non-existent
manifest, or compare file sizes with the official releases.
Following these guidelines are particularly encouraged when distributing
diff --git a/content/markdown/maven-jsr330.md b/content/markdown/maven-jsr330.md
index 6aeac79..bd53c07 100644
--- a/content/markdown/maven-jsr330.md
+++ b/content/markdown/maven-jsr330.md
@@ -296,7 +296,7 @@ Now let\'s take a look at the plugin code. You\'ll notice that we\'re using cons
which makes testing a lot easier. If you want to test your `Jsr330Component`, you do not need the container
to instantiate the `Mojo`. In this simple case, you can actually test this plugin without using the plugin
testing harness because you can instantiate the `Jsr330Component` and `Jsr330Mojo` directly and wire
-everything up manually using the constructor. Constructor injection, which Plexus lacks, greatly simplies testing.
+everything up manually using the constructor. Constructor injection, which Plexus lacks, greatly simplifies testing.
```
package org.apache.maven.plugins;
diff --git a/content/markdown/project-roles.md b/content/markdown/project-roles.md
index 93e37d6..cd55fb8 100644
--- a/content/markdown/project-roles.md
+++ b/content/markdown/project-roles.md
@@ -271,7 +271,7 @@ by example the early committing of such changes from a fork (that they
are involved in maintaining) back to Apache Maven source control.
Similarly, if a fork is being hosted elsewhere in order to get contributions
-from other talented individuals, the PMC members should endevour to bring
+from other talented individuals, the PMC members should endeavour to bring
those individuals and their talent to the project as committers.
Finally, where a fork is hosted outside of Apache hardware, there is less
@@ -286,7 +286,7 @@ of the risk that review obligations may grow above the time capabilities
of the PMC and committers such that when they eventually decide to try and
bring the changes in their fork back to the Apache Maven project their
contribution may end up being rejected on the basis of the review of a
-large set of changes being too difficult/timeconsuming.
+large set of changes being too difficult/time-consuming.
### [Project Management Chair](https://www.apache.org/foundation/how-it-works.html#pmc-chair)
@@ -305,7 +305,7 @@ Committee as a whole that is responsible for the direction of the project.
If things break down and there is no consensus and there is no clear
ability to reach any conclusion *and* it is in the interest of the
foundation because damage is done and the board expects the chair
-to act as an officier of the foundation and clean things up, then the chair
+to act as an officer of the foundation and clean things up, then the chair
can act as an ultimate decision maker, however, by this point the
board of the foundation must already be well aware of the situation and
should be actively monitoring the chair.
diff --git a/content/markdown/reference/maven-classloading.md b/content/markdown/reference/maven-classloading.md
index dbd4074..808568d 100644
--- a/content/markdown/reference/maven-classloading.md
+++ b/content/markdown/reference/maven-classloading.md
@@ -73,7 +73,7 @@ Plugin classloaders are wired differently for projects with and without build ex
For projects without build extensions, single classloader is created for each plugin identified by groupId:artifactId:version and the classloader imports API packages from Maven API classloader. Maven will create one and only one classloader for each unique plugin+dependency combination.
-For projects that use build extensions, plugin classloaders are wired to project classloaders. This gives plugin code access to both Maven API packages and packages exported by the project build extensions. Maven will create one and only one classlaoder for each unique plugin+dependencies+buid-extensions combination.
+For projects that use build extensions, plugin classloaders are wired to project classloaders. This gives plugin code access to both Maven API packages and packages exported by the project build extensions. Maven will create one and only one classlaoder for each unique plugin+dependencies+build-extensions combination.
All plugin classloaders use ClassWorlds bootstrap classloader as the parent. This provides relatively clean and therefore consistent plugin classpath, while still allowing plugins access to `-javaagent` classes (see [MNG-4747](https://issues.apache.org/jira/browse/MNG-4747)).
diff --git a/content/markdown/run.md b/content/markdown/run.md
index 0636183..1fdbbad 100644
--- a/content/markdown/run.md
+++ b/content/markdown/run.md
@@ -45,7 +45,7 @@ or
mvn checkstyle:check
-There are many different plugins avaiable and they all implement different goals.
+There are many different plugins available and they all implement different goals.
Further resources:
diff --git a/content/markdown/security-plexus-archiver.md b/content/markdown/security-plexus-archiver.md
index a8a6e7f..6cf88ab 100644
--- a/content/markdown/security-plexus-archiver.md
+++ b/content/markdown/security-plexus-archiver.md
@@ -47,21 +47,21 @@ which versions contain the fixed and the link to the corresponding issue.
<td>(,3.1.0]</td>
<td>3.1.1</td>
<td><a href="https://issues.apache.org/jira/browse/MDEP-611">MDEP-611</a></td>
- <td>unpack and unpack-dependencies goals (not used unless configured explicitely)</td>
+ <td>unpack and unpack-dependencies goals (not used unless configured explicitly)</td>
</tr>
<tr>
<td>maven-ear-plugin</td>
<td>(,3.0.0]</td>
<td>3.0.1</td>
<td><a href="https://issues.apache.org/jira/browse/MEAR-268">MEAR-268</a></td>
- <td>EAR <a href="/plugins/maven-ear-plugin/modules.html">modules</a> feature (not used unless configured explicitely)</td>
+ <td>EAR <a href="/plugins/maven-ear-plugin/modules.html">modules</a> feature (not used unless configured explicitly)</td>
</tr>
<tr>
<td>maven-javadoc-plugin</td>
<td>[2.5,3.0.0]</td>
<td>3.0.1</td>
<td><a href="https://issues.apache.org/jira/browse/MJAVADOC-520">MJAVADOC-520</a></td>
- <td>resourcesArtifacts and includeDependencySources features (not used unless configured explicitely)</td>
+ <td>resourcesArtifacts and includeDependencySources features (not used unless configured explicitly)</td>
</tr>
<tr>
<td>maven-war-plugin</td>