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:
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’
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.