There is no built-in support for “ivy-deliver” with the new ivy-publish plugin. You can implement something similar using the withXml() hook when publishing. Check out the user guide.
With this hook, you can modify any aspect of the descriptor. You could for example easily build a functionality similar to Ivy deliver on top of this in conjunction with the new Resolution Result API. In general, it can be useful to optimize the descriptor for consumption instead of having it be an accurate record of how the module was built
I’m not sure what you’re suggesting here. The docs discuss the low-level functionality available, and how you could build an ivy-deliver style functionality on top of this low-level functionality.
Well, as I don’t understand your comment about my answer, it makes me thing that I’m definitely missing something here
AFAICT both your answer and my answer were : 1) Yes you can build an ivy-deliver style functionality 2) you need the withXml() hook and in my anwser I was simply adding 3) and per the “Gradle 1.3 release note” you will also need the “new Resolution Result API”
I thought that 3) was interesting because I did not see it mentioned in an other documentation in direct relation with this use case (that’s to say “replace dynamic rev by static rev”). But I may simply delete my answer if you think that it is misleading.
Yes it’s arguable what version should end up in ivy.xml, but I still think the Ivy Publish plugin should be more configurable with options. Like to support a option similar to “replacedynamicrev” in Apache Ivy and/or to use forced module versions.