Upload task serves two purposes, it creates the ivy.xml AND publishes

(Justin Ryan) #1

I’d really like to see a separation between the generation of the ivy.xml (and maybe also the pom.xml, but I don’t do that) and the actually publishing of artifacts. It makes more sense to me that ivy.xml is the output one task and the input for any publishing that might happen. It sorta flies in the face of using input/outputs on tasks if tasks are going to generate output AND use them at the same time. This is relevant because I need to see everything that would be published before it gets published, it’s sorta like maven’s install where it does everything locally before uploading it. Right now, it’s conjoined in the Upload task calling the ArtifactPublisher.publish and I can’t easily get the ivy.xml without an Upload task. Or am I missing something? Is ivy.xml the output of some task with no other side-effects?

The other reason I would need this is I have to publish two places, sometimes to maven central (oss.sonatype.com) via the maven plugin and sometimes to a private artifactory instance. And this might be another bug, but the maven plugin takes over any UploadArchives task with the mavenDeployer repository. Then the artifactory plugin depends on the uploadArchives task and ivy.xml, which causes my maven deploy before doing an Artifactory deploy. I’m guessing that what they really want is just the ivy.xml, but they can’t get it without being dependent on uploadArchives.

(Peter Niederwieser) #2

Having separate tasks for creating ivy.xml and pom.xml is on our radar. A workaround for the Ivy case is to trick the Upload task into just creating an ivy.xml:

configurations {
  task createIvyXml(type: Upload) {
  configuration = configurations.dummy
  uploadDescriptor = true
  descriptorDestination = file("$buildDir/ivy.xml")

There’s a similar workaround for pom.xml, but it’s a bit more complex.