The build directory for Gradle is one of the most important directories since this is where the output of the build is saved. The build directory is also used to store intermediate build files so they don't have to be re-created when running a new build. This directory contains the output from the interim steps that Gradle follows in a build.
- [Narrator] In this video, we're going to talk about the Gradle Build Directory. We'll talk about what it's used for, we'll see ways in which we can manipulate it directly, we'll talk about the Gradle clean task and how it affects the build directory, and then we'll quickly see how we can change the location of the build directory if we wanted to. Okay, let's look at some code. I'm continuing on with the project from the prior videos, but if you happen to be starting at this point, you can load the starter project from the exercise files.
So the first thing we need to do is identify where the build directory is. And in this case, we can see that it's marked with a yellow folder icon, and it's the third file or directory from the top, and its name is build. If I open that up, I can see various subdirectories. So what's the purpose of the build directory? Well, at a high level, as Gradle goes through building your projects, it executes many different tasks. And each task has a certain set of inputted takes, and a certain set of outputted rights for the next task in the chain.
Rather than get rid of these intermediate input and output files, Gradle saves them. And Gradle saves them in the build directory. And then finally, and this is, in a sense, the essential purpose of the build directory, this is where the final build artifact is produced and saved. So let's take a quick look at these subdirectories. Classes is where any of the compiled Java bytecode goes. So you can see that this subdirectory structure within this refers to the main directory, which is the directory for our production code, and then some subdirectories for the package, the Java package that we're in, and then the sale event class, in this case, we have a single Java file that's being compiled to bytecode.
And this is saved until it changes, and then a new version would be placed there. The libs directory is actually where the output goes. So in this case, the final build artifact for our root project, here, is a JAR file, because it's Java, named java-project-1.0-SNAPSHOT. Now the reason that we've gotten this name is because when we created the project, which you can refer to in a prior video, this is the artifact ID that we gave it. This is certainly something we can change.
Reports, you may nor may not always have a reports directory, but if you're using any utilities that create reports, such as the dependency report, this is where they would be stored and saved. Now in this case, this has generated an entire mini-website with an index.html homepage, various CSS files and images. And then finally, in this particular example, there's a temp directory where it's just keeping temporary files, again, for the Gradle build. And there's really only a manifest file in here that we aren't even using, that's been generated by Gradle automatically.
So that's the purpose of the build directory and where it is. Can we manipulate it directly? Yes. And what I mean by that is, oftentimes you'll want to take things out of it and save them permanently. So for instance, in this reports directory, this is where a dependency report has been generated. And if we wanna maintain that historically, we're going to have to copy that somewhere else. The reason being, that every time we do a build, this directory may be overwritten.
Now let's drill down into our sub-project, json-display. And you'll notice we also have a build directory there, and it has a similar directory structure. If I open up classes, same directory structure, the only difference is that this is a different Java class being compiled, because we're in a different project with different Java classes. Another difference is in the libs directory, which is where our output goes. We're again seeing a JAR file, but it's a different JAR file. And this is an item where new Gradle users can sometimes be confused.
We have multiple build directories, but one per project. How many projects do I have again? Couple of ways to know. I can look at the settings.gradle, and I can see in line one I've got a root project, line two I've got a module sub-project, or I can go into my terminal, I can run the Gradle projects task, in quiet mode so I don't get as much output, and we can see here in the middle of the terminal view, you can see that we have two projects here: the root project, called java-project, and a sub-project, or module, called json-display.
So we have two projects, which means we should have two different build directories in different locations within our project structure. I'll close the terminal. And now let's talk about cleaning the build directory. So, normally Gradle maintains the build directory automatically for you, but occasionally you may decide that you wanna start from scratch and just get rid of everything that's in there. Now there's two ways to do it. Sort of a manual way, where you could literally highlight the directory and delete it. The preferred way in Gradle is to use the Gradle command, clean.
So I will, in my terminal, issue the Gradle clean command. And now, this is a little bit tricky, but what I'd like you to do is sort of watch the view, and you'll notice that the build directory went away. And so that was cleaned automatically for us. And both the build directory at the root level, and the build directory at the module level are now gone.
Now, I'll close the terminal. Another thing you can do is change the location of the build directory. So in my build.gradle file, I could say that I want my build directory to be called myBuild. And now I'll go into terminal, I'll run Gradle build to rebuild the project, and you'll notice that now I have a directory called myBuild. Within the directory it looks exactly the same as before, with the classes and the JAR file, but it's in a different location.
I'll close the terminal by clicking on the X. So, I wanted to show you how you could manipulate the build directory, but I'm going to remove line 19 because generally, that's not something you need to do. You might as well just keep it in the default location unless you have some special reason.
- The purpose of Gradle
- Building a Java project with Gradle
- Adding a dependency to a project
- Creating a library module
- The Gradle project structure
- Creating new Gradle tasks
- Profiling and using the Gradle cloud