Gradle Interview Questions & Answers

Question 1. What Is Gradle Framework?

Answer :

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.

Question 2. Advantages Of Using Gradle?

Answer :

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.

Question 3. What Is Gradle Wrapper?

Answer :

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.

Question 4. Why Gradle Is Preferred Over Other Build Tools?

Answer :

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.

Question 5. What Is The Gradle Build Script File Name?

Answer :

build.gradle.

Question 6. What Is The Latest Version Of Gradle Available In The Market?

Answer :

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.

Question 7. How Do You Run Gradle Build?

Answer :

Execute Gradle build using gradle command.

Question 8. What Are The Core Components Of Gradle Build Script?

Answer :

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.

Question 9. How Do You Find Gradle Project Dependencies?

Answer :

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

Question 10. The Main Difference Between Maven Build.xml And Build.gradle Script?

Answer :

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

Question 11. How Do I Check Out And Build The Framework?

Answer :

Framework uses a Gradle-based build system. In the instructions below, ./gradlew is invoked from the root of the source tree and serves as a cross-platform, self-contained bootstrap mechanism for the build.

Prerequisites

Git and JDK 8 update 20 or later

Be sure that your JAVA_HOME environment variable points to the jdk1.8.0 folder extracted from the JDK download.

Check out sources

git clone git@github.com:spring-projects/spring-framework.git

Import sources into your IDE

Run ./import-into-eclipse.sh or read import-into-idea.md as appropriate.

Note: Per the prerequisites above, ensure that you have JDK 8 configured properly in your IDE.

Install all spring-* jars into your local Maven cache

./gradlew install

Compile and test; build all jars, distribution zips, and docs

./gradlew build

... and discover more commands with ./gradlew tasks. See also the Gradle build and release FAQ.

Contributing

Pull requests are welcome; see the contributor guidelines for details.

Staying in Touch

Follow @SpringCentral as well as @SpringFramework and its team members on Twitter. In-depth articles can be found at The Spring Blog, and releases are announced via our news feed.

License

The Spring Framework is released under version 2.0 of the Apache License

Question 12. How Long Should A Build Take? When Running `./gradlew Build` For The First Time, It Is Likely That The Gradle Wrapper Script Will Need To Download Gradle For You. Gradle Distributions Run Around 30mb, So This Step Will Be Connection-speed Dependent?

Answer :

You will also need to download all of Spring's compile- and test-time dependencies. This currently runs around 120MB. Keep in mind here that almost all of these dependencies are optional at runtime for applications that use Spring. It's only when building from source that you actually need them all!

Once you've bootstrapped a Gradle distribution and downloaded dependencies, you won't need to do it again; they are cached in your $HOME/.gradle directory. A complete ./gradle clean build at this point will take between 5 and 15 minutes depending on your clock and disk speed. A solid state drive makes a huge difference here!

As is also mentioned below in the 'tips' section, you'll want to break yourself of any habits executing the clean task during normal development iterations. Gradle has excellent incremental build support, meaning that once you've built Javadoc, compiled, run test, etc, Gradle won't execute these tasks again unless the inputs for those tasks (e.g. .java files) have changed. As a general rule, just run ./gradle build or ./gradle test (without clean) to keep things snappy.

Also, consider running with the -a flag to avoid evaluating other subprojects you depend on. For example, if you're iterating on changes in spring-webmvc, cd into the spring-webmvc directory and run ../gradlew -a build to tell gradle to evaluate and build only that subproject.

Question 13. How Do I Configure The Gradle Daemon To Speed Up Builds?

Answer :

The Gradle daemon helps greatly in eliminating startup overhead. This feature may potentially be enabled by default in the future, but in the meantime you need to instruct Gradle to launch the daemon process. This can be achieved by passing the --daemon flag to gradle at the command line, by exporting a GRADLE_OPTS environment variable that includes -Dorg.gradle.daemon=true, or by adding org.gradle.daemon=true to the gradle.properties file in your gradle user home directory (e.g., ~/.gradle/gradle.properties).

If you are building against JDK 9 and using the Gradle daemon, you may encounter an Unrecognized VM option error which halts the build. To avoid this error, you can add org.gradle.jvmargs=-XX:MaxMetaspaceSize=1024m -Xmx1024m to the gradle.properties file in your gradle user home directory. See also GRADLE-3256 for details.

Question 14. Why Are Compile-time Warnings Suppressed? You'll Notice That `build.gradle` Includes The Following Line?

Answer :

[compileJava, compileTestJava]*.options*.compilerArgs = ['-Xlint:none']

