Ivysettings to pass to an anttask?

Old Forum Archive
1

Hello,

Like many others, I am migrating from ant/ivy to gradle… One of the things that we do at our company is have the CI server bump the ‘patch’ number of the version.

We currently use ivy’s buildnumber task to do this. I have the task defined (and I can call it), but I think I need to pass it a settingsRef (a reference to ivysettings)…

configurations{
        ivy
}
             dependencies {
         ivy fileTree(dir: System.getenv('IVY_HOME'), include: '*.jar')
}
  repositories {
    ivy{
            name 'myResolver'
            url "http://xxx/ivy/private"
            layout 'pattern' , {
                    artifact "[organisation]/[module]/development/[revision]/[artifact](-[classifier]).[ext]"
                    ivy "[organisation]/[module]/development/ivys/ivy-[revision].xml"
        }
   }
}
    String getIvyBuildNumber() {
        ant.taskdef( resource:"org/apache/ivy/ant/antlib.xml", classpath: configurations.ivy.asPath, uri: 'org.apache.ivy.ant')
        ant.'org.apache.ivy.ant:buildnumber' (
                organisation : project.getGroup(),
                module : project.getName(),
                resolver : 'myResolver',
                settingsRef : 'XXX'
        )
        return ant.properties['ivy.new.build.number']
}

Basically, I need to be able to tell the Ivy task about the “settings” that I currently have defined in Gradle… Can I get this information? or am I going about this all wrong?

Thanks, Marc

__ ref: buildnumber doc: http://ant.apache.org/ivy/history/2.2.0/use/buildnumber.html

2

There is nothing built into Gradle to help with this. If you choose to use Ivy (the library) in a Gradle build, you are on your own. Not sure where you’d get an Ivy Settings object from (perhaps an Ivy configure task?).

3

I figured as much… I was trying to follow up on this discussion: http://forums.gradle.org/gradle/topics/can_we_use_ivy_buildnumber_or_an_equivalent_from_gradle

But, I think i’ll just use our CI’s build number… That should be easier and will help “quickly” map

RPM versions to the actual build.

Thanks again for the quick response. Marc