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?
