Build tools (Maven and Ant) interview questions and answers

In my view, open ended interview questions on tools help interviewer assess a candidate's experience.A typical question would be to ask, what tools would you require to get your job down?

Q. What Java build tools are you experienced with? Which tool will you choose?A. Ant + Ivy and Maven are the ones have been around for a while now. Gradle is a less matured build tool that takes a hybrid approach of both Ant and Maven, but looks very promising. Buildr is a build system for Java-based applications, including support for Scala, Groovy and a growing number of JVM languages and tools.

Ant is more like a build language offering great flexibility as to how you build. You can write elegant and modular builds with it, but the main problem with this flexibility is that many don't write good build programs. For any non-trivial projects, over time it can lead to duplication of configuration between builds if proper care is not taken. If you need great flexibility in builds or you are working with some legacy code base where you have no control over the convention that Maven expects, then go for Ant. Ant is used for defining and executing the build steps. If you need dependency management to be integrated with Ant, then use Ivy as the dependency manager.

Maven is a build framework. Maven takes the opposite approach to Ant and expects you to completely integrate with the Maven lifecycle. Maven's philosophy is "Ant With Convention Over Configuration". For example conventions like the "Standard Directory Layout" (e.g. src/main/java, src/main/resources, src/test/java, src/test/resources, etc) , build cycles, and phases. The Maven plugin mechanism allows for very powerful build configurations, and the inheritance model allows you to define a small set of parent POMs encapsulating your build configurations for the whole enterprise, and individual projects can inherit those configurations, leaving them lightweight. If you want to do anything that is "not the Maven way" you have to write a plugin or use the Ant integration. Maven also has great tool support with IDEs like eclipse, NetBeans, and IntelliJ. Maven is very handy working with multiple-module projects and in scenarios where your project consists of several teams working on dependent modules. These modules can be automatically versioned and composed in to the application regularly.

Gradle is more of a build language like Ant that incorporates some of the pluses of Maven. Gradle tries to provide a hybrid solution to meet in the middle between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens for greater flexibility. It also allows you to use existing Maven/Ivy repositories.

Gradle looks very promising by providing the best of both worlds, but only time will tell its adoption. There are also other factors to consider when choosing a tool like how comfortable your team is with a particular tool, standards and guidelines already in place from a consistency and governance perspective (especially in larger organizations), etc.

Q. What do you understand by Maven's build life cycle?A. The build life cycle has a number phases like validate, compile, test, package, integration-test, verify, install, and deploy. Each phase can have 0 or more goals (i.e. tasks). These build phases are executed sequentially to complete the default life cycle. Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verified package to the local repository, then deploy the installed package in a specified environment.

If you want to do all the phases, you only need to call the last build phase to be executed, which is deploy: This is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase.

A project specific customization of a build cycle involves binding specific goals to specific phases beyond the default settings in the configuration file (i.e. pom.xml). The code snippet below demonstrates how the maven-check-style plugin can be configured in the pom.xml file to execute the "checkstyle" task during the verify phase to evaluate code quality.

Q. In your experience, what are some of the challenges you faced with maven, and how do you over come them?A.When it works which is 95% of the time it's quite nice, and when it doesn't, it can be a challenge. Some of the challenges can be resolved by keeping some tips in mind.

For example, it might not automatically download a particular artefact from a repository. In this case, you can manually install it to your local repository using the following command.

You have no control over, and limited visibility into, the dependencies specified by your dependencies (i.e. transitive dependencies). Builds will break because different copies of Maven will download different artifacts at different times. Your local build can break again in the future when the dependencies of your dependencies accidentally release new, non-backwards compatible changes without remembering to bump their version number. You can use the following commands and tools to check the dependency tree.

mvn dependency:tree
mvn dependency:analyze

The IDEs do provide very useful graphical tools to display. For example, the diagram below shows the plugin that opens a pom.xml file in eclipse.

This is also very handy to resolve class loading issues due to jar conflicts. Also keep in mind that the dependencies are loaded in the order in which they are declared in the pom.xml. So look at the effective pom with mvn help:effective-pom.

The following flags are handy for debugging any other maven issues:

The -X flag shows debug logging, and tee it to a file which you then search for clues of what happened.

mvn -X install | tee maven_out.txt

To show the logical pom.xml or settings.xml being used

mvn help:effective-pom
mvn help:effective-settings

Note: options like help:active-profiles and help:all-profiles also come in handy.

There are other handy options to resume your build from where maven failed in a multi module project. For example, if your build failed at proj-commons, you can run the build from this module by typing: