gnodet commented on code in PR #2022:
URL: https://github.com/apache/maven-resolver/pull/2022#discussion_r3705438435


##########
src/site/markdown/what-is-resolver.md:
##########
@@ -18,47 +18,16 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-Did you ever want to integrate Maven's dependency resolution mechanism
-into your application and ended up trying to embed Plexus and an entire
-Maven distribution? Did you ever want to use Maven's dependency
-resolution mechanism in a multithreaded fashion and got burned by the
-stateful singletons in there? Did you ever want to have a little more
-control over how Maven calculates the resolved dependency graph, say use
-another strategy for conflict resolution or inspect some intermediate
-dependency graph?
+Did you ever want to integrate the Maven dependency resolution mechanism into 
your application? Did you then try to embed Plexus and an entire Maven 
distribution? Did you want to use the mechanism in a multithreaded way? The 
stateful singletons in Maven caused problems. Did you ever want more control 
over the resolved dependency graph? For example, to can use another strategy 
for conflict resolution, or inspect an intermediate graph?
 

Review Comment:
   Grammar error introduced in the second commit: "to can use" is not valid 
English.
   
   ```suggestion
   Did you ever want to integrate the Maven dependency resolution mechanism 
into your application? Did you then try to embed Plexus and an entire Maven 
distribution? Did you want to use the mechanism in a multithreaded way? The 
stateful singletons in Maven caused problems. Did you ever want more control 
over the resolved dependency graph? For example, you can use another strategy 
for conflict resolution, or inspect an intermediate graph?
   ```



##########
src/site/markdown/what-is-resolver.md:
##########
@@ -18,47 +18,16 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-Did you ever want to integrate Maven's dependency resolution mechanism
-into your application and ended up trying to embed Plexus and an entire
-Maven distribution? Did you ever want to use Maven's dependency
-resolution mechanism in a multithreaded fashion and got burned by the
-stateful singletons in there? Did you ever want to have a little more
-control over how Maven calculates the resolved dependency graph, say use
-another strategy for conflict resolution or inspect some intermediate
-dependency graph?
+Did you ever want to integrate the Maven dependency resolution mechanism into 
your application? Did you then try to embed Plexus and an entire Maven 
distribution? Did you want to use the mechanism in a multithreaded way? The 
stateful singletons in Maven caused problems. Did you ever want more control 
over the resolved dependency graph? For example, to can use another strategy 
for conflict resolution, or inspect an intermediate graph?
 
-Well, Resolver (former Aether) is the answer. It's an *embeddable Java library 
to
-work with artifact repositories*, enabling you to fetch artifacts from
-remote repositories for local consumption and to publish local artifacts
-to remote repositories for sharing with others.
+Resolver (formerly Aether) is the answer. It is an *embeddable Java library 
that works with artifact repositories*. It can fetch artifacts from remote 
repositories for local consumption. It can also publish local artifacts to 
remote repositories to share with others.
 
-There are many ways to transfer artifacts, to describe their
-relationships and to use them. Resolver was designed with an open mind
-towards customization of these aspects, allowing you to augment or even
-replace stock functionality to fit your needs. In fact, the Resolver Core
-itself doesn't know how to deal with Maven repositories for instance.
-It's tool agnostic and provides some general artifact
-resolution/deployment framework and leaves details like the repository
-format to extensions.
+There are many ways to transfer artifacts, describe their relationships, and 
use them. Resolver was designed to be customizable, so you can augment or 
replace the stock functionality. The Resolver Core itself does not know how to 
handle Maven repositories, for example. It is tool agnostic. It provides a 
general artifact resolution and deployment framework and leaves details such as 
the repository format to extensions.
 
-At this point, the `maven-resolver-provider` from the [Apache
-Maven](http://maven.apache.org/) project is probably the most
-interesting extension as it brings support for, well Maven repositories.
-So if you're looking for a way to consume artifacts from the [Central
-Repository](http://search.maven.org/), Resolver in combination with the
-Maven Resolver Provider is your best bet. Usage of Resolver in this way does
-not only ease your work when dealing with artifacts but also ensures
-interoperability with other tools that work with Maven repositories.
+The `maven-resolver-provider` from the [Apache 
Maven](https://maven.apache.org/) project supports Maven repositories. If you 
want to consume artifacts from the [Central 
Repository](https://search.maven.org/?eh=), Resolver together with the Maven 
Resolver Provider is the best choice. This simplifies your work with artifacts. 
It also ensures interoperability with other tools that work with Maven 
repositories.
 

Review Comment:
   The three hyperlinks from the previous review are still missing. STE governs 
word choice and sentence structure — hyperlinks are navigational aids that help 
readers find these resources. Consider restoring them:
   
   ```suggestion
   The `maven-resolver-provider` from the [Apache 
Maven](http://maven.apache.org/) project is the most interesting extension. It 
brings support for Maven repositories. To consume artifacts from the [Central 
Repository](http://search.maven.org/), Resolver together with the Maven 
Resolver Provider is the best choice. These simplify your work with artifacts 
and ensure interoperability with other tools that work with Maven repositories.
   ```
   
   Also consider restoring the MIMA link on line 34: 
`[MIMA](https://github.com/maveniverse/mima)`.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to