During our java based microservice development, we extensively use build tools like Maven or Gradle. Usually, IDEs do a lot on our behalf or we just run some predefined commands without checking what's happening inside. Here in this series of 6 posts, I tried to explain Maven.
Before I start talking about what Maven is, and its different components, let’s discuss the “why”. Why do we even need Maven?
For this, I’ve to first explain the nature of a Java-based project and also need to take you back in history.
The “Build” Step.
Java is a compilable language, Unlike Python or Javascript, which are interpreted. ie, the code we write in java, can not as-is run on a Java virtual machine (JVM). JVM understands only the bytecode.
Therefore, in the Java world, there is always a need for an intermediary step. A step that compiles the java code files into bytecode. That's why after writing the java code, we “somehow” create some deployable (jar, war, ear) to run on machines having JVMs.
This intermediary step of converting the java code to a deployable is called the build process, and this is what gave birth to various build tools for java.
In an enterprise application, the build process is more complex. Older monolith enterprise applications used to have many other components, ie, XML configs, UI code files, etc. So the intermediary step was not limited to code compilation, there were various other steps involved to create a final deployable, such as placing UI files in the right places, copying configuration files, etc.
Older ways
This is how we progressed as I remember.
- In the early 2000s, I remember creating jar files for standalone applications by using
jar -cfon my developer machine and deploying them on the required production machine. - Things got a little better when we started creating deployable using fancy IDE (eclipse) plugins, but still on the developer machines.
- Then came an era of ANT. With Ant scripts, the whole build process could be defined in XML files using interdependent Targets, with predefined or custom tasks.
I migrated the complete build process for a few big enterprise applications with ant script and custom tasks. In retrospect, that was too much work compared to what we need to do now thanks to maven.
The unsolved problem
ANT streamlined the build processes to a big extent by removing manual steps during the build and providing the capability to create a final deployable with just one command or click.
However, an initial project setup was still an issue. Someone still had to figure out all the dependency jars needed by the codebase and manually place them at some predefined location for ANT to use during the build.
And It was not just the direct dependencies that need to be placed, but also the transitive dependencies with supported versions.
In my experience, finding the correct version of supported dependencies was the real challenge, because of the broken backward compatibility of many transitive dependencies.
The ultimate solution
The folks in Apache solved this problem, by introducing a build tool named Apache-Maven. The word “Maven” means an expert. So this tool was an expert on all the things a build process needs.
Maven was introduced as a build tool for Java-based projects. Maven addressed a lot more than just the dependency management problem that I explained in the previous section.
For example, code quality checks, running integration tests, deploying the artifact to the shared repository, etc. We will discuss them in the next 6 (or more) posts of this series. Here are the direct link (if the post is ready) for each post in the series.
- Maven (1)- The Life of a build (Goals & Phases)
- Maven (2)- I need you (Dependencies)
- Maven (3)- Conflicts resolution (the Maven way)
- Maven (4)- Changing the life (build Plugins)
- Maven (5)- Multi-Module project
- Maven (6)- BOM to manage POM
That's all for the preface of the series, go through the remaining posts in the series for more understanding.
Comments