Java

Gradle Repositories

Gradle looks for external dependencies in the repositories. A Gradle repository is organized using group, name, and version. Gradle is compatible with different repository formats like Maven and Ivy.

Understanding Dependency Management in Gradle

Repositories are used in Gradle for dependency management. There are two components to Gradle dependencies: dependencies and publications of the project.

When you build a project on Gradle, you will probably need libraries from other developers. Suppose you need the Apache Commons Lang library for special string manipulations. So you need it in your classpath in order for your code to work. And the Apache Commons Lang might need additional libraries that you aren’t aware of. Gradle allows you to tell the particular dependency your project needs and it will go to the specified repository like Maven or Ivy and figure out all the related dependencies and download the files and set it up for you automatically.

Gradle also has the ability to publish your artifacts. You can decide on what publication means for your particular case. You can publish it locally or publish it to a Maven or Ivy repository.

Gradle Repository Example

Suppose, we want to use the StringUtils class from Apache Commons Lang library. Let’s set up a director like this:

helloworld
|-- build.gradle
`-- src
   |-- main
      `-- java
          `-- helloworld
              `-- helloworld.java

In the helloworld.java, you can put the following code:

import org.apache.commons.lang3.StringUtils;

public class helloworld {

  public static void main(String[] args) {

    String greetings = "Hello World!";
    System.out.println(greetings);
    System.out.println(StringUtils.swapCase(greetings));
  }
}

And in the build.gradle file you can put the following:

apply plugin: 'java'

version = '1.0'

repositories {
  mavenCentral()
}

dependencies {
  compile group: 'org.apache.commons', name: 'commons-lang3', version: '3.7'
}

jar {
  from configurations.compile.collect {zipTree it}
}

Let’s discuss what is happening in the above build script. It is telling Gradle to look in the Maven repository for the commons-lang3 version 3.7. It is also telling Gradle to package the dependencies into the jar file. If you remove the from configurations.compile.collect {zipTree it} line, then you will have to include the external dependencies into the classpath when you run the program.

Now from the root folder, you can run the build with the command

$ gradle jar

You should see results like this:

$ gradle jar
Download https://repo.maven.apache.org/maven2/org/apache/commons/commons-lang3/3.7/
commons-lang3-3.7.pom
Download https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/42/
commons-parent-42.pom
Download https://repo.maven.apache.org/maven2/org/apache/commons/commons-lang3/3.7/
commons-lang3-3.7.jar

BUILD SUCCESSFUL in 6s
2 actionable tasks: 1 executed, 1 up-to-date

You can run the build like this:

$ java -cp build/libs/helloworld-1.0.jar  helloworld
Hello World!
hELLO wORLD!

If you hadn’t included the dependencies into your build, then the StringUtils classes wouldn’t have been included in your helloworld-1.0.jar file. And you would have gotten an error like this:

$ java -cp build/libs/helloworld-1.0.jar helloworld
Hello World!
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lang3/
StringUtils at helloworld.main(helloworld.java:11)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.StringUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more

Gradle makes it easy for you to package your dependencies into your package.

Conclusion

Using Gradle repositories and dependencies functionalities can simplify your dependency management process. You don’t have to manually keep track of everything.

Further Study:

Gradle Dependency Management for Java Projects

About the author

Zak H

Zak H

Zak H. lives in Los Angeles. He enjoys the California sunshine and loves working in emerging technologies and writing about Linux and DevOps topics.