bmuschko / gradle-cargo-plugin

Gradle plugin that provides deployment capabilities to local and remote containers via Cargo
Apache License 2.0
258 stars 61 forks source link

gradle up-to-date logic broken for Deployable #97

Closed OverDrone closed 10 years ago

OverDrone commented 10 years ago

AbstractCargoContainerTask contains property @Input @Optional List deployables = []

but this property would never be considered up-to-date because of missing custom equals method with default Object.equals returning false always. See http://www.gradle.org/docs/current/javadoc/org/gradle/api/tasks/TaskInputs.html#property(java.lang.String,%20java.lang.Object) for more details. To fix that bug you should add following method to org.gradle.api.plugins.cargo.convention.Deployable:

boolean equals(def obj) { if (obj == null) { return false } else if (obj.class != Deployable.class) { return false } else { Deployable that = obj return that.file == this.file && that.context == this.context } }

bmuschko commented 10 years ago

Would you mind providing a pull request for this? The change should also take into account other POJOs used as input properties like ConfigFile and BinFile in LocalCargoContainerTask.

Even if you add the methods, all tasks only define inputs but no outputs. For incremental build functionality to work, you'd also need to provide outputs which would be fairly tricky. You'd need to ask the target server if the artifact(s) are already deployed and that would have to work uniformly across all server products.

OverDrone commented 10 years ago

providing a pull request for this? Could you pls clarify, I'm afraid I don't understand, I'm a newbie here You are correct about outputs, but I managed to create a workaround: I create single file in output folder and touch it every deploy. I register this file as output so gradle don't deploy if source file isn't changed. I understand that it's not a fair solution, you don't know what happened with your deployed application on target server, it could be already undeployed or redeployed. I only suggest that you only add those custom equals methods to those pojos and leave custom up-to-date logic to plugin users So that I don't have to create additional classes like in attached example

OverDrone commented 10 years ago

import org.apache.commons.io.FileUtils;

apply plugin: "cargo-base"

task redeploy(type: MyCargoRedeployRemote) { inputs.source buildscript.sourceFile String warPath = "$buildDir/myapp.war" inputs.file warPath ext.touchFile = new File("${buildDir}/redeployTomcat.txt") outputs.file touchFile containerId = 'tomcat6x' String containerUrl = '' URL url = new URL(containerUrl) protocol = url.protocol hostname = url.host port = url.port username = '' password = '' deployables = [new MyDeployable(file: file(warPath), context: "mywar")] }

//adding custom equals for gradle up-to-date logic works class MyDeployable extends Deployable { boolean equals(def obj) { if (obj == null) { return false } else if (obj.class != MyDeployable.class) { return false } else { MyDeployable that = obj return that.file == this.file && that.context == this.context } } String toString() { return "file=${file},context=${context}" } }

//required so that MyDeployable is loaded from correct classloader //to prevent ClassNotFound(MyDeployable) class MyCargoRedeployRemote extends CargoRedeployRemote { }

OverDrone commented 10 years ago

I've created pull request https://github.com/bmuschko/gradle-cargo-plugin/pull/98 I've changed all pojos that implement Serializable