Gradle allows you to describe your build using a rich, easily extendable build language based on Groovy. It provides compelling solutions for many of the big pain points that exist with current build systems. This session will be mostly driven by live demos. You will see how easy and elegant Gradle enables you to solve a broad range of requirements - over the full life cycle of typical and atypical Java builds.
Gradle pushes declarative builds to a new level. It allows users to provide there own declarative elements and to customize the behavior of the build-in ones. Thus enabling concise, expressive and maintainable builds. All this is build on a rich, flexible imperative layer of tasks.
With its Deep API Gradle allows you to hook in and customize every aspect of the build, be it configuration or execution behavior.
Gradle comes with many optimization strategies for building fast and yet reliable. It has a powerful support for multi-project builds and transitive dependency management. It allows to integrate with your existing Ant/Maven builds and your Ivy/Maven/Custom repositories.
The demos will span dependency management, test result analysis, code sharing, parallel testing, incremental builds, integrating with Ant/Maven and more.
For our production code we apply a wealth of design values and principles. Currently this is rarely done for our builds. Yet the project automation domain, specially in the enterprise, is often at least as complex as the business domain.
The design of your build is heavily influenced and possibly constrained by the design of the build system you are using. The main focus of this talk is to evaluate those design forces of the build systems. Mostly with the help of two books: Refactoring by Martin Fowler and Domain Driven Design by Eric Evans.
The build systems under review are dramatically different and thus the design of the corresponding builds. We will talk about best practices for build design and how different build systems might support that or stand in the way, thus preventing expressive, maintainable and easy to use builds. Those differences should be a major factor when you are choosing a build system appropriate to your needs.
The speaker is the founder of Gradle. So there might be some bias :). But the design principles referred to are core principles fully accepted by the Java community. The way they are violated is astonishingly obvious once pointed out. Production code would not get away with this and neither should builds.
The project automation requirements of complex enterprise builds are the true stress test for any build system. Gradle has a special focus on enterprise builds. In this session we will talk about and demo on: Multi-project builds, incremental builds, parallel testing, dependency management and concluding with organizing build logic, custom plugins and custom tasks.
The project automation requirements of complex enterprise builds are the true stress test for any build system. Gradle has a special focus on enterprise builds. In this session we will talk about and demo on: Multi-project builds, incremental builds, parallel testing, dependency management and concluding with organizing build logic, custom plugins and custom tasks.