Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Jan 22, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions api/maven-api-settings/src/main/mdo/settings.mdo
Original file line number Diff line number Diff line change
Expand Up @@ -542,9 +542,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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to move the documentation in the code rather than keeping it external ?
It's easier to maintain as using a single PR allows updating both the code and the doc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you're proposing here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion was to inline the content of https://maven.apache.org/guides/mini/guide-mirror-settings.html into the model, so that the generated javadoc for the Mirror class will contain the documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't prefer that. guide-mirror-settings.html is written for people who simply use Maven for their own projects and might never look at the API docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. My point was to move the documentation inside the code base along the source code.
It could be put in https://github.com/apache/maven/tree/master/src/site rather than in an unversioned area from a different git repository.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe then. I'm not sure how maven site is published and what parts come from where.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we remove references to old version, what's the point of keeping the ref for Maven 3.8.0 ?

]]>
</description>
Expand Down Expand Up @@ -892,7 +892,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>
Expand Down
8 changes: 2 additions & 6 deletions api/maven-api-toolchain/src/main/mdo/toolchains.mdo
Original file line number Diff line number Diff line change
Expand Up @@ -126,7 +126,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
Expand All @@ -138,18 +138,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>
Expand Down
4 changes: 2 additions & 2 deletions compat/maven-compat/src/main/mdo/profiles.mdo
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -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>
Expand Down
2 changes: 0 additions & 2 deletions impl/maven-core/plugin-manager.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading