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.

Sign up for GitHub

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

[MNG-7870] Undeprecate G level metadata #1224

Merged
merged 3 commits into from
Sep 7, 2023
Merged

[MNG-7870] Undeprecate G level metadata #1224

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
dd260fb
[MNG-7870] Undeprecate G level metadata
cstamas Sep 5, 2023
d9f59a8
Remove the fluff even more
cstamas Sep 6, 2023
a9843a2
Restore page as is, remove deprecation message,link it to other page.
cstamas Sep 6, 2023
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
10 changes: 2 additions & 8 deletions maven-repository-metadata/src/main/mdo/metadata.mdo
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,10 +74,7 @@ under the License.
<field xdoc.separator="blank">
<name>plugins</name>
<version>1.0.0+</version>
<description>The set of plugins when this directory represents a "groupId" (deprecated)</description>
<annotations>
<annotation>@Deprecated</annotation>
</annotations>
<description>The set of plugins when this directory represents a "groupId".</description>
<association>
<type>Plugin</type>
<multiplicity>*</multiplicity>
Expand Down Expand Up @@ -383,10 +380,7 @@ under the License.
<class java.clone="deep">
<name>Plugin</name>
<version>1.0.0+</version>
<description>Mapping information for a single plugin within this group (deprecated).</description>
<annotations>
<annotation>@Deprecated</annotation>
</annotations>
<description>Mapping information for a single plugin within this group.</description>
<comment>NOTE: plugin version is _NOT_ included here, since it is resolved using a separate algorithm in plugins' artifact.</comment>
<fields>
<field>
Expand Down
30 changes: 0 additions & 30 deletions maven-repository-metadata/src/site/apt/index.apt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,38 +27,8 @@ Maven Repository Metadata Model

This is strictly the model for Maven Repository Metadata, so really just plain objects.

The metadata file name is:

* <<<maven-metadata.xml>>> in a remote repository,

* <<<maven-metadata-\<repo-id>.xml>>> in a local repository, for metadata from a repository with <<<repo-id>>> identifier.

[]

Depending on what the directory represents ("groupId", "groupId/artifactId" or "groupId/artifactId/version"),
the Maven Repository Metadata file contains 3 different sets of metadata:

[[1]] in a "groupId" directory: a "groupId" directory may contain Maven plugins artifacts, which are described in metadata's <<<plugins>>> element,

[[2]] in a "groupId/artifactId" directory: metadata describes <<<groupId>>>, <<<artifactId>>> and <<<versioning>>> element that
gives data about available versions (<<<latest>>>, <<<release>>>, <<<versions>>> list and <<<lastUpdated>>>),

[[3]] in a "groupId/artifactId/version" snapshot artifact directory: metadata describes <<<groupId>>>, <<<artifactId>>>, <<<version>>> (base version, i.e. ending in <<<-SNAPSHOT>>>) and
<<<versioning>>> element that gives data about snaphot (<<<snapshot>>>, <<<lastUpdated>>> and <<<snapshotVersions>>> list). Notice that a
release artifact directory is not expected to provide metadata.

[]

hboutemy marked this conversation as resolved.
Show resolved Hide resolved
The following are generated from this model:

* {{{./apidocs/index.html}Java sources}} with Reader and Writers for the Xpp3 XML parser, to read and write <<<maven-metadata(-*).xml>>> files,

* a {{{./repository-metadata.html}Descriptor Reference}}.

Notice: data about plugins in a directory representing a groupId is deprecated and will be removed in a future Maven version.
~~ logic behind this:
~~ 1. MNG-7266: maven-compat will be removed from future Maven version
~~ 2. this will remove the code that updates plugins data: see MNG-7375/MPLUGIN-384 https://maven.apache.org/ref/3.8.4/maven-compat/apidocs/org/apache/maven/artifact/repository/metadata/GroupRepositoryMetadata.html
~~ 3. this will lead to inconsistent data: removing it will be safer/more clear
~~ but this logic still remains to be confirmed by clear consensus of the whole team
Copy link
Contributor

Choose a reason for hiding this comment

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

IIUC, this is not wrong, but just too early, right ?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, this is plain wrong: assumes that two distinct things are "same thing" (maven-repository-metadata generated classes and maven-compat Metadata coming from Maven2, pre Aether times).

It blurs by mistake two distinct things, while they are not same (but their purpose WAS same, but latter should not be used anymore, while former is and should be used by resolver-provider ONLY)

Copy link
Member

Choose a reason for hiding this comment

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

can we clarify what fills the (effectively non-deprecated) metadata? And when Maven was fixed to update this metadata?
because this is the part that is not clear to me

Copy link
Member Author

Choose a reason for hiding this comment

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

It was done on master (#555) and ported to maven-3.9.x (#691)

The code is (and should remain) confined in maven-resolver-provider, as it "hooks" into resolver https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/impl/MetadataGeneratorFactory.java and does the job by simply inspecting the payload. Also notice that all this code is package protected (again, as this happens by "hooking into resolver, and is not an API that one should tamper/call").