[IvyPublish] Dynamic version in published ivy.xml is not replaced when publishing


(Marcel Overdijk) #1

When using the incubating IvyPublish plugin dynamic versions in the published ivy.xml are not replaced with static values.

If you use standalone Ivy the replacement of dynamic version is by default switched on. See also Ivy docs related to replacedynamicrev on http://ant.apache.org/ivy/history/2.2.0/use/publish.html

Is there something I need to configure in Gradle to have the dynamic versions being replaced?

compile "commons-lang:commons-lang:2.+"

The above dependency will be published as seen below in ivy.xml:

<dependency name="commons-lang" conf="compile->default" rev="2.+" org="commons-lang"/>

Furthermore what I have a forced resolution strategy like:

configurations.all {
 resolutionStrategy {
  force 'commons-lang:commons-lang:2.5'
 }
}

then still the ivy.xml uses 2.+

I wonder if above is expected behavior or just functionality that needs to be enhanced in this incubating plugin?


#2

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.


(Stephane Galles) #3

There’s also something directly related to this use case in the release note of Gradle 1.3 :

http://www.gradle.org/docs/current/release-notes#new-ivy-publishing-mechanism

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


#4

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.


(Stephane Galles) #5

Well, as I don’t understand your comment about my answer, it makes me thing that I’m definitely missing something here :slight_smile:

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.


#6

Sorry, I thought you were interpreting the docs as if the functionality should be built in. My mistake. Your interpretation is exactly correct.


(Marcel Overdijk) #7

Yes I understand something can be done like this but it might be good to offer more functionality out of the box (enhancement)?


(Marcel Overdijk) #8

Further more I found out then when using e.g.the dependency:

compile "commons-lang:commons-lang:2.+"

and having it forced to:

configurations.all {
    resolutionStrategy.force([
        "commons-lang:commons-lang:2.5",

Then the published ivy.xml contains version 2.x.

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.