🤑 Join the Treehouse affiliate program and earn 25% commission!

Join our Live Career-Building Workshop: Launch Your Tech-Adjacent Career! ⭐ Register here!

🌟 Dreaming of a bright future? 🎓 Ask about the Treehouse Scholarship program! 🚀

Curious which AI tools Treehouse developers love? ⚙️ Check them out!

🫡 Treehouse for Military offers discounts to Veterans, service members and their families!

Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Adding Dependencies

9:12 with Craig Dennis

Let's add some dependencies to our build script and get them downloaded

Teacher's Notes
Questions?
Video Transcript
Downloads
Workspaces

Note

In the latest versions of Gradle, the configuration keywords have been updated. Instead of using compile and testCompile as shown in the video, you should now use implementation for main dependencies and testImplementation for test dependencies.

dependencies {
    implementation 'org.apache.commons:commons-csv:1.2'
    testImplementation group: 'junit', name: 'junit', version: '4.11'
}

The Gradle menu on the far right is now just an image of the elephant logo instead of the word "Gradle" as seen in the video.

Learn More

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

And now the moment you've all been waiting for, adding dependencies. 0:00

So remember how we talked about how difficult it would be to manage 0:04

all those libraries that the dependency we wanted to use depended on? 0:08

You know the transitive dependencies? 0:11

Well, ready for the good news? 0:14

This transitive dependency management is all done for you through Gradle. 0:16

It even provides a cache of each of its dependencies 0:20

in case they're shared across libraries. 0:24

And they usually do share dependency. 0:26

This means, that it won't go and download a version that it already has, but 0:28

where is it downloading from you ask. 0:33

Good question. 0:35

This is under control by the build script author. 0:36

That's you. 0:39

It's defined in a section called repositories. 0:40

The default one used is called Maven Central. 0:44

Maven Central has been around for a long time and 0:47

just about everything you want to use is published there. 0:49

But like all other pats of Gradlel, you can definitely change this. 0:52

You can actually publish your project up to Maven Central quite easily. 0:56

But that's a different workshop. 0:59

So let's go and manage some dependencies. 1:01

Cool, so here is the repositories section that we just talked about. 1:04

It takes a closure, which is this, and 1:09

it returns a call to a helper function called mavenCentral. 1:12

Which you might have guessed returns the web location of mavenCentral. 1:17

What this means is that anything in the dependency block down here 1:21

will look in our defined repositories for the project. 1:26

Now the defined repositories in our case is just mavenCentral. 1:29

So let's add our dependency. 1:34

So I navigated over to the Apache Commons website, and 1:37

specifically to the Commons CSV project. 1:40

And I scrolled down through here. 1:42

And it says you can pull it from a Maven repository. 1:44

So I'm just gonna go ahead and I'm gonna grab this XML that's sitting here. 1:47

I'm gonna come and pop over, and let's just paste that in here. 1:51

And this is actually what Maven syntax looks like. 1:56

Maven is written in XML. 1:58

So this is what it looks like. 2:00

But those tag names look pretty familiar, right? 2:01

Those are the ones that we used when we were building our gradle project, right? 2:04

We used groupId, artifactId, and version. 2:06

So what we wanna do here is take this and 2:09

put it into the closure that's in the dependency method here. 2:11

So currently there's one here already for the junit testing library. 2:13

Do you see how important testing is? 2:17

It's assumed. 2:19

If you wanna take junit for a test drive, check the teacher's notes for 2:20

more instructions. 2:23

Now, notice how the word test compile is here before the library output. 2:25

Now this is a configuration, and 2:30

by default, the Java plugin has a couple of these, right? 2:32

So, following the configuration here are what in Groove as named parameters. 2:36

They're just parameters to this method here, this test compile method. 2:42

They can go in any order, and 2:46

what happens here is the parameter name has a colon and then the value afterwards. 2:48

In our case the values are all strings. 2:54

So in Groove you don't need to put parentheses around your method call, 2:56

it's kind of assumed, but this looks a little bit more sane, right? 3:00

So this is calling the test compile method and it's passing in these arguments and 3:04

their names, so the order doesn't really matter. 3:08

I notice that there's a comma between them, we're familiar with that. 3:10

Okay so I'm going to ahead and I'm going to get rid of this. 3:13

We don't need it. 3:16

It's assumed. 3:17

Also note that there is no difference between single quotes and double quotes so 3:18

it's best to follow the file format, but you know in Java if you do double quotes, 3:23

it's for strings, single quotes are for charts. 3:26

Doesn't matter in Groove. 3:28

So we could look up in the Java plug-in and find out what the other configurations 3:30

are, but I know that one is compile, and that makes sense, right? 3:34

When the program runs we want this at compile time. 3:37

We wanna have our CSV package at compile time, so let's do that. 3:40

So we'll do compile. 3:43

And we're just gonna follow what's down there below, so 3:48

say group, and then I'm gonna grab this. 3:50

This is the group ID, right? 3:55

Translate, and then I'm gonna do a comma. 3:58

And the next parameter. 4:00

Copy this. 4:03

