Tag: gradle

Experiments with Gradle in the IntelliJ IDEA IDE

I’ve recently started using JetBrain’s IntelliJ IDEA software to develop software written in Groovy at work. It is an excellent package well worth it’s modest price. I have been investigating the differences between the Ultimate edition that my employer purchased for me at work and the community edition that JetBrain’s offers for free. While the extra features available in the Ultimate edition are nice, I have been finding my experience with the community edition as good or better than my previous experiences with Eclipse and Netbeans.

Lately, I have been experimenting with using the Gradle build tool within IDEA. I have figured a lot of things out about it but I am having trouble getting it to build an executable jar file. I’m sure it is just a matter of configuring something correctly within the jar task but I haven’t figure out how to do it yet.

I have learned a lot about IDEA and Gradle but I am just going to have to keep studying until I figure out how to get things to work the way that I want them to. I’ll write a post when I figure out how it’s done.

UPDATE: I figured it out. You just need to add the following lines to your build.gradle file. This includes all of your dependent jars in your executable jar. By the way, substitute the name of your main class  for  ‘org.me.package.Main’.

task fatJar(type: Jar) {
    manifest {
        attributes 'Main-Class': 'org.me.package.Main'
    }
    baseName = project.name + '-all'
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    with jar
}

Of Gradle, Groovy, and How I’ve Come to Love Build Automation

I finally got my project at work to build using Gradle. Grade is a build tool, something like make or ant except that it is implemented as a Domain Specific Language (DSL) built on top of Groovy. Groovy is a remarkable language in its own right. It is a dynamic language that compiles to Java byte code so it runs on the Java Virtual Machine (JVM). It can freely call code written in Java and Java code can call code written in it. This gives Groovy an enormous head start in terms of the variety of libraries that it can take advantage of right out of the box.

What is so great about Groovy, anyway? Well, it is a lot less verbose than Java for one thing. You rarely need to use semicolons in Groovy. Usually, it knows where the end of a statement is without you having to tell it explicitly with a semicolon. Another thing Groovy is good at is figuring out the types of variables without explicitly being told. This makes it easy to define a variable using the def keyword and letting Groovy figure out the type of the variable by what you assign to it. Groovy is touted as a scripting language and it does serve in that capacity very well but it can also be used to write very succinct and flexible object oriented code, like Java. Another place where Groovy saves typing is with imports. All of the more commonly used library packages are included by default.

Groovy also adds a new syntax for cleanly entering Map constants. This makes creating keyword/value data structures much easier. These are very useful for collecting information such as configuration parameters. There are lots of other neat features that Groovy brings to the table but to get back to Gradle, it is an application, written in Groovy specifically for managing the build process.

Gradle makes the build process a lot more expressive. It is more concise while at the same time being more flexible. It is easily extended both in an ad-hoc fashion by writing code specific to the build at hand as well as in a more general fashion by supporting plug-ins that can be shared among many different projects.

Using Gradle to automate my build process has turned a tedious job into one that is as exciting for me as writing the rest of the code in my application is. If you are developing in Java or Groovy or any other language for that matter, I suggest that you give Gradle a look.