Thursday, July 17, 2014

Being a Maven maven

I spent the morning trying to use the Quasar library but it mostly came down to reading a lot about Maven to get all the libraries dependencies required by Quasar.

Maven is a Java build tool similar to Ant, Make or SCons. Unlike most build tools, Maven does dependency resolution of third party libraries. If your project depends on other libraries Maven will resolve and download them with a similar logic to tools like Yum . Meaning you don't need to go and find them yourself (or check-in your library dependencies into version control). Maven will read the list of the dependencies for your project and it recursive download exactly the right libraries for you from its fancy, federated package management repository system.

This is both wonderful and frustrating. It's wonderful because it's pretty much how things should work. It's frustrating because third-party libraries that use Maven for *their* dependent libraries force you to either resolve all the dependencies yourself or use maven.

Resolving all the dependencies yourself is a huge pain. Maven makes resolving dependencies easier so encourages adding a dependencies to third-party library. This make it more likely that there are a greater number of  dependencies to resolve. It also makes tracking down the project page difficult because no one bothered to document that because it's all in Maven so why not just use Maven?

Switching your project over to Maven can be difficult too. Not only do you have to learn a new tool for but Maven is very anal about exactly how it expects your project to be set up and behave. Project configuration for IDEs should be generated by Maven. Code files should be in such and such a place. Unit test file should be in this other such and such a place. Resources should be in this other other such and such a place. And so on. Dependencies should be in maven, version control by maven installable by maven. Maven is in line with best practices and makes a lot of sense. The problem is the universe does not revolve around Maven. All legacy projects cannot always be restructured to the Maven world order just because of Maven!

Maven maven maven? Maven maven! Maven maven maven maven...!?

With my own projects I've historically included the dependencies in the source repository. Dependency resolution is a finicky thing and a source of breakage. I don't want whoever is building or using my project to have to worry about it. Hard drive concerns be damned. Programmer time is more precious than hard disk space so just give me everything I need in the project checkout.

A few people online have been suggesting using maven as a dependency resolution tool and just ignoring the build tool aspect. I could see how this makes sense but convincing an organization to use maven for dependencies and a different build tool for building when maven does both is going to be hard. There are simply so many opportunities for confusion about which tool to use when and why. Oh woe is me..

And now back to working with Quasar..

No comments: