[MNGSITE-393] Remove references to Maven 2.x (#2024)

Author: elharo

api/maven-api-settings/src/main/mdo/settings.mdo

@@ -546,9 +546,9 @@
           <type>String</type>
           <description>
             <![CDATA[
-            A repository id or (since Maven 2.0.9) an expression matching one or many repository ids to mirror, e.g.,
+            A repository id or an expression matching one or many repository ids to mirror, e.g.,
             <code>central</code> or <code>*,!repo1</code>.
-            <code>*</code> (since Maven 2.0.5), <code>external:*</code> (since Maven 2.0.9) and <code>external:http:*</code> (since Maven 3.8.0) have
+            <code>*</code>, <code>external:*</code> and <code>external:http:*</code> (since Maven 3.8.0) have
             a special meaning: see <a href="/guides/mini/guide-mirror-settings.html">Mirror Settings</a> guide.
             ]]>
           </description>
@@ -896,7 +896,7 @@
           <version>1.0.0+</version>
           <description>
             What to do when verification of an artifact checksum fails. Valid values are "fail" (default for Maven 4 and
-            above), "warn" (default for Maven 2 and 3) or "ignore".
+            above), "warn" (default for Maven 3) or "ignore".
           </description>
           <type>String</type>
         </field>

api/maven-api-toolchain/src/main/mdo/toolchains.mdo

@@ -136,7 +136,7 @@
         <field>
           <name>provides</name>
           <version>1.0.0/1.0.99</version> <!-- fake upperbound, it's inclusive -->
-          <type>DOM</type> <!-- DOM for Maven 2.0.9/2.3.3 -->
+          <type>DOM</type>
           <description>
             Toolchain identification information, which will be matched against project requirements.
             &lt;p>Actual content structure is completely open: each toolchain type will define its own format and
@@ -148,18 +148,14 @@
         <field>
           <name>provides</name>
           <version>1.1.0+</version>
-          <type>Properties</type> <!-- Properties for Maven 2.3.4+ -->
+          <type>Properties</type>
           <association xml.mapStyle="inline">
             <type>String</type>
             <multiplicity>*</multiplicity>
           </association>
           <!-- <identifier>true</identifier> -->
           <description>
             Toolchain identification information, which will be matched against project requirements.
-            &lt;p>For Maven 2.0.9 to 3.2.3, the actual content structure was completely open: each toolchain type would
-            define its own format and semantics. This was generally a properties format.
-            &lt;p>Since Maven 3.2.4, the type for this field has been changed to Properties to match the de-facto
-            format.
             &lt;p>Each toolchain defines its own properties names and semantics.
           </description>
         </field>

compat/maven-compat/src/main/mdo/profiles.mdo

@@ -24,7 +24,7 @@ under the License.
   <id>profiles</id>
   <name>Profiles</name>
   <description><![CDATA[
-    <b>Deprecated in Maven 2</b> Project-local overrides to the build process based on detected or user-provided environmental parameters.
+    <b>Deprecated</b> Project-local overrides to the build process based on detected or user-provided environmental parameters.
     This is the model specification for <code>${basedir}/profiles.xml</code>.
   ]]></description>
   <defaults>
@@ -309,7 +309,7 @@ under the License.
           <version>1.0.0</version>
           <description>
             What to do when verification of an artifact checksum fails. Valid values are "fail" (default for Maven 4 and
-            above), "warn" (default for Maven 2 and 3) or "ignore".
+            above), "warn" (default for Maven 3) or "ignore".
           </description>
           <type>String</type>
         </field>

impl/maven-core/plugin-manager.txt

@@ -103,8 +103,6 @@ h4. Working with POMs during development
 
 During the development of a plugin we would want to make it easy for a developer to create a plugin which means we would allow the direct use of a POM to state the dependencies of a given plugin and any tooling we created would be responsible for turning the dependency information in the POM into plugin metadata which described the dependencies of the plugin.
 
-We are looking at using Mercury for the resolution and retrieval of the plugin dependencies so during development we would translate the POMs into dependency information that Mercury can understand, and in production we would have the pre-digested format that Mercury could utilize to resolve and retrieve dependencies. We need to be careful that we are using Mercury during development and production so that we don’t get in the situation where Maven 2.x is resolving differently than Mercury is. We can still leverage POMs during development but we need to make sure Mercury is doing the work.
-
 With respect to development inside an IDE the workspace from which we would like to resolve and retrieve dependencies is a read-only local repository to Mercury which is put at the front-end of the search order of any repository that Mercury will consult for artifacts.
 
 h4. Generation of plugin metadata and packaging