One of the features of Gradle that I like the most is its ability to interoperate with other popular build tools such as ANT and MAVEN. We have already seen using Gradle with ANT and here we will see using Gradle with MAVEN. We are not going to discuss the advantages of one over the other, but only how to use both of them together. One of the best things about Maven is that it adds more conventions than in Maven so that you can create build script files with much lesser code than in Maven. See the first java program with Gradle example build.gradle file to see how small it was, and still it did many things on its own. This would have surely required more lines of code in a Maven POM file. If you are not familiar at all with Maven, I would suggest you go through some beginner tutorial for Maven to know the basics of Maven at least.
Gradle offers a bridge to Maven and Ivy artifact repositories in the form of a dependency management definition graph, without demanding remote repositories, thus providing connectivity to open source hosted binaries on sites like Maven Central. You can say Gradle to use the Maven Central repository to resolve its dependencies by adding below in the Gradle build file:
This repositories block indicates that the build should resolve its dependencies from the Maven Central repository. Gradle follows many conventions and facilities established by the Maven build tool, including the option of using Maven Central as a source of library dependencies. Gradle also allows the dependency binaries to be stored alongside the source in version control. Gradle users can establish custom dependency scopes if needed. Gradle replaces the strict Maven lifecycle with task defaults set via plug-ins (e.g. java plugin). Common development tasks such as clean, build, test, and JAR the project’s code are included via the simple inclusion of the java plug-in. Even with convenient defaults, Gradle allows to extend the plug-in-supplied task sequence with additional steps if needed.
Maven coordinates (e.g. groupId, artifactId, version etc.) are called as properties in Gradle and most of them they have defaults too. For instance Maven groupId corresponds to Gradle group property with default value as blank and Maven artifactId corresponds to Gradle property name or archivesBaseName, with default value as the project’s directory name. A Gradle build with an explicit version declaration may look as:
apply plugin: 'java'
version = '0.0.1’
You can list out the entire Gradle properties available in command line using the properties flag:
Many of these properties have sensible defaults assigned so that you don’t have to change them in most cases.
We will see dependency management using maven repositories in detail next.
Book: Building and Testing with Gradle by Tim Berglund and Matthew McCullough.