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

Maven metdata still references a version whose assets were deleted #524

Open
yakirm-cr opened this issue Nov 22, 2024 · 2 comments
Open
Assignees

Comments

@yakirm-cr
Copy link

yakirm-cr commented Nov 22, 2024

  • What problem are you trying to solve?
    When deleting all of the assets under a specific version in a hosted Maven repository, the version is NOT deleted from the maven-metadata.xml file of that GA (GroupId and ArtifactId) coordinates.
    Manually, uploading the maven-metadata.xml file without that version remains like this until another version's assets are removed (after which, the contents of the maven-metadata.xml of that GA coordinates are restored with the deleted versions).
    The issue is not encountered when the parent component (i.e. the version folder) is deleted.

  • Do you have a workaround you are using at present?
    If we upload a dummy artifact with the same GAV (GroupId, ArtifactId and Version) coordinates of the deleted version and then delete parent component (i.e. the version folder), the maven-metadata.xml is regenerated without the deleted version.
    However, this might be complicated when there are many corrupted maven-metadata.xml files.

In addition, the repair task which rebuilds the maven-metadata.xml files also picks up the components for which all the assets were deleted and adds them back to the maven-metadata.xml files (so, it is not an option to use this task as a workaround).

  • What feature or behavior is this required for?
    Moving of old versions from a hosted Maven repository to another or deleting old versions (for multiple artifacts with the same version).

  • How could we solve this issue? (Not knowing is okay!)
    Update the delete asset API to make sure that the parent component is also deleted when the last asset under it is deleted.

  • Tell us about your Nexus Repository deployment: what version, operating system, and database are you using?
    We are using OSS Nexus 3.73.0 with the internal H2 DB running in Docker.

  • Anything else?
    Nope. 🙂

@mrprescott
Copy link

@yakirm-cr Can you say more about why you're removing assets systematically rather than removing the component? Do you have separate processes that remove some of the assets, and sometimes between them all they've removed everything?

@yakirm-cr
Copy link
Author

@mrprescott
At the moment we are using the components removal API (instead of the assets removal API).
The removal of assets/components is based on a search results by a specific criteria.
In a previous release of Nexus (3.63.0 or before, I cannot be sure exactly which one) we faced an issue when attempting to delete a component via the REST API (error 404 for a component listed in the search results).
We now know that there was an issue with the search index and there is a task that can repair it, but at the time we found that removing assets is a workaround for the error (with the side effect described in this issue).

Basically, there are two issues here (when the last asset is deleted):

  1. The UI no longer shows this version folder and it is not listed in the search results (even though, it still seems to exist).
    So, it cannot be removed from the UI as well. 🙁
  2. Nexus regenerates the maven-metadata.xml whenever another components is deleted with reference to the empty component. 🙁

The way I see it, one of the following should apply:

  • Delete a component when the last asset is deleted.
  • Empty components should be listed in the UI and in the search results.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants