Build tools (Maven and Ant) interview questions and answers

Related links:

• Maven - setting up profiles and tokenizing properties file
• Java Tutorial: Setting up Java, Maven, and eclipse
• Maven interview questions and answers - inheritance versus aggregatio

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 features do you expect in a build tool? A. Compile java code and build jar, war, and ear files for deployment and release. Versioning and dependency management of relevant artifacts and modules. Execute tests and report test results. Run code quality check tools like Sonar, Checkstyle, Findbugs, etc. Environment property substitution Generation of files (e.g. Java source code from WSDL, AspectJ, XSL transformation, etc) Support for cross-platform (UNIX, Windows, etc) and IDEs (e.g eclipse, NetBeans, IntelliJ, etc) Proper documentation and support.  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.

<plugin>
   <groupid>org.apache.maven.plugins</groupid>
   <artifactid>maven-checkstyle-plugin</artifactid> 
   <version>2.2</version>
   <configuration>
      <failonviolation>true</failonviolation>
      <failsonerror>true</failsonerror>
      <consoleoutput>true</consoleoutput>
      <cachefile>true</cachefile>
      <configlocation>${project.parent.basedir}/checkstyle.xml</configlocation>
      <suppressionslocation>${project.parent.basedir}/checkstyle-suppressions.xml</suppressionslocation>
    </configuration>
    <executions>
       <execution>
           <phase>verify</phase>
           <goals>
              <goal>checkstyle</goal>
           </goals>
        </execution>
     </executions>
</plugin>

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.

mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta -Dpackaging=jar -Dversion=1.0.1B -Dfile=c:\Temp\my-commonservices-1.5.5-SNAPSHOT-tests.jar -DgeneratePom=true 

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.

To skip tests to resolve any other issues

mvn install -DskipTests             //this will skip running tests, but still compile it. 
mvn install -Dmaven.test.skip=true  //this will skip compilation and execution of tests
mvn install -Dtest=FooTest          //runs only FooTest
mvn -Dmaven.surefire.debug test     //to debug your tests 

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:


mvn -rf proj-commons clean install   //Resume from proj-commons
mvn -pl proj-commons, proj-service clean install  //build only 2 modules
mvn -nsu clean install            //Don't update the snapshots

To debug maven plugins via your IDE like eclipse,set the MAVEN_OPTS environmental variable as shown below

MAVEN_OPTS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000";
export MAVEN_OPTS

rf --> resume from,  pl --> project list, nsu --> no snapshot update, am --> also make (If project list is specified, also build projects required by the list), amd --> also make dependents (If project list is specified, also build projects that depend on projects on the list)

Now, use your IDEs remote debugging option by connecting to port 8000. In eclipse, you do this via Run --> open debug dialog and then select "Remote Java application".


You may also find  useful:

• Maven - setting up profiles and tokenizing properties file
• Java Tutorial: Setting up Java, Maven, and eclipse
• Maven interview questions and answers - inheritance versus aggregation