Gradle uses a default structure for organizing the files and directories in a project. Explore the default structure and be able to identify the Gradle files by name and location. You'll be able to debug Gradle problems and quickly locate files. Learn how to tell Gradle how to handle the build when directory locations are different than the defaults.
- [Narrator] In this video we're going to talk about the Gradle Project Structure. So we'll do a review of each directory and file. And this may sound a little bit boring, but we'll go through it pretty quickly. And I think you'll find that it'll really help you in understanding the file structure. We'll identify the purpose of each file and directory so you'll know what each one does and we'll look into most of them. And then finally, we'll differentiate the file and directory types. So in other words, what I want to be able to have you understand is what are the IntelliJ files and directories, what are the Java files and directories and what are the ones that are specifically for Gradle.
And this will be helpful, obviously in understanding the directory structures a whole. But also if you're using Gradle in a different environment or in a different IDE, some things will be the same because they're about Java and Gradle where some things will be different. So for instance, if you're using Eclipse, some of your clips meta data files will obviously not be the same as the IntelliJ ones. Okay, let's look at some code. So I'm continuing on with the Java project that I used in prior videos. But if you happen to starting at this video, you can load the starter project from the exercise files.
So let me close these two directories just so you can sort of see from the beginning what's going on. And let me cover the Java project first. Let's drill into that by clicking on the caret. So we have to decide what order we're gonna look at these and rather just start from the top to the bottom, there's a sort of logical flow that we can do. So we'll look at the Gradle files first. So I'm gonna start with the file at the bottom called settings.gradle. And in a sense you can say that this is the most important gradle file because it describes what the gradle projects are. You can see that little icon on the left, which is the green bullseye and that's the icon for gradles. So you can identify file types by the decorators on them.
So settings.gradle has two lines and line 1 we're defining what the root project is. It's called "java-project." And you'll notice the name corresponds to the name of the project and to it's location. On line 2, we have an include for "json-display." That tells us what additional modules we have in the project. And "json-display" corresponds to a directory at the root level of the project. So we can see in our project view that we also have a "json-display" directory.
More on that in a bit. Let's look at the next file now. That's the "build.gradle" file. And the decorator is the same green bullseye icon. So that tells us it's a gradle file. And having .gradle in the file name certainly gives us the hint also. I'll open this up and we have seen this file before, we've been working with it in prior videos. Let's do a quick review again for those who might be coming into this video directly. Lines 1 and 2 describe the artifact information for the build artifact that we're producing for the root project for "java-project." Line 4 tells us that this project is a Java project because we're applying the Java plugin from gradle.
Line 6 tells us that the code we're writing in the project, is compatible with version 1.8 of Java, the language itself. Lines 8, 9, and 10 describe the repositories that Gradle is going to be using to get external dependencies from. And we've defined one in line 9, "mavenCentral." And remember Gradle dependencies are compatible with Maven dependencies. So we can actually use any Maven repository.
Line 12, 13, 14, and 15 describe the external dependencies. So in line 13, we're using the "junit" library to do unit testing. We're not actually using that in this video, but it's generated by default by IntelliJ. And then line 14 our root project is using another module within the same overall project structure called, "json-display." So that's the second project in this group of projects.
Line 17, we're applying an additional plugin called, "project-report." And this is one of the built in plugins that are available in Gradle. But we still have to turn it on, in a fact, by issuing the applied plugin command. The next thing we'll look at is the directories. So that's the source directory. And just as convention, rather than spelling out source, we use the abbreviation. This is something that Maven did, so Gradle is adopting it.
But it's where our Java source code goes and any other resources this project would have. I'll open up source and I see two sub directories, main and test. Main is where our production code goes. So that's what we're actually going to be deploying. Test is where our code is for writing unit tests that tests the code in main. That tests the production code. So we've got that separation between those. And that's a Java convention not a Gradle convention to separate out your production code from your test code.
So let's open up "main" and see what that looks like. Now underneath "main," at least in the Maven world we could actually have multiple languages in here. In our project we only have a single language and that's Java. So all our code will be under the "Java" directory. And then we have a Java package called, "info.garagesales.domain." And then we have some Java source code called, "SaleEvent." And if I look at that, that's just regular Java code. Now in our case we have nothing. But in production projects you may have various xml files and things in there.
And in "test" you'll notice that we have a directory structure that corresponds to the directory structure in "main." So this will be a little bit of review. We have a Java directory where we can put our Java unit tests. Now we don't have any. And we also have a resource directory where we could put any xml resources specifically for testing. Again, we don't have any. But I'm going to talk briefly about a set of files, a "gradle" directory which contains a "wrapper" sub directory and a couple of files, a "wrapper jar" and a "wrapper properties," and then a "gradlew" file and a "gradlew.bat" file.
At a high level let me explain these and we'll have a other video later that goes into more detail. These set of files are referred to as the gradle wrapper. What the wrapper files do is provide us a command called, gradelw that we can issue at the command line. And what that does, is it provides a light weight wrapper around Gradle that makes sure we have the right version of Gradle. And then passes whatever command we're issuing on to Gradle itself. The reason that Gradle provides this is, let's say I have Gradle 3.4 on my machine where I'm doing development.
And another developer has Gradle 3.5. If we're both working on the same Java project, we don't actually want to build them with different versions of Gradle. We wanna use the same version. And the Gradle wrapper will make sure that happens. Also if you happen to be in a continuous integration environment and your build server uses a different version of Gradle than you are locally in development, the Gradle wrapper will again assure that both environments are using the same version of Gradle so that the build artifact is exactly the same.
A little bit more detail on the Gradle wrapper later. Let's take a look at the build directory next. The build directory is the output of Gradle. So if I open that up I can see various directories where as Gradle is running and as we have issued various commands in Gradle, the temporary output has been saved to these files. So one of the most obvious examples is underneath "classes," we can see a directory structure. "Main" and then the package directory structure. "info," "garagesalesapp," "domain." And then the "SaleEvent class" itself, which is the byte code for the compiled "saleevent.java file.
Then we've got a couple of other directories that begin with a dot. Now dot files, .gradle and .idea. In IntelliJ, dot files are meta data. If we open that up we can see that there's some temporary output and there's some xml files. I'm not gonna show you that. Not because I don't want to or that it's secret, but it's just something as a developer you don't really need to deal with within IntelliJ. These are meta data files that are maintained by IntelliJ itself and you don't wanna go into them and mess with them in any way.
You could break your project if you do that. So just leave them alone and let IntelliJ manage those. Next I wanted to go into the "json-display" sub module. And let's remind ourselves why this is a sub module. If I open up "settings.gradle," we can see on line 2 that this root project includes a reference to an additional module that happens to be in the same project structure, called "json-display." And you'll see that we've got a folder called "json-display." And let me click off that for a moment just to emphasize something.
You'll notice that it's in bold and that's just a convention that Gradle uses within IntelliJ to mark the Gradle module projects. Sometimes these modules are also referred to as sub projects. And you could sort of understand why. It's because it's underneath another project. So like a sub directory is under a directory, a sub project is under another project. So you may hear the term module or sometimes sub project. So when I open this up you can see that we've got three items in here.
We've got a "build.gradle" file, that's the most important one. And when I open it up, it looks very similar to the "build.gradle" at the root level. And that's because it's purpose is the same. In other words, it describes a separate project. So we can think of the root project and the module sub project each as two independent Java projects. So in line 1 and 2, it has to describe its own artifact ID. In line 4, since this module is Java, it has to state that by applying the Java plugin.
Line 6, we're also using jdk 1.8 here. Line 8, 9, and 10 we have to separately specify which repository we wanna use. In this case "MavenCentral." And then on lines 12, 13, 14, and 15, we're specifying the dependencies for the sub project itself for "json-display." Now in this case on line 14, you'll notice that it's just this module which uses the "gson" library, not the root project.
One other point I'd like to make about the "build.gradle" file is now we have two. We have one in the module and one at the root project level. And that always confuses new Gradle developers. They can't understand why there's more than one "build.gradle" file. But the reason is because they're for different projects within the overall project structure. Let's now look at the source directory, and I won't spend too much time on this since it's exactly the same structure and purpose as it is for the root project.
So we have a "main" and a "test" directory and a "java" and "resources" directory where any of our code in "resources" are. Then finally we have a "build" directory, and again the purpose is the same as the "build" directory at the root project level. This is where the artifacts are saved just for this module. So if I drill down into "build," "classes," "main." That's my production code. "info," "garagesalesapp," "domain." That's my package. I'll see "JasonDisplay" by code there because in my source directory for this module, that's the code I have.
Sometimes things can be a little bit confusing, especially if you have a lot of modules because you'll see this parallel directory structure in each of the modules. And so if you're looking for a file like "build.gradle," you need to make sure you're either at the root project level or in the right module.
- 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