Gradle overriding version for configuration dependency on current artifact

I have a gradle deploy task that uses a ‘deployJars’ configuration to grab the jars to deploy to a given environment. For some reason, when pulling the dependency for the current project, the deploy version number is overridden by the value of ‘version’ for the current script. It’s probably easier to understand with an example:

group = “”

version = “1.0.3-SNAPSHOT”

def allSystemProperties = System.getProperties()

def deployVersion = allSystemProperties.getProperty(“deployVersion”) ?: null

configurations {


deployJars.transitive = false


configurations.deployJars {

resolutionStrategy {

force “$deployVersion”



dependencies {

if (deployVersion) {

deployJars “$deployVersion”

deployJars “com.scripps.mpxingestion:common-library:$commonLibraryVersion”

deployJars “org.apache.servicemix.bundles:org.apache.servicemix.bundles.jedis:${jedisVersion}_1”



task deploy() << { … }

So, I’ll call the deploy task with -DdeployVersion=1.0.2, but when I do

println configurations.deployJars.asPath

It will show that it has picked up instead of 1.0.2.

Any suggestions? Thanks!

Are you trying to deploy the local jars that were built for the current project or jars that are in an artifact repository?

Is the artifact-id == current project name?

Trying to deploy jars that are in an artifact repository. And yea, artifact-id is the current in settings.gradle.

Ah, yeah. It’s a side effect of the way we keep track of the local project’s output internally. The dependency and the local project have the same group:name and they collide somewhere so only the local project version wins.

I think the easiest way to be able to do this from the same project is to create a subproject for it.

e.g., in settings.gradle add:

include 'deployer'

In deployer/build.gradle put your deploy task and dependencies. You should be able to then use ‘./gradlew deployer:deploy -DdeployVersion=1.0.2’

Alright thanks. So are there any plans to fix this or is this not considered a bug?

It’s a variant of GRADLE-2713. Like Luke says, it’s hard to fix given the way we keep track of the dependencies internally. So, it’s a bug, but there are no plans to fix it right now. I think it’s more common to want to deploy your current build vs download+deploy a different version (of the same project). It’s unfortunate that it seems to quietly do the wrong thing right now.

Ok, thanks! I really appreciate your help!