Posted on by admin

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.

Leave a Reply