You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. 🙂
The text was updated successfully, but these errors were encountered:
@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?
@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):
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. 🙁
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 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 themaven-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 themaven-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. 🙂
The text was updated successfully, but these errors were encountered: