svn commit: r1857419 - in /maven/website/content: maven-site-1.0-site.jar repository/guide-central-repository-upload.html

[sv...@apache.org]

Author: svn-site-role
Date: Fri Apr 12 17:16:27 2019
New Revision: 1857419

Log:
Site checkin for project Apache Maven Site

Modified:
    maven/website/content/maven-site-1.0-site.jar
    maven/website/content/repository/guide-central-repository-upload.html

Modified: maven/website/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.

Modified: maven/website/content/repository/guide-central-repository-upload.html
==============================================================================
--- maven/website/content/repository/guide-central-repository-upload.html (original)
+++ maven/website/content/repository/guide-central-repository-upload.html Fri Apr 12 17:16:27 2019
@@ -142,7 +142,7 @@ Brian Fox" />
 <h3><a name="Explanation"></a>Explanation</h3>
 <p>Some folks have asked <i>&quot;why do we require all this information in the POM for deployed artifacts?&quot;</i>, so here's a small explanation.</p>
 <p>The POM being deployed with the artifact is part of the process to make transitive dependencies a reality in Maven. The logic for getting transitive dependencies working is really not that hard, the problem is getting the data. The other applications that are made possible by having all the POMs available for artifacts are vast, so by placing them into the Central Repository as part of the process we open up the doors to new ideas that involve unified access to project POMs.</p>
-<p>We also ask for license now because it is possible that your project's license may change in the course of its life time and we are trying create tools to help normal people sort out licensing issues. For example, knowing all the licenses for a particular graph of artifacts, we could have some strategies that would identify potential licensing problems.</p></div>
+<p>We ask for the license because it is possible that your project's license may change in the course of its lifetime, and we are trying to create tools to help sort out licensing issues. For example, knowing all the licenses for a particular graph of artifacts, we could have some strategies that would identify potential licensing problems.</p></div>
 <div class="section">
 <h3><a name="A_basic_sample:"></a>A basic sample:</h3>
 <div class="source"><pre class="prettyprint linenums">
@@ -187,7 +187,7 @@ Brian Fox" />
 </pre></div></div>
 <div class="section">
 <h3><a name="PGP_Signature"></a>PGP Signature</h3>
-<p>When people download artifacts from the Central Repository, they might want to validate that these artifacts have valid PGP signatures that can be verified against a public key server. If there is no signatures, then users have no guarantee that they are downloading the original artifact.</p>
+<p>When people download artifacts from the Central Repository, they might want to verify these artifacts' PGP signatures against a public key server. If there are no signatures, then users have no guarantee that they are downloading the original artifact.</p>
 <p>To improve the quality of the Central Repository, we require you to provide PGP signatures for all your artifacts (all files except checksums), and distribute your public key to a key server like <a class="externalLink" href="http://pgp.mit.edu">http://pgp.mit.edu</a>. Read <a class="externalLink" href="http://central.sonatype.org/pages/working-with-pgp-signatures.html">Working with PGP Signatures</a> for more information.</p></div>
 <div class="section">
 <h3><a name="FAQ_and_common_mistakes"></a>FAQ and common mistakes</h3>
@@ -216,9 +216,9 @@ Brian Fox" />
 <p>The easiest way to upload another project is to use the <a class="externalLink" href="http://central.sonatype.org/pages/ossrh-guide.html">Open Source Software Repository Hosting (OSSRH)</a>, which is an approved repository provided by Sonatype for <i>any</i> OSS Project that want to get their artifacts into the Central Repository.</p></div>
 <div class="section">
 <h3><a name="Explanations"></a>Explanations</h3>
-<p>Having each project maintain its own repository with rsync to the Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis.</p>
+<p>Having each project maintain its own repository with rsync to the Central Repository was the preferred process until January 2010. However, we are no longer accepting rsync requests on a per project basis.</p>
 <p>Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone. </p>
-<p>The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone.</p></div></div>
+<p>The aggregation of projects into larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone.</p></div></div>
         </div>
       </div>
     </div>