Build tools such as Maven and Ivy scores over ANT as they have dependency management support. There are even open source hosted binaries on sites like Maven Central, so that you don’t have to download all the required dependencies yourself, but can just ask the build tool to get it for you. For simple Hello World programs, you might not require any other libraries, but an enterprise project will have lot of dependencies to other libraries. For instance a Spring or hibernate program will have dependencies on their framework jars. Spring Framework page currently provide you options to get the jar dependencies through Maven or Gradle, rather than downloading the jar dependencies yourself. Refer to Spring Note Book under Frameworks for more details.
Gradle offers both an Ivy and Maven dependency and repository compatibility layer. A library is declared as a desired external dependency by a one-line listing in a dependencies block. The current Spring Framework page requires you to add below dependency to your build file to get started with Spring:
This can also be written in a more verbose form (following Maven) as:
compile group: 'org.springframework', name: 'spring-context', version: '4.0.5.RELEASE'
Here group, name and version are Gradle’s properties corresponding to Maven coordinates in the POM file groupId, artifactId and version respectively.
Here the compile phrase is referred to as the configurations and external dependencies are applied to these configuration scopes. There are six configurations (or scopes) for the java plug-in: compile, default, testCompile, testRuntime, archives and runtime. Unlike the fixed scopes of Maven, a Gradle plug-in can introduce new scopes, and all scopes (from all plug-ins specified) are defined with dependencies in the dependencies block.
As we have seen, Gradle allow us to use Maven or Ivy repositories easily. We have also seen, how to tell Gradle to use the Maven Central repository:
Similarly, you can use use jcenter() for Maven JCenter repository and mavenLocal() for Local Maven repository. Gradle uses the same logic as Maven to identify the location of your local Maven cache. If a local repository location is defined in a settings.xml, this location will be used. The settings.xml in USER_HOME/.m2 takes precedence over one in M2_HOME/conf. If no settings.xml is available, Gradle uses the default location USER_HOME/.m2/repository.
You can also specify another (project specific) repository easily, if needed. In older Gradle versions, you could specify another (project specific) repository with an addition of a URL to the mavenRepo configuration element of repositories as:
However this is deprecated in latest Gradle and you might get a warning like:
The RepositoryHandler.mavenRepo() method has been deprecated and is scheduled to be remove d in Gradle 2.0. Please use the maven() method instead.
According to the documentation for the Gradle DSL, maven can accept a closure or an action. So we can replace the above mavenRepo method with a closure as:
Flat directory repository
You can also specify a flat directory where you have put the required jar files to resolve dependencies using the flatDir configuration of the repository:
flatDir name: 'localDiskRepoName', dirs: 'lib1'
If there are more directories, you can use the syntax:
flatDir dirs: ['lib1', 'lib2']
Here lib1 and lib2 directories are in the same level as build.gradle file. You can also specify absolute or relative paths (with proper escaping if necessary):
flatDir dirs: ['D:\\GRADLE\\lib1', '../GRADLE/lib2']
Another thing to note here is that, when you specify flatDir to specify a flat directory, you need to specify all required dependencies, unlike before. So for compiling a basic Spring code, instead of specifying only compile 'org.springframework:spring-context:4.0.5.RELEASE', you need to specify as:
Gradle will add up the name and version part above, and add .jar to it, and search the folder specified as flatDir. E.g. spring-core-4.0.5.RELEASE.jar.
Book: Building and Testing with Gradle by Tim Berglund and Matthew McCullough.