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:

1. One in the versionless package (<- this one exists for all maven packages)
2. 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?

User should not be able to delete the maven-metadata.xml

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 🏓 with $ 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

1. 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.
2. we continue to not show it. - I have not seen any customer complaints about not showing it.