Questions to Determine Maven Knowledge

Question

I requested Maven training at work, and the bosses want to hire someone who knows Maven to come work with us as a consultant so that we'll learn Maven from a real-world perspective instead of a training perspective.

I've been tasked with coming up with questions of various difficulty to ask potential hires in order to ascertain their Maven ability. The problem is that I don't fully understand Maven yet (hence the training request).

What questions would you ask someone to determine their Maven ability, and what level of knowledge would someone have to have of Maven to answer them?

Answer 1

Here are the questions I would ask:

• How would you enforce the use of JDK6 for a group of projects?
• How would you enforce the use of a particular version of a plugins?
• What are some of the reasons why you would use an assembly to build a jar rather than the jar plugin?
• Describe the process of releasing a Java EE project made up of an EJB, a WAR file and two utility jars.
• How many repositories should an internal company repository server have and why?
• How would you structure a POM project made up of N child projects so they it can easily be used in Eclipse?

All of these questions have at least two answers. I would be looking for someone who can provide at least two answers and point out the pros and cons of each approach. Ideally, this person should be tweaking the set up to be less disruptive to the way your environment already works.

Answer 2

I would ask:

• Describe what is the practice of SCM?
• Describe your ideal Maven infrastructure (server, repositories, CI, plug-ins, conventions, etc.)?

Both are very open questions, but they should give your a feeling of his skills and what you can learn from him and what he could bring to your company.

EDIT

Maven is just one piece in the overall software configuration management (SCM) strategy. A good consultant should know the details of maven in and out but also know how it fit in the big picture. Just like you expect a Java EE consultant to be expert in a Java but to know what it means to deliver enterprise application to a customer.

In the company I worked, we had a guy responsible of the SCM who had been a Maven contributor. And his view was way broader than "just" maven. He was in charge to have a productive build, configuration and release process. Two examples:

• We were hard-coding the release number in java code to be able to display it into the "about" dialog of our desktop applications. Most of the time we forgot to change it after the release resulting in a mismatch between the actual release number and the about dialog -- big problem for integrators on-site. This was a bad practice. He then set up something so that the release number in Maven would be correct in the manifest file and educated us to read the manifest file from Java to ensure both match.

• When you would release a module, he wrote a script to not only build the application, but also close the corresponding version in the ticket system (JIRA) and push the release notes in the wiki.

All that to say that knowing how to "mavenize" a project is important, but more important, the guy must understand how you currently work, what is in place and help you set up something reasonable to improve your productivity.

Answer 3

A lot of good questions here, especially the ones proposed by Pascal Thivent. However, I would ask another question:

Q: What is the difference between the aggregation and inheritence in Maven?
A: You can have a short explanation here.

Answer 4

If you have the luxury, I suggest having the consultant come onsite for a day, give him/her an existing java project that you're working on and have him/her "mavenize" it for you. The next day, sit with him/her and have them explain how to compile, and build a jar (or war).

Or maybe have them come to the interview with a maven project to demonstrate. The should be able to compile, and build a jar/war at the very least, imo. If they can run unit tests, deploy to tomcat, integrate with any of the various frameworks like gwt, hibernate, spring, etc, then even better.

Answer 5

In my opinion, a "Maven consultant" should:

• Have a good understanding of how Maven differs from other build tools like Ant (Maven provides a "lingua franca" for project management).
• Have a good understanding of Maven principles: Conventions over Configuration, the default layout, the naming conventions, the philosophy of the tool (one primary output per project).
• Have a good understanding of how Maven works: from where the conventions are coming from (the super POM), the lifecycles (main, clean, site), the phases, how plugins are bound to phases, the influence of packaging, etc
• Know what profiles are and how they can be used to deal with different environments, how to trigger them.
• Know how to use plugins, how to configure them, how to plug them in a maven build.
• Know how repositories work, the difference between local and remote repositories, what SNAPSHOT dependencies are.
• Know how dependencies are resolved, what transitive dependencies are, how to control them, what dependencies scope are, how to use dependencyManagement.
• Know how to implement code health checks, the essential plugins (Checkstyle, PMD and Findbugs plugins), how to implement various kind of tests (unit, integration, functional), how to measure coverage, when to fail the build, when to report.
• Know how to setup maven in a corporate environment (using a shared repository, setting up CI, a company POM).
• Know how to handle advanced packaging scenarii (with the assembly plugin)
• Know how to handle deployment, the various protocols, the deploy plugin, the release plugin, the SNAPSHOT resolution.
• Know how to setup a Maven build for a Java EE project, how to setup a multi-modules build, what modules are required, how to test in the development environment, how to handle the production environment.

Someone with these skills should put you on the right path (and has very likely a decent experience of Maven).

Answer 6

I would suggest that you think about what you wanna do with Maven, or why you wanna introduce it into your projects. Maybe ask your boss for his reasons/goals in introducing Maven.

After you have named your main goals why to introduce Maven. Ask potential consultants how they would use Maven to achieve those goals.

Examples 1
Goal: Improve overall code quality in project.

Question: How may we use Maven to improve our overall code quality in projects.

Possible answer: Maven has several plug-ins to force/meassure code quality in projects, we could integrate those into our buildscripts in almost no time. (e.g. checkstlye, pmd, cobertura, xradar...)

Examples 2
Goal: Creating automated deployment scripts for several destination environments.

Question: How may we use Maven to automatically deploy artifacts to several destination environments.

Possible answer: We could use Maven plug-ins for deployment (e.g. Cargo) and use maven's profiles to handle several configurations.

a.s.o.