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.

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.

Learn How You Can Replace Your Scripts with Gradle Tasks

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. Gradle's modernization of the building process for plugins today helps to streamline building a plugin from start to finish. 

Using Gradle is also a way to minimize and eliminate guesswork when building a plugin from scratch. If you're looking for a way to save time while optimizing your programming efforts, Gradle offers a solution that is simple, straightforward, and easy to implement.

Advantages of Using Gradle

Using Gradle is not just about personal preferences. In fact, Gradle has plenty to offer that Maven simply cannot compete with, especially in terms of working on multiple projects simultaneously or working with various integrations. 

With Gradle, you have support for all processes of managing projects, from building and testing to deploying and launching the actual software on a host of platforms.

Because Gradle is open-source, developers also have much more creative control and flexibility when it comes to developing new software and implementing automation solutions in any project, regardless of size. A few of the most notable advantages of using Gradle over an alternative such as Maven include:

• Open-source: With Gradle, developers have many more options when it comes to programming and developing new software. Users can also easily write and build scripts with Java, making Gradle extremely accessible to those who are already familiar with working in Java in other areas.
• Dependency management: Gradle supports dependency management, which can help to streamline your efforts when developing new software.
• Scalable: One of the biggest advantages of using Gradle is the ability to scale projects with ease. Additionally, Gradle is known for its high performance regardless of project size and scalability options made available for the future.
• Multi-project structure support: If you are working on more than one project, you can do so effortlessly with the use of Gradle. Gradle includes multi-project structures, making it easier than ever to bounce from one project to the next with ease.
• Integration capabilities: Another reason Gradle stands out is the ability to easily migrate to Gradle from Maven as well as the easy integration process involved with using Gradle. Gradle provides a straightforward method of migrating from Maven to Gradle to make the process as painless and as effortless as possible at the developer's end.
• Faster speeds: If you are searching for project management tools that help to save time, Gradle is optimal over Maven, as it is significantly faster when it comes to compiling code and launching tests.
• Simplified build script: If you are interested in condensing the tools you use or if you are seeking a concise method of building a project, Gradle delivers. While Maven's pom.xml file has a total of 66 lines, Gradle's Groovy script comes in at only 37 lines, making it a bit easier to wade through various areas of coding. Fewer lines of coding also means improved readability.
• Dynamic build model: With Gradle, you can also take advantage of a dynamic build model, allowing you to make changes from wherever and within minutes. You can also use Gradle's own APIs in your build script for even more options when it comes to customizing your build script.
• Customization: With Gradle, it is possible to add single tasks directly into the build script of your project. On the other hand, if you are using Maven, you can add customized build logic with the use of custom plugins created by you or existing plugins available for Maven users. With the ability to add functionality and custom logic directly into a build script, Gradle makes it easier than ever to customize any type of project you are working on.
• Abbreviations: When creating any new project, having the ability to use abbreviations and shortcuts can help reduce time spent on tasks in a significant manner. With Gradle, you can also take advantage of abbreviated task names, making it much easier and quicker to execute Gradle tasks. Using shortened task names also allows you to streamline your workflow while executing tasks such as build, assemble, or even changing the name of a class you have created.

Converting Maven Projects to Gradle

If you have been working in Maven but wish to transition to working with Gradle, you can do so once you are familiar with the platforms and once you understand how to convert Maven projects to Gradle.

Although converting a Maven project to Gradle only requires one step, it is important to become comfortable with executing the process, especially if you are working with more than one project that you would like to convert from Maven to Gradle. 

Once you are familiar with both Maven and Gradle interfaces, you can then easily migrate your projects without feeling unsure about where to begin and how to do so safely.

Use Gradle Guides

Using a complete guide for the Gradle plugin is highly advisable for developers who are interested in creating their very own plugins with the use of Gradle. If you are familiar with working with Java or if you are interested in building a plugin with the use of Java, two of the most popular tools used to do so include Maven and Gradle.

With Gradle's Java application guide, discover the pros and cons of building with Gradle as well as dependencies and the basics of Gradle to help get you started. With the included guide, you can also take advantage of available script samples and live examples to help you with becoming familiarized with the setup and platform of working with Gradle and Java. 

You can also learn to manage dependencies with dependency constraints when working with Gradle.

Deploying WAR using Gradle

The WAR plugin available for Gradle provides additional Java plugin features for working with web application WAR projects and files. When using WAR, keep in mind that the default JAR will be disabled while WAR will be updated as the default selection.

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)
        }
    }
 }