Title: Gradle – the Basics and Beyond
Speakers: Ken Kousen
For more blog posts, see the DevNexus 2018 live blogging table of contents
Install
- requires Java 7+
- Gradle 4.2.1+ supports Java 9
- Gradle releases frequently but is very backward compatible
- Just unzip and add to path
- The complete distribute includes the samples. The sample sources are also available online.
General
- Gradle is now much faster than Maven
- gradle.com is the enterprise version which is built on top of open source gradle.org.
- Gradle is mostly implemented in Java. Groovy is for the DSL.
- Uses Ant behind the scenes as well
- Groovy comes with Gradle. Don’t need to install Groovy separately
- gretty is jetty for gradle; also contains tomcat
Docs
- User manual – keep open as reference when writing build files. Also available as a single page PDF
- DSL reference – next place to look
- JavaDoc – useful if writing a plugin
Future
- Kotlin
- Creating a Kotlin DSL for simple build files.
- Kotlin is not replacing Groovy
- Not yet at 1.0.0
- Goal is better IDE integration
- Generator
- Looking at being able to generate projects on web project like Spring Boot has
gradlew
- Recommend using gradlew. Checking in the file guarantees users are on version of gradle that you intended
- Has effect of creating many gradle installs on your machine. Not that big.
Creating a project
- Can generate new project or port basic pom files.
- Use porting as a guide and then hand edit
- Generate new project in current directory (make empty directory by hand first)
- mkdir proj
- cd proj
- gradle init –type java-application (or java-library)
- Files/directories in project
- gradlew/gradlew.bat – wrapper script
- gradle/wrapper – jar and properties
- settings.gradle – lists multi project builds
- gradle.properties – key/value pairs used by build
- In home directory’x .gradle
- wrapper/distx – the binarry/installs.
Daemon
- Improves performance
- Cache a lot of the JVM startup
- For a few hours, same daemon used if using same version of gradle on every project.
- Tip: turn off daemon on CI servers so every build is a clean build
Gradle file
- repositories
- can use jcenter or maven central.
- or can specify a different one for any Maven or Ivy repo; like internal corporate one
- can list multiple repos and searches in order
- dependencies
- ‘group:name:version’ – same concept as Maven GAV. Or can split into three sections. Ken likes the former better; either fine.
- can write compile (‘g:n:v’) to specify fully. Groovy parens are optional except when they are not. The DSL can interpret without parens and easier to read.
- New Java plugin has api/implementation to use as scope instead of compile.
- compile files – lets you add files not in the classpath
- compile fileTree – lets you add a directory not in the classpath
- plugins
- if registered on plugins.gradle.org, can list id and version numbers.
- built in plugins (ex: java) don’t get a version number
Commands
- gradle build -t – rebuilds and then sits idle until you change code. Like a rebuild loop
- gradle build –dry-run – shows what would run (can use -m instead of –dry-run)
- gradle -b… – use different build file name
- gradle –stsatus – shows processes
Build scan
- Starting Gradle 4.3, will prompt you if you haven’t accepted the license agreement and try to use.
- It’s hosted at Gradle so sends some info out.
- Gradle Enterprise does build scans in house
My take
Good structured intro/review. Happy that Ken changed the background to white when we were reading code. He also made the code sufficiently large. I didn’t even need my glasses. Go Ken! The only time I needed my classes was when he showed the manual which uses dark gray on a light gray background for the comments. I knew more of the basics than I realized. But good to have it gel better in my head! And I definitely learned things. Rushed at the end though and that was where most of the new stuff is. Glad I’m a New Yorker and can handle talking fast. Can’t type that fast though so stopped taking notes.