Sonatype has introduced tens of thousands of people to Maven through our free Maven books, our numerous Maven training course, our consulting services, and our professional support efforts. When you interact with so many working engineers and introduce Maven, you come away with a broader view of how developers approach tools. It sounds callous to say this, but it is very true: most working developers don't care; they don't care about "the build", and they just want a system that works. Until people fully understand Maven, many don't appreciate the difference between a comprehensive tool like Maven and a focused, procedural tool like Ant. Many approach Maven as a replacement for another tool and try to force Maven to adhere to a set of assumptions about how a build should work.
In my own experience teaching, introducing, and implementing Maven, I've found that even the brightest engineers among us, the people that don't need instruction, even these people tend to hold on to one or two quirks from a previous build that should either be abandoned completely or refactored into a build that is more compatible with Maven. When you move a project to Maven, or when you introduce Maven to a new set of engineers, it is important to make sure that everyone understands and agrees on the basic assumptions.
Without exception, every organization I have seen that just throws a group of developers Maven without giving them the support of training or connecting them with the experts has come away with a build that has some serious problems. Sonatype's training offering isn't just about learning the syntax of a POM or figuring out how to pass the Compiler plugin more options. While POM syntax and plugin configuration are important things to know, this is the sort of information that can be self-taught. The real value of Maven training and of engaging directly with Sonatype is the intangible experience of understanding why a build was crafted a certain way.
Here are some concrete examples of practices I've noticed in companies that have decided to skip Maven training:
- Non-standard Version Number - The pattern that Maven uses for versions isn't optional, and you shouldn't get creative when it comes to project versioning. The version standard in Maven is simple (major).(minor).(point). Some examples, 1.1.2 or 3.2. I've seen people decide to use alphanumeric identifiers such as "r06" in place of major versions, and I even had one client argue that, instead of version numbers, project releases should be named after colors on a spectrum. Feel free to use all of the extra code names or project specific numbers you want to use, but keep them out of the Maven version number for a project. Creative version numbers complicate Maven tool support and they make your project more difficult for people to approach.
- Putting a SCM Revision into a Version Number - This might be a controversial statement, but I'm going to take sides. SCM Revision numbers have no business being included in the names of JARs or any other build output. If you need to put a revision number into a properties file, use resource filtering, but avoid putting a Subversion revision number your dependency. Doing this almost always adds a nasty runtime dependency on an SCM tool. If you need to link a release version with a SCM revision number, use a Git or Subversion tag, don't expose this information to your end-users.
- Creating an Assembly in a Parent Project - Assume that you have a parent project which contains submodules all to related to a single project. If you haven't taken the time to understand how the Maven Reactor orders project, you might think that the parent project is a logical place to put an assembly. It isn't, Parent projects are always built first in the Reactor. Again this is something we touch upon in our training.
- Running Multiple Goals on the Command Line - I see this pattern emerge in the self-taught organization more than I would have predicted. Someone adopts Maven without reading the book or taking training, and they decide that Maven works best when you can string together a collection of Maven goals on the command line. Instead of "mvn clean install", you end up with "maven compiler:compile jar:jar install:install". In other words, I see people start using Maven all the time without a full appreciation of the lifecycle. The lifecycle is arguably the most important part of Maven yet a large majority of Maven users never fully grasp its significance.
I could go on and on listing more Maven misunderstandings, but the previous examples make my point. If you are adopting Maven, you should make sure that your team understands why they are using Maven, why the tool exists, and what problems should and should not be solved with Maven.
If you are heading up the Maven adoption effort, budget some time for rudimentary training. You can send developers to our focused training classes. Based on what I've seen in the field, a little training can go a long way.
Interested in Maven Training? Find out more about Sonatype's Virtual Maven Training and upcoming class schedules by clicking here.
