Posted on

What you may not know about Gradle

Last week I was at the Gradle Summit in Santa Clara. There were a few things I learnt about Gradle that were worth mentioning since they expanded what I knew Gradle to be, and are just handy to know about

  1. Support for Docker, Vagrant & Cargo

    Gradle has a docker plugin allowing builds to define their own Docker VM’s.  This keeps the development environment the same as production which means less risk when deploying to a new environment given things are more ‘same’.  Vagrant and Cargo support do the same for VirtualBox VMs and Arquillian based JEE containers. Developer checks out build and has the production environment (equivalent) ready to go, all orchestrated by the Gradle build.  Ben Muschko’s Provisioning Virtualized Infrastructure with Gradle talk has more.

  2. Not just for JVM projects anymore

    Gradle has had native support for months now, but it’s been adopted quite quickly and used by companies to build native apps. These companies have little to do with building Groovy or Java apps. Prezi use Gradle to build their JavaScript modules and manage their dependencies, and also build their native mobile apps which incorporate some of those JS modules. It’s enlightening to hear the Prezi devs state they have no JVM knowledge but have taken Gradle in new directions with new modules.

  3. Appreciation of the number of Enterprises dealing with Multi Module builds

    There are some large companies using Gradle. LinkedIn, Google, Netflix, Prezi were present at the conference and had talks. You quickly get appreciation for the number of developers using the tools, and the challenges that all have in incorporating dependencies from other teams. Gradle is in a valuable position to provide tooling to help these organisations work amongst themselves, get their builds building more often and more consistently.

  4. Appreciation that working on multiple modules at once that depend on each other gets tricky

    When working on module A, that depends on module B, Gradle will download its dependencies and recompile A. When working on both modules B and A, do you want to bring in B from the artifact repository or your local one you are currently working on? There is also the chance that the existing version of the dependency will be loaded from the repository instead of using the one that you are currently building. You want to make sure that doesn’t happen. The team at Prezi created Pride, a way to manage multi project builds and specify a fenced off area to indicate the dependencies you care about building yourself versus those in the dependent modules. Their blog, Simpler Management of Modular App Development, goes into more detail about the scenarios you want to care about and their approach to managing this.
    Apart from that I gathered a lot of anecdotal evidence about how large enterprises with multiple teams chose to avoid updating a dependency built by another team for fear of it breaking the build or generating bugs. The problem manifests itself in other bugs that are fixed by that dependency but not implemented by all the products the company releases. There doesnt seem to be a consistent way to manage this but in those larger organisations it does fall onto the build masters responsibility for reporting on the quality of the dependencies used in each project and make sure that they are up to date, and work with the project leads to make sure they get updated accordingly. The challenges of integration within the enterprise came up multiple times to make it worth mentioning here.

  5. The number of attendees a Gradle Summit draws

    I was quite impressed with the number of attendees. I dont have an official number, (could guess a few hundred to a thousand?) but the fact that a conference can be built solely off the existence of a build tool, and have enough sessions to run 3 separate tracks over two days is impressive. Sure Silicon Valley has some of the largest Enterprises using Gradle (and thus developers) using the tool, but people also traveled from other parts of the US, and internationally from Europe, and even Australia to talk Gradle. The result is a conference the size of YOW Melbourne, with an equal breadth of attendees. Gradle is positioning itself as *the* polyglot build tool and so the breadth of topics can only grow from here.

Apart from the experience of presenting, Gradle Summit opened my eyes to a bigger picture of what Gradle is about, far beyond the JVM realm I thought it to live.

Posted on

Presenting at Gradle Summit

In a little over a week and a half, I’ll be presenting this session at Gradle Summit in Santa Clara

Single Page JavaScript Webapps … A Gradle Story

Most people ask me why we chose to use Gradle over a JavaScript build tool.  It was a small circumstance that we took this path. Usually most companies begin their new JS project with Grunt or Gulp.  We tried the same path but it was an unfortunate case at the clients site, their firewall that prevented us from using npm to download npm modules.  We tried to get around this but since we already were using Gradle and it could get around the firewall, we put it through its paces.

In addition, the pace of JS build tool momentum is a little ridiculous. Every time I visit a JS meetup there is a new tool on the scene for managing builds. I’m not sure where to invest my time in learning a tool if the flavour of the month changes so regularly.

Many Java projects have picked up Gradle. There is low configuration required to get a build up, but you are allowed to declare more as required to customise the build for your world.  Since many JVM devs are learning Gradle, and have migrated some of their projects to the new build tool, the barrier for a Java dev to use this tool to build projects on other platforms like JavaScript isn’t too hard.

In this talk we’ll cover getting a simple build up for a simple single page JavaScript web app covering the functions that are available in Gradle for processing JavaScript & CSS resources. We’ll look at some cool features you can get by integrating Jetty so that developers can checkout and run the project in an interactive way. Other tricks and tips covered whilst developing our project will be covered.  Finally, grunt and gulp are the two main contenders in the JS build space. We’ll provide a quick overview of how they work and where you’d want to bring these into your build.

If you are in the area and can come to gradle summit, please come along to watch!