Maven / Gradle interview questions

Gradle is an open source build automation system that builds based on the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration.

Gradle combines both Ant and Maven, taking the best from both of these frameworks; Flexibility from Ant tool and convention over configuration, dependency management and plugins from Maven.

Gradle provides support for multi-project builds.

It allows to use existing Maven/Ivy repositories.

Free and open source.

Scalable nature.

A wrapper is a batch script and it is one of the ways to perform Gradle build. When executed the first time, it automatically downloads Gradle and then initiate the build.

It helps to setup Gradle workspace quickly for first-time users (Zero installation) and also ensure all the developers use the same version of Gradle.

Gradle build script is written using groovy API which has the syntax similar to Java so it is easy to understand.

Gradle supports ant tasks, ivy and Maven repositories for dependency management. It also has a maven Pom.xml converter to Gradle build script.

It is open source.

provides strong support for multi project builds.

supports build cache.

build.gradle.

Gradle build tool latest version is 3.5 as of May 2017. The version on your local Gradle installation can be checked using gradle -v command.

Execute Gradle build using gradle command.

Project and task are the core compoents. Groovy organizes projects as a list of tasks.

To view the list of available projects, use the command gradle projects, for the tasks list the command is gradle tasks.

Use the Gradle command gradle dependencies that lists the dependencies of the selected project. It includes both direct and transitive dependencies.

Maven build.xml is xml document that includes start and end tags. Build.gradle is a Groovy script which has syntax similar to Java.

you may refresh dependencies in your cache using the command line option --refresh-dependencies. Also deleting the cached files under ~/.gradle/caches would get the next Gradle build to download them again.

Every Gradle build is made up of one or more projects. What a project represents depends on what it is that you are doing with Gradle. For example, a project might represent a library JAR or a web application. It might represent a distribution ZIP assembled from the JARs produced by other projects. A project does not necessarily represent a thing to be built. It might represent a thing to be done, such as deploying your application to staging or production environments. Don't worry if this seems a little vague for now. Gradle's build-by-convention support adds a more concrete definition of what a project is.

Each project is made up of one or more tasks. A task represents some atomic piece of work which a build performs. This might be compiling some classes, creating a JAR, generating Javadoc, or publishing some archives to a repository.

The Gradle build file defines the project and its tasks. The below list a simple task to print "Hello world!".

task hello {
    doLast {
        println 'Hello World!'
    }
}

Run Gradle hello on the command line in the directory of the build file to execute hello task. If the Gradle output should be suppressed, use the -q (quiet) parameter.

gradle hello

The Daemon is a long-lived process that helps with the faster build process, by avoiding the cost of JVM startup for every build and also caches information about project structure, files, tasks, and more in memory.

Gradle improves build speed by reusing computations from previous builds and also uses cache information.

The settings.gradle is a Groovy script that defines build related settings and not project related. It is evaluated against a Settings object and with this Settings object, you can add sub projects to your build, modify the parameter from the command line (StartParameter) and access the Gradle object to register lifecycle handlers.

The gradle.properties file is a simple Java Properties file. It's a simple key-value store, that only allows string values.

• build.gradle, script that defines the build configuration,
• gradle.properties,
• and settings.gradle.

To add a dependency to your project, specify a dependency configuration such as compile under the dependencies block of your build.gradle file.

dependencies {
   compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
   testCompile group: 'junit', name: 'junit', version: '4.+'
}

Use gradle projects command.

There are 2 general types of plugins in Gradle, script plugins and binary plugins.

Script plugins are additional build scripts that further configure the build and usually implement a declarative approach to manipulating the build.

Binary plugins are classes that implement the Plugin interface and adopt a programmatic approach to manipulating the build.

One can develop plugins for Gradle in any JVM language such as Java, Scala etc.

The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, allowing you to package executable jar or war, execute Spring Boot applications, and use the dependency management provided by spring-boot-dependencies.

Gradle provides a domain specific language (DSL) for describing builds. This build language is available in Groovy and Kotlin.

It is build.gradle. Kotlin DSL script files use the .gradle.kts file name extension.

A multi-project gradle build will have rootProject and the subprojects, both together is considered as allprojects. The build starts from rootProject however it usually has no code, subproject does. allproject section can have dependencies seen by all projects while subproject dependencies seen only by those sub projects.

Usually subproject only apply Java plugin as it got code.

subprojects {
    apply plugin: 'java'
} 

Open a console (or a Windows command prompt) and run gradle -v to run gradle and display the version as shown in the below picture.

The Spring Boot Gradle Plugin provides Spring Boot support in Gradle. It collects all the jars on the classpath and builds a single, runnable jar, which makes it more convenient to execute and transport your service.

plugins {
	id 'org.springframework.boot' version '2.2.1.RELEASE'
}

buildScript {
    repositories {
        mavenCentral()
    }
}

The repositories in the buildScript block are used to fetch the dependencies of your buildScript dependencies. For example, your plugin dependencies are listed here.

repositories {
    mavenCentral()
}

The repositories on the root level are used to fetch the dependencies that your project depends on. So all the dependencies you need to compile your project.

The api configuration should be used to declare dependencies which are exported by the library API, whereas the implementation configuration should be used to declare dependencies which are internal to the component.

dependencies {
    api 'org.apache.httpcomponents:httpclient:4.5.7'
    implementation 'org.apache.commons:commons-lang3:3.5'
}

Dependencies appearing in the "api" configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the "implementation" configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath.

Every Gradle project provides the task dependencyInsight to render the so-called dependency insight report from the command line. Given a dependency in the dependency graph, you can identify the selection reason and track down the origin of the dependency selection. You can think of the dependency insight report as the inverse representation of the dependency report for a given dependency.

The dependency insight report answers the below queries.

• Why is this dependency in the dependency graph?
• Exactly which dependencies are pulling this dependency into the graph?
• What is the actual version (i.e. *selected* version) of the dependency that will be used? Is it the same as what was *requested*?
• Why is the *selected* version of a dependency different to the *requested*

gradle -q dependencyInsight --dependency commons-codec --configuration scm

Initialization: Gradle supports single and multi-project builds. During the initialization phase, Gradle determines which projects are going to take part in the build, and creates a Project instance for each of these projects.

Configuration: During this phase the project objects are configured. The build scripts of all projects which are part of the build are executed.

Execution: Gradle determines the subset of the tasks, created and configured during the configuration phase, to be executed. The subset is determined by the task name arguments passed to the gradle command and the current directory. Gradle then executes each of the selected tasks.