This is the name here. 4:04

Right. 4:06

Or the artifact ID. 4:07

And then the version. 4:09

And the version is 1.2. 4:16

And now we want to refresh this project. 4:22

So there's a little handy tool window over here in intelliJ, called Gradle, 4:25

let's click that. 4:30

And if you have Gradle modules in your project, which we do, 4:32

you'll see them listed here, right? 4:35

There could be multiple modules in this project, but there's one, 4:37

here's a Gradle project, right? 4:40

So see how it says reviews here? 4:42

So the first button on the toolbar here is used to refresh all projects, okay? 4:45

You can imagine there are multiple. 4:49

Maybe you don't want to do all of them, so you could also, 4:51

you can right click on this and choose refresh external project. 4:54

It uses the same icon there. 4:57

So just ahead and let's click refresh external project. 4:59

So, what that's gonna do is it's gonna pop over here, and 5:04

if we take a look, here's the dependencies that have popped up. 5:08

And over here in external libraries, too, the dependencies popped up in here. 5:12

Look, here's our library. 5:16

Now, some people don't like that you have to do that refresh. 5:17

And I don't blame them. 5:21

We developers have enough to remember these days, right. 5:21

So, do you recall that option of auto import when we first started the project? 5:24

Well, like I said, you can turn this on now. 5:28

So let's go over here, and we'll right click over here on reviews, and 5:30

choose auto-import. 5:33

And you'll see it says auto-import is enabled. 5:35

When you save things, it will automatically refresh. 5:37

So here, I'm gonna cut out the line that we added, right? 5:39

So I'm gonna get rid of that, I'm just gonna cut it. 5:41

And I'm gonna save. 5:45

And what's gonna happen is because it's marked as auto import it's gonna 5:47

rerun the dependency and see it's not there anymore. 5:51

So bam. 5:53

So now if we paste it back and save it. 5:54

It'll come right back. 5:58

Cool, awesome. 5:59

So, the way that we have it now is actually called long form. 6:01

There's a much shorter version of this. 6:05

And you'll actually see this if you see people talking about the Gradle command. 6:07

The Gradle way to download this. 6:12

So, basically it's just a little trick, right. 6:14

So we're gonna get rid of this. 6:16

And we're gonna get rid of. 6:17

All the name parameters, it's gonna be a single string and it's gonna be group ID, 6:22

the name, and then the version all separated by colons, okay? 6:27

So let's go ahead and save that and you'll see that it comes back. 6:34

So, wait a second, look at the external libraries over here. 6:37

Where is this one that's called hamcrest, where is that coming from? 6:41

I don't see it in the dependencies, but it's listed as if it's a Gradle 6:45

dependency, and see it's in the dependencies over here. 6:49

So where is that coming from? 6:51

Oh this must be one of those transitive dependencies I was talking about. 6:53

As you can imagine, 6:58

this might get kind of confusing if you had a bunch of dependencies. 6:58

One way to get a quick peek is to actually use the Gradle command line tool, so 7:01

I'm gonna click the terminal down here and I am going to run 7:05

the Gradle wrapper to get things installed to get Gradle installed on this computer. 7:10

Awesome. 7:16

And I think that's gonna install gradle, it did not, 7:17

so we'll do gradlew and we'll run dependencies. 7:22

So the gradle command takes different words so 7:28

the one that we're gonna use is gradle dependencies. 7:30

And what you'll see here is the list of dependencies that are for the different 7:36

configurations so this configuration here is the test compile configuration. 7:41

Remember the test compile configuration that was defined here and it's saying 7:47

that we'll have commons available but we're also gonna have junit available. 7:50

And junit, see how it indents, it has this hamcrest dependency here. 7:55

Now hamcrest is actually an anagram for matchers. 7:59

And it allows for extremely expressive assertion message in junit. 8:02

And junit depends on it, 8:06

because it exposes some of it's managers in the base libraries. 8:08

Now both libraries are open source and 8:11

they're leaning on each other, sharing is caring. 8:13

You might have noticed that there were three numbers separated by periods. 8:17

This is a type of tracking named semantic versioning or sim ver. 8:20

I figured it might be helpful to get a basic understanding 8:25

of what those different digits commonly represent. 8:28

The first number there is the major version. 8:31

You use this when you make API changes that are not compatible 8:34

with prior releases. 8:37

[SOUND] The next number there is the minor version. 8:38

[SOUND] This is for 8:41

when you add functionality in a backwards compatible manner. 8:41

[SOUND] And the last number there is the Patch, [SOUND] when you add bug fixes. 8:45

[SOUND] You might also see the word [SOUND] snapshot appended to the version. 8:49

And this is used to signify the latest development version, prior to a release. 8:53

It's for code that's under development, but not yet released. 8:58

This semantic versioning is used all over the place, 9:02

especially in the open source world. 9:04

Okay. 9:07

So now that we have our dependencies installed, let's go see how to use them. 9:08

You need to sign up for Treehouse in order to download course files.

Sign up

You need to sign up for Treehouse in order to set up Workspace

Sign up