Discussion: should the maven-metadata.xml be shown on the package UI
Context
When the user allows Maven duplicates, each publish to the registry adds
- the
maven-metadata.xml
to the versionless package (package with no version) - the .pom and .jar files to the package with a version.
When consuming the package, only the latest maven-metadata.xml
is served. The user cannot access the older maven-metadata.xml
files on the UI or API.
A note about snapshots
Currently Maven snapshots do show the maven-metadata.xml
in the UI.
Snapshot packages don't have 1
but 2
maven-metadata.xml
files:
- One in the versionless package (<- this one exists for all maven packages)
- One in the package with the version (<- this one only exists for snapshot versions)
(1.) is not visible in the UI. (2.) being in the package with the version, you can see it in the UI.
Question
Should we show the (versionless package) maven-metadata.xml
on the UI?
maven-metadata.xml
User should not be able to delete the Note: if we show the file the UI, we should not allow the user to delete it.
This file is technically the state of the package registry for a given package. This is used during the requests $ mvn
when $ mvn
asks: Hey third party registry, which versions of package foobar are available?
. This is when the backend returns the most recent maven-metadata.xml
file.
Because of the above, if we allow the delete operation on that file, this can have a pretty deep impact on the registry behavior for that package (eg. $ mvn
could complain that a specific version doesn't exist on the registry).
Options
- we show the file the UI but do not allow delete operation - consistent with competitors, maybe more clear what is being stored as part of the package.
- we continue to not show it. - I have not seen any customer complaints about not showing it.