Sonatype has introduced tens of thousands of people to Maven through our free Maven books, our numerous Maven training courses, our consulting services, and our professional support efforts. When you interact with so many working engineers and introduce Maven, you get a broader view of how developers approach tools. It sounds callous to say this, but it is 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 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 who don't need instruction, 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 ensure that everyone understands and agrees on the basic assumptions.
Without exception, every organization I have seen that throws away a group of developers without giving them the support of training or connecting them with the experts has come away with a build with 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 engaging directly with Sonatype is the intangible experience of understanding why a build was crafted in 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 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 use alphanumeric identifiers such as "r06" in place of major versions, and I even had one client argue that project releases should be named after colors on a spectrum instead of version numbers. Feel free to use all 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 on 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 you have a parent project that contains sub-modules all related to a single project. If you haven't taken the time to understand how the Maven Reactor orders the project, you might think 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 life cycle. The life cycle 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 adopt Maven, you should make sure your team understands why they use 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.
Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to ...
Explore All Posts by Tim OBrienTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.