I'm not going to go into the whole Maven debate, but suffice it to say that I'm a strong proponent of everything best practice, and, to me, Maven is an embodiment of best practice. By this I mean that Maven is built around a specific best practice build methodology. Note, I said a specific best practice build methodology. In the real world, there are more than a handful of build methodologies that could qualify for the best practice accolade, but Maven assumes a single one of them. This does not mean that the others are not good, it just means that if you use Maven, you going to need to buy-in to the conventions it assumes . . . or suffer. This is true for any Convention Over Configuration ( CoC ) tool, and Maven is pretty darn CoC.
Maven, like all design patterns, is a reuseable solution to the process of building software
I think the occasionally discussed notion of Maven as a design pattern for builds is a powerful metaphor. It's useful because it emphasises that Maven, like all design patterns, is a reuseable solution to the process of building software. It's a best practice solution that has been refined by a community of smart people over years of heavy use. The most obvious benefits of leveraging a design pattern for building software are the same as those for writing software. Namely:
- You get a bunch of functionality with out having to write it yourself
- An engineer that understands the pattern as applied to one project, can instantly understand the pattern as applied to another project.
Nominally, the first bullet is about productivity and and the second is about simplicity. Obviously, everybody wants to be more productive, i.e. accomplishing more with less lines of code. But, I actually think the second point -- simplicity -- is far more important. In my opinion, the entire field of engineering boils down, most elegantly, to the concept of "managing complexity". By complexity, I refer directly to that headache you get when bombarded with piles of spaghetti code. Design patterns help eliminate this intellectual discord by sealing off a big chunk of complexity in a higher level notation. In case you've forgotten, this is what frees our minds up for the bigger and cooler tasks that inevitably reside on the next level.
It is this point of view that makes me rank learning a new project's ad hoc build to be one of the most annoying aspects of my profession. Even if an ant or make build is very cleanly implemented, follows a localized best practice, and automates a broad scope of the software lifecycle, it still punishes new developers with a mountain of raw data, i.e. lines of scriptcode. Note, it's only the ad hoc-ness that is a problem here. This is certainly not a knock on these tools. ant in particular is very good at automating your tasks and providing a reusable set of build widgets. But it does nothing to provide a reusable solution to the entire process of building software, and, accordingly, it does nothing to ease a new developers on their road to comprehending the build.
it's the conventions that matter most with a CoC tool like Maven
So, as I see it, it's the conventions that matter most with a CoC tool like Maven. You have to know and follow the assumed conventions in order to be successful with Maven. Projects that don't follow the conventions quickly run afoul of Maven. First, they struggle to implement their own build process with a tool that assumes a build process of it's own. It's easy to fall into being upset that you can't easily do what you've been doing, but the preceding paragraphs are meant to suggest that it's actually you who needs to change, at least if you plan to continue on with Maven. When you choose Maven, you need to accept the conventions. I you can't, I suggest you stick with Ant, which is flexible enough to meet you on your terms. Just remember that you are losing the ability to leverage the design pattern aspect of Maven to manage the complexity of your build. And if you think your build doesn't have complexity issues, ask your self these questions:
- Can every engineer on our team easily build all the components of our software system?
- Do our engineers have the confidence to modify build scripts without angst?
- Do our engineers flee the room when someone is needed to address a build problem?
So, if you're with me so far, you'd probably agree that following the conventions assumed by Maven is a critical prerequisite for entering Maven nirvana. And this is what leads me to the conclude that the Maven docs suck. They are not only inadequate, but perhaps detrimental; they mostly document the configuration while utterly failing on the critical topic of conventions. The emphasis on configuration, which I assume is largely by accident, leads newbies into thinking it's okay, and perhaps even normal, to configure Maven.
Read the rest of the article at the following URL: