Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Replace your Scripts with Gradle Tasks

DZone's Guide to

Replace your Scripts with Gradle Tasks

I really like Maven, and I really like the declarative build style, but recently I finally came to understand why Gradle is better.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

I really like Maven, and I really like the declarative build style, but recently I finally came to understand why Gradle is better.

For small projects that produce a common library JAR, you can still use Maven, but real-life, complex software projects always contain a lot of support scripts for deployment, copying artifacts, and so on. For some of those tasks you can find Maven plug-ins, for most of them you can write Maven plugins, but in real life you have shell scripts to do the job.

The problem with such scripts is that they contain paths and file names, which are part of the build. And if you change your pom.xml, you should change those scripts as well.

Gradle solves the problem. Your scripts are now part of the build; they can use build paths and artifact names, and they can depend on build stages.

I will show a small example: deploying WAR using SSH to a remote server. The example uses the Gradle SSH plugin.

Notice that we use the WAR name from the build and that the deployment task depends on the test, so we can't deploy if the tests fail

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.hidetake:gradle-ssh-plugin:0.1.7'
    }
}

apply plugin: 'ssh'
apply plugin: 'war'


war {
    archiveName = 'rest.war'
}

dependencies {
  //...


}


ssh {
    config(StrictHostKeyChecking: 'no')
}
remotes {
    testserver {
        host = 'myserver.com'
        user = sshuser
        identity = file("${System.properties['user.home']}/.ssh/id_dsa")
    }


}

task deployTestServer << {
    deploy(remotes.testserver)
}



deployTestServer.dependsOn build


def deploy(def server) {
    logger.lifecycle("Deploying to $server")
    logger.lifecycle("Copying ${war.archivePath.absolutePath} to $server ... Be patient .. takes time ...")
    sshexec {
        session(server) {
            put(war.archivePath.absolutePath, war.archiveName)
        }
    }
    sshexecute(server, '/usr/share/tomcat7/bin/tomcat7 stop')
    sshexecute(server, 'rm -rf /var/lib/tomcat7/webapps/rest*')
    sshexecute(server, "cp ${war.archiveName}  /var/lib/tomcat7/webapps")
    sshexecute(server, '/usr/share/tomcat7/bin/tomcat7 start')
    sshexecute(server, '/usr/share/tomcat7/bin/tomcat7 status')
}



def sshexecute(def server, def cmd) {
    logger.lifecycle("Executing '$cmd'  ...")
    sshexec {
        session(server) {
            execute(cmd, pty: true)
        }
    }
 

}  


Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
java ,devops ,maven ,jar ,build ,tips and tricks ,gradle ,war

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}