This tells Gradle to suppress all warnings during compilation. The reason for this is that the framework currently has many warnings, most of which are related to generics usage -- particularly raw type warnings -- e.g. using Class instead of Class<?>. This is an artifact switching to Java 5 in Spring 3. As with the Javadoc warnings mentioned above, committers are encouraged to fix these warnings whenever possible. Once the bulk of them are eliminated, we can switch to -Xlint:all. In the meantime, it's just creates unnecessary noise in the build output.

Question 15. How Do I Perform A Milestone, Rc, Or Ga Release?

Answer :

The steps are simple, and almost everything is done via the Bamboo and Artifactory UIs.

One-time setup

Configure your CI build plan to use the Artifactory Maven 3 or Artifactory Gradle tasks as appropriate. For "Deployer Username", use "buildmaster" (password on request).

Steps at a glance 

1. Stage the release into the libs-staging-local repository
2. Verify and test the staged artifacts
3. Promote the release to libs-milestone-local (or libs-release-local as appropriate).
4. Merge release branch
5. Announce the release 

Steps in detail

1. Stage the release
   
   The Artifactory Bamboo plugin mentioned above also includes sophisticated Release Management capabilities. This feature allows for publishing releases directly from CI, including creating a release branch and/or tag; incrementing the project version; and publishing to the libs-staging-local, libs-milestone-local or libs-release-local repositories as appropriate.
   
   To access this feature, click on the "Default Job" for the Spring 3.2.x build plan, where you'll see a link to "Artifactory Release Management". Fill out the form fields there and click "Build and Release to Artifactory". Typical values -- in this case for a milestone release.
   
   
2. Verify staged artifacts
   
   When the staging build and release process is complete, you can navigate to the associated build record in Artifactory to verify that all modules were published as expected
   
   
3. Promote the release
   
   When verification is complete, return to the build in Bamboo from which you staged the release and click 'Default Job' and 'Artifactory' at the top, below the Job status bar. Make sure you have the side-bar shown in order to see this.
   
   
4. Merge the release branch
   
   At this point, the release is complete and successful, so the release branch should be merged back into master.
   
   
5. Announce the release!
   
   At this point, announcements may be made and users may consume the released artifacts by adding http://wisdomjobs/libs-milestone-local to their build scripts.

Question 16. What About Publishing Artifacts To Maven Central?

Answer :

This allows for maximum convenience for the majority of Spring users, given that most users have Maven-based builds and Maven resolves artifacts by default from Maven Central.

The preferred way of releasing artifacts to Maven Central is via Sonatype's Nexus server at oss.sonatype.org (OSO). This is explained in detail in Sonatype's OSS usage guide.

The Spring Artifactory repository has been customized with a "nexus-push" plugin that allows for automatic propagation of builds from Artifactory to the Nexus server at OSO for publication into Maven Central.

All Spring projects -- that is, all projects having groupid org.springframework -- can publish to OSO under the shared 'springsource' account. This has already been set up in the nexus-push plugin, so there's no additional setup necessary at OSO, even for new projects.

The Artifactory Bamboo plugin supports use of the nexus-push plugin through it's UI. Step 3 of the the FAQ entry above on publishing releases described the process for promoting a build out of staging. If the build is a GA release, simply choose the 'Push to Nexus' option, and select 'libs-release-local' as the target repository.

Question 17. When Will I Be Able To Play With This?

Answer :

Right now. See the samples README for details on how to get started.

Question 18. What's The Overall Roadmap?

Answer :

a subsequent milestone release of Gradle Script Kotlin will ship with the forthcoming Gradle 3.0. We'll be posting further information about the roadmap to Gradle Script Kotlin 1.0 GA soon.

Question 19. Is Using Groovy For My Build Scripts Deprecated?

Answer :

No. Gradle's Groovy support is not deprecated, and will continue to be supported.

Question 20. Will Existing Plugins Still Work When I Write My Build Logic In Kotlin?

Answer :

Yes, they will continue to work without a problem. Gradle plugins can be developed in any JVM language and they interoperate well with each other as well as with build scripts written in Kotlin or Groovy.

Question 21. Do I Have To Use Intellij Idea When Using Kotlin For Gradle?

Answer :

No. Although JetBrains is the company behind IDEA and also the inventor and driving force behind Kotlin, JetBrains is also committed to providing Kotlin support for Eclipse. The IDE support for writing Gradle build logic in Eclipse will actually improve with Kotlin once we integrate the Eclipse Kotlin support into Buildship, the Gradle plugin for Eclipse.

Question 22. In What Language Should I Develop My Plugins?

Answer :

You can develop your plugins in any JVM language, but as part of this effort, we are working on making Kotlin the language of choice for developing Gradle plugins. Stay tuned!