Maven in 5 minutes

Despite having been a professional Java programmer for some time, I’ve never had to use Maven until now, and to be honest I’ve avoided it. Just recently however I’ve found myself need to use it to build a pre-existing project, and so I’ve had to had to get acquainted with it to a small extent.

So what is Maven, exactly?

For some reason people who write the web pages and other documentation for build systems seem to have trouble articulating a meaningful description of what their project is, what it does and does not do, and what sets it apart from other projects. The official Maven website is no exception: the “what is Maven?” page manages to explain everything except what Maven actually is. So here’s my attempt to explain Maven, or at least my understanding of it, succintly.

  • Maven is a build tool, much like Ant. And like Ant, Maven builds are configured using an XML file. Whereas for Ant it is build.xml, for Maven it is pom.xml.
  • Maven is built around the idea that a project depends on several libraries, which fundamentally exist as jar files somewhere. To build a project, the dependencies have to be download. Maven automates this, by fetching dependencies from a Maven repository, and caching them locally.
  • A lot of Maven functionality is provided by plugins, which are also jar files and which can also be downloaded from a repository.
  • So, yeah, Maven loves downloading shit. Maven builds can fail if run offline, because the dependencies/plugins can’t be downloaded.
  • The pom.xml file basically contains some basic project information (title etc), a list of dependencies, and a build section with a list of plugins.
  • Dependencies have a scope – they might be required at test, compile time, or run time, for example.
  • Even basic functionality is provided by plugins. To compile Java code, you need the maven-compiler-plugin.
  • To Maven, “deploy” means “upload to a repository”. Notionally, when you build a new version of something with Maven, you can then upload your new version to a Maven repository.
  • Where Ant has build targets, Maven has “lifecycle phases”. These include compile, test, package and deploy (which are all part of the build “lifecycle”, as opposed to the clean lifecycle). Running a phase runs all prior phases in the same lifecycle first. (Maven plugins can also provide “goals” which will run during a phase, and/or which can be run explicitly in a phase via the “executions” section for the plugin in the pom.xml file).
  • It seems that the Maven creators are fans of “convention over configuration”. So, for instance, your Java source normally goes into a particular directory (src/main/java) and this doesn’t have to specified in the pom file.

Initial Thoughts on Maven

I can see that using Maven means you have to expend minimal effort on the build system if you have a straight-forward project structure and build process. Of course, the main issue with the “convention over configuration” approach is that it can be inflexible, actually not allowing (as opposed to just not requiring) configuration of some aspects. In the words of Maven documentation, “If you decide to use Maven, and have an unusual build structure that you cannot reorganise, you may have to forgo some features or the use of Maven altogether“. I like to call this “convention and fuck you (and your real-world requirements)”, but at least it’s pretty easy to tell if Maven is a good fit.

However, I’m not sure why a whole new build system was really needed. Ant seems, in many respects, much more powerful than Maven is (and I’m not saying I actually think Ant is good). The main feature that Maven brings to the table is the automatic dependency downloading (and sharing, though disk space is cheap enough now that I don’t know if this is really such a big deal) – probably something that could have been implemented in Ant or as a simple tool meant for use with Ant.

So, meh. It knows what it can do and it does it well, which is more than can be said for many pieces of software. It’s just not clear that its existence is really warranted.

In conclusion

There you have it – my take on Maven and a simple explanation of how it works that you can grasp without reading through a ton of documentation. Take it with a grain of salt as I’m no expert. I wish someone else had written this before me, but hopefully this will be useful to any other poor soul who has to use Maven and wants to waste as little time as possible coming to grips with the basics.

Advertisements

4 thoughts on “Maven in 5 minutes

  1. Thanks. I also find it frustrating that open source projects are so badly documented. It often feels as though everybody on earth knows this stuff except me, and they’re not letting me join the club 🙂

    I’ve found Maven to be very brittle in practice. It doesn’t take much to upset it. Things go wrong with no obvious explanation and I then spend hours (sometimes days) of trawling through Stack Overflow to find an answer. That really grinds my gears – when my labour saving system ends up causing more work than before I used it.

  2. In my experience I found maven to be a huge headache. With ant I simply cherry pick libraries I need with least possible dependancies. However it wasn’t once when maven would create some convoluted build with circular dependancies that would take days to resolve. I know it may sound naive but when I see that software was built with maven and god forbid uses Spring and its derivatives I choose not to use it.

  3. > The main feature that Maven brings to the table is the automatic dependency downloading (and sharing, though disk space is cheap enough now that I don’t know if this is really such a big deal) – probably something that could have been implemented in Ant or as a simple tool meant for use with Ant.

    Well, actually, there is Avy for Ant. And it’s not a problem to fetch all the dependencies in the central jar cache (and by the way, you can disable automatic dependency resolution and can control everything your self) and then reference them from there to replicate the Maven’s jar sharing feature. But just believe me (I tell you this a professional Java software developer, meaning, they pay me for that), no commercial product would ever use Ant+Ivy. I never participated in such projects. But Maven, Gradle, SBT (uses Avy) and other shit floating all around and ready to be eaten. The reason is very simple: time. No product owner would ever pay you for “better architecture design”, “better build system” or “better CI”. “Better” costs too much for them. If there is a kick-off solution – eat it. All Maven-like solutions are exactly of that genre. Something that you can kick off very quickly, and it will work and will support 95% of use cases. So… shut up and eat the shit. Who told you there is the justice in this world?

    1. > So… shut up and eat the shit. Who told you there is the justice in this world?

      Well: even if you find yourself having to eat shit, staying silent about it is unlikely to result in the situation improving (and complaining in itself might even make you feel better about it). Your point is valid but irrelevant in this context. To paraphrase Sarah Connor, there is “no justice but that which we make for ourselves”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s