[MNG-7870] Undeprecate G level metadata#1224
Conversation
| ~~ 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 |
There was a problem hiding this comment.
IIUC, this is not wrong, but just too early, right ?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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").
hboutemy
left a comment
hboutemy
left a comment
There was a problem hiding this comment.
is it https://issues.apache.org/jira/browse/MNG-7055 ?
I'd prefer keeping a comment in this documentation, because it's hard to track
|
Yes, it was done as part of MNG-7055:
|
|
My point is, that the related code change simply made G level metadata work the "same way" as GA and GAV level metadata worked: user needs not to manage it, it all happens transparently from user POV, is done by resolver "behind the curtains", without user interaction. |
|
And finally, i find this page (rendered as part of maven-repository-metadata site) a bit anemic, and IMHO missing the point: https://maven.apache.org/ref/3.9.4/maven-repository-metadata/index.html Especially when I put it next to this page: Former page, that is about maven-repository-metadata module (that contains ONLY the modello generated model classes) talks about "local" and "remote" metadata, that is totally irrelevant, and none of those things happens in given module. The "metadata file names" are irrelevant (are defined by layout), and page https://maven.apache.org/repositories/metadata.html IMHO describes much better all of it (from remote repo aspect, it does not mention "locally cached" metadata either). So, I'd propose to modify page even more, and just keep this: |
This module really generates JUST the object that are used to describe G, GA and GAV level maven metadata. How the file is named, how is locally cached one named is totally irrelevant (as it is defined by layout and resolver cache logic).
hboutemy
left a comment
hboutemy
left a comment
There was a problem hiding this comment.
keep the description text, but add a link to end-user doc https://maven.apache.org/repositories/metadata.html
|
ping? |
|
Closed by mistake, reopened |
The modello generated classes should not be deprecated, and they are in use. Forward port of 84ee422 --- https://issues.apache.org/jira/browse/MNG-7870
|
Resolve #9047 |
4 participants
The modello generated classes should not be deprecated, and they are in use.
https://issues.apache.org/jira/browse/MNG-7870