SPRINGONE 2GX 2012: THE SPRING, GROOVY, GRAILS, & CLOUD EVENT OF THE YEAR!


Hans Dockter

Founder of Gradle and CEO of Gradleware

Hans Dockter

Hans Dockter is the founder and project lead of the Gradle build system and the CEO of Gradleware, a company that provides training, support and consulting for Gradle and all forms of enterprise software project automation in general.

Hans has 13 years of experience as a software developer, team leader, architect, trainer, and technical mentor. Hans is a thought leader in the field of project automation and has successfully been in charge of numerous large-scale enterprise builds. He is also an advocate of Domain Driven Design, having taught classes and delivered presentations on this topic together with Eric Evans. In the earlier days, Hans was also a committer for the JBoss project and founded the JBoss-IDE.



Presentations

Beauty and the Beast: Software-Design for Builds and Build Systems

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.

Enterprise Gradle

In this talk we will cover many Gradle power features that are particularly helpful for the real heavy lifting often needed in enterprise builds.

We will start this session with the concept and advantages of autowiring the Task Dependency Graph based on the inputs and outputs. We will then talk in detail about the new dependency management features such as the new cache, customizable dynamic revision handling and customizable version conflict resolution. From there we'll explore the new extension mechanism for the Gradle DSL and introduce the Gradle daemon. We will also discuss our take on best practices for dealing with module dependencies in the enterprise and how this can be mapped with Gradle. Finally we will show how you can programatically customize the way the Gradle build model is mapped to the STS Gradle Eclipse plugin. All those features are presented in the context of our roadmap and what further improvement you can expect with future releases.

Patterns for Efficient Build Promotion

We have seen quite a few larger projects for which a naive practice of early integration between the components lead to constant breakages. Thus they were not capable to successfully build a new version of the software stack for days or even weeks. Obviously the problem of that is dramatic as no regular manual testing and capacity testing is taking place. Not only is this a massive waste of testing resources, it also leads to very long and therefore expensive feedback cycles that severely affect your time-to-market of new features. It also a likely source of conflict between the CI team and software development, as with no other means at hand, there is a desire to create stability by not adding new features or doing important refactoring.

We will present patterns on how to integrate as early as possible but at the same time keep the delivery pipeline of new features flowing. Obviously automation can't solve all the problems of software development. But it can for example help to shield against pockets of problematic pieces of software. With a good reporting it can also give valuable insights into potential organizational problems.

Gradle - the Innovation continues

The Gradle development team have not been taking it easy since the release of Gradle 1.0. New features and innovations are constantly being added, rough edges are being smoothed and the platform continues to expand. In this session we’ll explore the most notable additions to Gradle since the release of 1.0 and preview some of the new and exciting features just over the horizon with Gradle founder and Gradleware CEO Hans Dockter and Gradle core developer Luke Daley.

The 1.0 release was the result of many years of engineering and innovation, and its release signals an increased commitment to stability and backwards compatibility for Gradle. But Gradle will continue to evolve with a high velocity to gain new capabilities, features and increased build performance.

We’ll dig into to some of the features incorporated since the 1.0 release, such as:

  • Support for Build Migration
  • Maven import support
  • Parallel task execution
  • Improved Dependency Reporting
  • Improved access to the resolved dependency graph
  • Gradle Android Support
  • Improved test execution feedback on the command line
  • Convenient testing of Gradle upgrades via build comparison
  • Dependency injection for tasks, plugins and extensions
  • More flexible error handling (i.e. continuing on failure)
  • Improvements to the Tooling API (i.e. embedded Gradle)
  • Better scalability for large scale enterprise builds
  • And more.

We’ll also take a sneak peak at some of the upcoming features that will soon be available in Gradle and discuss strategies for keeping up to date with the latest Gradle developments to ensure you are getting the most out of your build tool.