Fetching the previous version of a project's jar

[Jim_Holmes]

I’m giving this another chance to hopefully get a response. Am I explaining the issue clearly enough? Even if this isn’t possible, I’d like some confirmation that I’m not missing something. Thanks…

Continuing the discussion from How can I grab the previous version of a project's jar?:

@Jim_Holmes

We are publishing artifacts to an Ivy repository in Artifactory. We have the requirement that new versions of jars are only published if they have changed from the previous version. Whether an artifact has changed is determined by a separate in-house tool with its own set of rules. The tool simply takes the previous and current jars and compares them.

I was assuming I could grab the previous jar by simply resolving the ‘latest.integration’ version of the current artifact from the repo since the new one hadn’t been published yet:

task difference {
    project.configurations {
        differencing
    }
      project.dependencies {
        differencing "$project.group:$project.name:latest.integration"
    }
      doLast {
        println project.configurations.differencing.singleFile
    }
}

When I run this task, the result of the configuration resolve always points to the output of the current project’s jar task (whether that jar exists yet or not). This is true no matter what version I request, so it appears Gradle is short-circuiting the resolve if the group and name match a current project of the build.

I understand why Gradle might do that, such as someone accidentally adding an artifact dependency on a subproject rather than an explicit project dependency. Is there a way i can bypass this behavior and resolve a previous version?

Continuing the discussion from How can I grab the previous version of a project's jar?:

@Jim_Holmes

I’m still struggling with this. I’ve investigated just about every API path off of a configuration and I can’t figure out how to resolve the previous published version of a project’s jar. The closest thing I’ve found is a ComponentSelectionRule:

configurations.differencing.resolutionStrategy {
    componentSelection {
        all { ComponentSelection selection ->
            println selection.candidate.version
        }
    }
}

This actually prints out the previous version of the jar. This is encouraging since it tells me that Gradle did in fact resolve against the Ivy repo to discover that version and obviously has that knowledge stored somewhere. However, the only thing I can do here is reject it. Assuming I did know the actual version string ahead of time, it doesn’t seem to help. Even resolutionStrategy.force() with the specific version will still result in the configuration resolving to the current project jar.

At this point, i’m open to any solution even if it involves internal APIs.

[sterling (Sterling Greene)]

I think this is a side effect of the way we handle this internally. The current project is tracked by its group/name in the dependency graph, so when you try to add the same group/name with a different version, those two things collide.

I can’t think of a way to do this and still use the configuration/dependency management infrastructure. If you only care about the jar, could you construct the URL to download it from (e.g., http://yourartifactory/repo/<group>/<name>/<version>/<name>-<version>.jar) There might be some helper methods/classes to make that a little cleaner.

[Jim_Holmes]

Thanks for the reply. I could pull directly from Artifactory, but it’s not that simple since I don’t know the version. I would have to use Artifactory’s rest API to figure out what the latest version is. This is possible of course, but not ideal since it ties my solution to usage of Artifactory.