Just like a certain number of speakers, Maven seems to divide developers into two camps:
- Those who like it; and
- Those who loathe it
I try to be objective as much as possible about tools, so let’s explore what Maven is and what it’s good for.
What’s Maven all about?
Maven has two major responsibilities (with a handful of minor ones). These two are:
- Library dependency management – Anyone who’s worked on a java project will know the large number of libraries you might end up with. Part of this is the JDKs inability to solve some of the simplest programming problems (solved with Apache Commons, various logging frameworks, etc). Maven was one of the first successful attempts at fixing this, focusing on applications on what version of libraries they’d like with its dependencies automatically resolved.
- Build lifecycle tool – Maven provides a standard set of fixed build lifecyles with hooks for each step in the lifecycle should you need to extend it.
Why was Maven developed?
To better understand Maven’s design, let’s look at the context developers built it in. Maven sprung forth out of the growing complexities in the Java Apache community. New Apache projects started off almost all the time and there was no “standard” way of building, or creating them. More than that, many Apache projects built on the work of other projects and managing the versioning of libraries started to become an onerous task.
Each Apache project characteristically depended on several other projects although generated its own single distributable (i.e. jar, war, etc).
Maven helped simplify these by assuming a default project structure, a default build lifecycle common to all many Apache projects.
Where is Maven most useful?
If you’re on a project that is similar to a single Apache project (a single distributable with a single set of unit tests) then you’ve hit Maven’s sweet spot.
Where does Maven start to break?
Here are some of the situations I’ve faced where Maven is not the best tool for the job:
- When one team is producing a number of artefacts, you find yourself needing to work around the Maven structure, often with resorting to “Pom Inheritence”. You have to do ugly things like maven installs before hand.
- If you need to do anything more complex than the standard build, then you start to obfuscate the build process. Strange things like different processes running under different profiles (whether or not the build is running on a build server or not) can be very confusing for lots of people.
- Maven adds more complexity to your development environment as you rely on either a public artefact server, or need to set up an internal one. Whilst this seems simple, it is yet another environmental factor that affects how you develop, and its external nature adds variability to projects that often cause false negative build failures.
What other situations would your recommend using Maven or not?
Hurry up and get back to work Pat, We need our Maven expert back!
+1 Loathe
-1 loathe ..just not to forget the countless maven plugin that makes your life simpler otherwise not in ant.. coverage , deployment , database and more…
-1 loathe here too. I don’t particularly love it, but worked on projects composed of more than 20 different modules and the hierarchical structure actually helped to manage all generated artefacts (jar, war, swc, swf etc).
I agree that builds can get nasty depending on how exotic is your project, specially if you decide to play with things like mojos. And managing repositories is also a pain, but maybe nothing compared with the manual processes I’ve seen in the past.
The big question is: what’s a better alternative to maven?
Good for simple projects, to start quickly a spike/investigation on some technology.
Never used in big sized projects, so there’s a chance that it won’t work well there.
Re: on the plugins points by Pratik, copying and pasting some example ant-xml from the third party website is actually as easy and fast as using a maven plugin IMO..
I blame pat…
For simple projects, Maven is great and allows you to clean, compile, test and package easily out the box. Where maven fails is multiple test sets such as unit, integration and functional which requires profiles, and various helper plugins. As soon as you start adding profiles or maven ant tasks, stop and reconsider if you’re better off using a specific ant script for your needs.
For more complex requirements such as smoke, performance tests, reporting, test data set cleansing etc, use Ant which provides pretty much any task you need, various protocols and extensibility in order to achieve what you want.
loathe = loathe
There just isn’t anything better yet for the ‘Where does Maven start to break?’ issues.. ?
+6 loathe… i think thats unanimous in our project group.