In this post I’m going to give an overview of Maven. I won’t explain all it’s features and capabilities in detail. I plan to stick to the important bits. As with anything, if you want to know more, consult Dr. Google.
If you’re interested in some tips on how to use Maven rather than learning about the tool itself then check out this post.
What is Maven?
In short, Maven is a build automation and dependency management tool for Java-based software projects. If all the words in that last sentence had meaning to you, in the context of software development, then you’re done. GG.
However, if you still feel like you need more I’ll explain each part as we go along. We’ll go word by word. I’ll explain what and then why.
What is a build and why would I want to automate it?
A build is the culmination of your dev efforts. It’s the thing you’ve been working towards since the beginning. It’s the process by which your code is compiled into an executable archive. Depending on what you’re working on, a build generates your JAR or WAR. Sometimes a build generates both WARs and JARs or multiples of each.
You’d want to automate the process of building because it would be a nightmare to show each developer on your project the oddly specific way your code is built. The nightmare becomes apocalyptic when you realize that in addition to training each person you also have to make sure they have all the same “files” you have and in exactly the same places. The word “files” in that last sentence was in quotes because each of those hypothetical “files” is a dependency.
What is a dependency and why do I need something like Maven to manage them?
A dependency is a file your code needs to run/compile properly. Dependencies are usually visible to most devs in the form of “import” statements at the top of their classes/scripts/code.
In case you’re not sure why you put imports at the top of your classes, I’ve got you covered there too. You use imports to add functionality to your code that isn’t built into the Java language. Imports are essentially programming shortcuts. They allow you to build upon and use the work of other devs. Devs have an aversion (or at least they should) to reinventing the wheel. As a result, Devs tend to attempt to build on top of each others work.
For example, we all can work out how to reverse a string. Why should I have to solve that riddle over and over? Dependencies solve this problem for us. Each time you use an import that isn’t built into the Java language, the import translates into a need for a file/dependency.
Without a program to do it for you, you’ll need to go out and download each of the dependencies that your projects needs. To further complicate the problem, technology is always changing and devs are always updating their projects. Their projects are your dependencies so you’ll also need to make sure that you have the correct version of each of your dependencies. Sounds like a lot of work, right? The people who made Maven thought the same thing.
The all mighty POM.
POM stands for “Project Object Model”. Usually found at the root of your projects directory in the form, “pom.xml”, the POM file is your bread and butter when it comes to Maven. It houses all the things that Maven needs to know about and do to your code. It holds dependencies, project names, build order, build steps, properties, Maven plugins, etc… all of the things.
I can’t say that I’m capable of much more than basic changes and configuration in POM files but there exist wizards, I’ve only ever encountered one out in the wild, who know how to manipulate POM files on a higher plane. Their sorcery allows them to be able to do things like have cascading POM files in sub directories that have slightly differing behaviors that are orchestrated by a parent POM file.
Why does Maven exist?
Ever go to install a piece of software on a new machine and it didn’t work? In your frustration of trying to get it to work, have you ever heard a coworker or friend say “well it works on my machine”? That same thing happens to devs while trying to build. You just need it to run. Getting it to build on your own machine is hard enough. It’s even harder getting it to build on several other similar but slightly different machines.
Maven standardizes the build process and (ideally) makes it so that if it’s broken somewhere, it’s broken everywhere. So when you inevitably hear “it works on my machine”, you can confidently reply “not for long”, instruct them to take an update from version control and laugh as their happiness fades.
Why is Maven valuable?
Read literally any of the stuff above. Not enough? I’ll add a little more. Maven is valuable because knowing the config of any Maven project allows you an entry point for understanding every Java project that uses Maven. Just the same as learning to drive a car gives you a base level of knowledge for approaching all cars . Need a tech specific example? Once you know git, you have a baseline for approaching all projects that use Git for version control. Maven is similar to Git in that understanding it will make your life as a dev much easier.