This course is an introduction to Gradle. Gradle is a Java tool that manages your build environment; it is the new-ish kid on the block of Java build tools and is the tool that Android Studio uses to build Android applications. Gradle lets you compile and test your code, create jars and wars for your applications, generate Javadoc, and much, much more. It is highly and easily extendable. While Gradle itself is written in Java, it provides a DSL that’s written in Groovy in which you write the configuration scripts. This course covers the basics of Gradle, from writing tasks in the DSL, through running Java builds and unit testing, on to ways to extend the build language itself. Gradle does not provide its own dependency management system but instead can use Maven’s or Ivy’s; we see how to configure and use both of those systems. Finally the class looks at the Gradle 'wrapper', a mechanism to ensure your developers always use the correct version of Gradle.
Basic Gradle Tasks Hi, my name is Kevin Jones from Pluralsight, and this is the Basic Gradle Tasks chapter of the Gradle Fundamental class. In this chapter, we'll take a look at how we define and use tasks, and we'll use the task domain specific language, the DSL that Gradle defines, to allow us to create task very easily. When we look at the task lifecycle, we'll see the tasks have different phases and we can do different things during those phases. We'll also take a look at Gradle properties, the things we might want to share across tasks, maybe version information, file names, directories, and so on, that are common to many tasks. Now the Gradle DSL is written in Groovy and Pluralsight has a Groovy Fundamentals class and it might be worth spending time with that class to see some of the basics of what we're going to use here.
Testing Hi, my name is Kevin Jones, and this is the testing module of the Gradle Fundamentals class from Pluralsight. So testing is integral to the Java plugin. You've seen already there's a test composite app and a test app within the plugin. So when we use the Java plugin it defines a source set which tells Gradle where to find the sources for testing. It provides a task that compiles the tests, and a task that runs the test. So we have to do nothing for basic testing. If we just want to do unit testing we add JUnit into our dependencies, we add the sources to the correct place inside the project structure, and we can just run the test quite naturally. And it's also hooked into the build when we do a Gradle build, tests are run as part of the build. So we know that the source set looks for tests in src/test/java, and we know that we can change this. So for the Security Tools project that we have, we looked at the source set, and we did that just to point to test. So you don't have to live in a particular place, but by convention they live in src/test/java. Any outputs from these tests is into the build folder goes into build/classes/test, make sure the output is there. And then we run the tests, Gradle also builds reports for us, and those reports go into build/reports/test. Let me show you an example in a previous module, and we'll see an example again in a moment.
Gradle Wrapper Hi. My name is Kevin Jones, and this is the Gradle wrapper module from the Gradle fundamentals class from Pluralsight. So in this last chapter, we'll take a look at how the Gradle wrapper works and how we can set this thing up, and also how we can use this for the build server, and in particular, we'll take a look at TeamCity and how we can set up a build with TeamCity to use a Gradle wrapper.