Introduction

• This is going to be a series where I try to explain the concepts of developing java applications with Maven. I will be walking us through an online book hosted by the TheNEXUS. Feel free to check on the book yourself if you every feel lost or confused. This will be a project based series, However, this first post is about getting to understand Maven at a high level. Future blog posts will also have a YouTube video walking through the projects.

What is Maven?

• If you have ever created a project with React or with Spring Boot, then you have definitely benefited from some build automation. For React projects you have Webpack and for Spring Boot projects you have Maven. This brings us back to our original question, what is Maven? Well some people might call Maven a build tool but it is actually something a bit more. Maven is a project management tool, which is essentially a build tool will more features. It provides additional build capabilities, we can run reports, generate a website and facilitate communication among a working team. When we use Maven, we are describing our project using a project object model (POM.xml file). Maven can then provide the logic to your project which is defined in the Maven plugins. So what is Maven? It is a build tool on steroids.

Convention Over Configuration

• convention over configuration simply means that libraries, Systems and frameworks should have some reasonable defaults. Maven gives this to our projects free of charge. So we can assume things like, source code is in /src/main/java, resources are in /src/main/resources, tests are in /src/main/test and the project is assured to be in a JAR file. There are more code conventions that Maven enforces but this gives us the general idea. The opinioned nature of Maven is what has made it so popular. Thanks to this opinioned nature we can jump from one project to another and spend little to no time figuring out the project build. Maven has a life cycle and a set of common plugins that know how to build and assemble software(more on this in a later post). As software developers all we have to do is follow the conventions that Maven provides, it will do the rest.

Common Interface

• Before Maven provided what is a "common interface", which simplified the whole software building process. Every project usually had someone who was solely dedicated to managing the custom build process. Those days were know as the time of the build engineer. Back in those days, it could take a couple of hours or even a couple of days to make sure you have the proper build of a system. However, now thanks to the "common interface" which is all the opinionated features that Maven imposes on us, all we have to do is download the code and then run the command "mvn install".

Universal Reuse through Maven Plugins

• basically plugins give extra behaviour to our projects build. Maven retrieves both dependencies and plugins from the remote repository. This is what allows for the universal reuse of the build logic.
• now it is thanks to plugins that we don't have to keep updating our software. We can use the Maven Surefire plugin which is the responsible for running unit tests. When a new update is created for that plugin we don't have to worry about our code breaking or any backwards compatibility.
• Maven has plugins for everything, compiling code, generating code, deploying to servers and many more. Plugins are downloaded from remote repositories so we can have universal reuse through Maven plugins.

Conceptual Model for a Project

• Maven maintains a model of a project, and with Maven we are not just compiling source code into byte code, we are architecting a whole software project, we are describing the attributes, the projects licence, who are the developers, what are the dependencies and more. The "conceptual model" of a project is as follows: (these might be confusing now but future posts will elaborate)

Dependency Management

• because a project is defined as a unique set of coordinates consisting of a group identifier, artifact identifier and a version, projects can now use the coordinates to declare dependencies.

Remote Repositories

• we can use the coordinates defined in the Maven Project Object Model(POM.xml file) to create repositories of Maven artifacts.
• A quick word for those unfamiliar with what an artifact is. In general software terms, an artifact is something produced by the software development process. In Maven the artifact is the resulting output of the Maven build and it is generally a WAR or JAR file.

Universal Reuse of Build Logic

• Plugins contain logic that works with descriptive data and configuration parameters defined in the Project Object Model(POM.xml file).

Tool Portability/Integration

• tools like NetBeans, Eclipse and InteliJ now have a common place to find information about a project.

Conclusion

• I want to mention a few things before I end this blog post
• 1) I will be skipping the next chapter in the Book. It is on installing Maven and a quick search on YouTube will provide a explanation on how to do that.
• 2) the next post will be chapter 3 of the Nexus book, where we build a simple Maven project.
• 3) Finally, thank you for taking time out of your day to read this blog post of mine. I hope we can both become better developers because of it and if you have any questions or concerns please comment below or reach out to me on Twitter.