For various reasons, I was relatively late to the Maven party, but nowadays I could not imagine developing enterprise Java projects without it. And when I am working with other languages and toolsets, I’ll always look to adopt similar tools to automate my workflows.
If you aren’t familiar, Maven is a tool for managing the lifecycle of a Java project – think compilation, testing, packaging, release, deployment, dependency management etc. All of the stuff that goes around the edge of simply writing code.
This can be incredibly useful time saver, helping to automate builds and making them much more repeatable. However, I am also struck by the way the Maven workflow enforces good habits:
- Automation – The number one win with Maven is the automation it gives you. Without writing a line of code or configuration, you’ll be able to do things such as compile, build project artifacts, run tests etc by running a single command. This will repeatable on your machine, your colleagues machines, and on your build and CI servers.
- Convention Over Configuration – Ant will have gotten you some of this way
- Testing – Maven has a specific phase explicitly for running tests. If you don’t have unit tests, Maven will make you feel guilty each time you see that phase whizz by. If you do have them, they better be up to scratch because by default, it will fail the build if your tests fail. Maven really drills home the fact that testing and verification is part of what we are doing.
- Separate Integration Testing – Maven specifically seperates out the integration testing phase of the lifecycle, and gives you the tools to perform good integration testing – e.g. by bringing up and tearing down environments cleanly.
- Small, loosely coupled Components – Maven encourages you to produce small defined components which are bundled into separate artefacts. These are then reusable.
- Consistency – Maven encourages consistency and convention over configuration. This is great when moving between companies and projects, but also encourages consistency within the project team. It reduces the special cases that people need to know about how things are deployed.
- Documentation – Maven incorporates a site feature which encourages documentation. As we know, developers don’t like writing documentation but the site can give us information on the code base, and it can bring in reports such as code coverage.
- Release Management – It will give some structure to your releases. Artifacts are versioned. The snapshot system helps you to. You can define dependencies.
- Code Quality Plugins – It’s really simple to integrate Maven with code quality tools such as coverage and static analysis tools, and possibly route these into your site. Teams who use
Now Maven has some critics and I don’t want to be a tool zealot, but I’m frankly baffled that Maven cannot deliver value to the average Java team who are using Ant or are working in an even more ad-hoc style.