2

I am using Gradle 2.4 to deploy artifacts developped in Grovvy and Java. I would like to check the actual existence of an artifact before its publication. One application is to avoid overwriting an artifact pulished in production. Another application would be to discover the next minor release to use for publishing a release for integration tests.

I am publishing into IVY repositories and my components are characterized by group, name, version. I would like to know how to use the Gradle API to check whether an artifact has already been published with these inputs.

Thanks, Loic.

Loïc Decloedt
  • 66
  • 5
  • "deploy artifacts" as in to jcenter? If you are publishing to jcenter, you can't publish the same version twice. – Jared Burrows Jul 23 '15 at 11:08
  • We are deploying in a local ivy repository. As a result, there is no such access control, AFAIK. – Loïc Decloedt Jul 23 '15 at 12:21
  • Ivy has a buildnumber task that can be used to increment a build number based on what has already been published. See: http://stackoverflow.com/questions/8452710/how-are-snapshot-and-release-repositories-used-differently/8456620#8456620 – Mark O'Connor Jul 25 '15 at 07:41

1 Answers1

0

I don't think there is a specific API dedicated to this, although it may be added to the publishing mechanism at some point in the future. The expectation is that you would normally use the repository configuration to specify that you don't want to allow overwrites.

As for the determining the next minor version, you should do a quick review of the available Gradle release plugins to see whether they do what you want. I simply did a web search for "gradle release plugin". The Axion one seems like the most up to date.

You can code the artifact check within your build file, as demonstrated on the Gradle forums. The effective but hacky solution is to add something like this:

uploadArchives {
  onlyIf {
    try {
      new URL("http://myrepo.com/${calculatedPathToWhereItWouldBePublished}").bytes
      false
    } catch (FileNotFoundException e) {
      true
    }
  }
}

A much cleaner approach would be to factor out your specific requirements into your own plugin.

Peter Ledbrook
  • 4,302
  • 1
  • 21
  • 18
  • The Axion plugin seems to be GIT specific and we are using SVN. So, it does not seem to fit our needs. – Loïc Decloedt Jul 24 '15 at 09:37
  • To deliver our modules, we do not upload to a server, but install them into a local IVY repository, so we use the "publish" task provided by the ivy-publish plugin. So, I am seekign for an equivalent solution with the "publish" task. – Loïc Decloedt Jul 24 '15 at 09:45