Pytry
Pytry

Reputation: 6400

Delete and/or Replace Artifacts in Nexus using Gradle

I am still new to Gradle and Nexus.

I want to be able to remove artifact from a hosted nexus repository with Gradle. Using the nexus GUI in order to do this is not an option, because I don't wanna.

Part of the reason for wanting this is to be able to automatically correct upload errors such as incorrectly labeled artifacts, or artifacts uploaded with he wrong version. I may also just want to wipe out an entire project and all versions of it (maybe because it was uploaded to the wrong repo, or I'm just doing some house cleaning. OR perhaps I want to overwrite the currently up-loaded version of an artifact. Anyways, I don't have a real use case right now, but I still want to know how to do it.

Edit: Also, I'm curious about ways to "gracefully" handle times when a certain artifact version is already uploaded, such as catching a specific exception and outputting a user friendly message to advise the developer to update the build version before uploading.

Here's my current uploadArtifact task.

uploadArchives {
    repositories {
        flatDir {
            dirs 'repos'
        }
        mavenDeployer {
            credentials {
                username "user"
                password "password"
            }
            url "http://localhost:8081/nexus/content/repositories/releases/"
        }
    }
}

Upvotes: 1

Views: 2701

Answers (1)

Peter Niederwieser
Peter Niederwieser

Reputation: 123910

There isn't anything built into Gradle to manage a Nexus repository. Unless you find a third-party Gradle plugin for this, you'll have to develop your own solution. For example, you could write one or more Gradle tasks that use Nexus' REST APIs to accomplish what you want.

PS: Maven repositories are designed to be immutable, and changing any data or metadata after it has been published is generally frowned upon. (Instead a new version should be published that fixes the problem.) For such a change to take affect, every developer and CI machine will have to run all affected builds with --refresh-dependencies in order to invalidate the local cache (or wipe out the whole cache). This will likely cause lots of pain.

Upvotes: 3

Related Questions