As Ant was created to overcome the shortages of make, Maven was created with a similar intention—to overcome the shortages of Ant. You may recall that make could not guarantee build portability because the commands make executes are arbitrary shell commands that may be system specific. An Ant build, if all the tasks are available on the classpath, is portable as long as Java runs the same way on the different platforms.
The problem with Ant is a bit different. When you download the source code of a project and you want to build, what will the command be? You should ask Ant to list all the targets and select the one that seems to be the most suitable. The name of the task depends on the engineer who crafted the build.xml file. There are some conventions, but they are not strict rules.
Where will you find the Java source files? Are they in the src directory or not? Will there also be some Groovy or other programming language files in case the project is polyglot? That depends. Again, there may be some conventions that some groups or company cultures suggest, but there is no general best industry practice.
When you start a new project with Ant, you will have to create the targets for compilation, test execution, and packaging. It is something that you will have already done for other projects. After the second or third project, you will just copy and paste your previous build.xml to your new project. Is that a problem? Yes, it is. It is copy/paste programming, even if it is only some build files.
Developers realized that a significant effort of the projects utilizing Ant is devoted to project build tool configuration, including repetitive tasks. When a new joiner comes to the team, they will first have to learn how the build is configured. If a new project is started, the build configuration has to be created. If it is a repetitive task, then better let the computers do it. That is generally what programming is all about, isn't it?
Maven approaches the build issue a bit differently. We want to build Java projects. Sometimes, some Groovy or Jython things, but they are also JVM languages; thus, saying that we want to build Java projects is not really a huge restriction. Java projects contain Java files, sometimes some other programming language's source files, resource files, and generally, that is it. Ant can do anything, but we do not want to do just anything with a build tool. We want to build projects.
Okay, after we restricted ourselves and accepted that we do not need a build tool that can be used for anything, we can go on. We can require that the source files be under the src directory. There are files that are needed for the operational code and there are files that contain some test code and data. Therefore, we will have two directories, src/test and src/main. Java files are in src/main/java as well as src/test/java. Resource files are under src/main/resources and src/test/resources.
If you want to put your source files somewhere else, then don't. I mean it. It is possible, but I will not even tell you how. Nobody does it. I do not even have any idea why Maven makes it possible. Whenever you see a project that is using Maven as a build tool, the sources are organized like that. There is no need to understand the directory structure envisioned by the project's build engineer. It is always the same.
How about the targets and the tasks? They are also the same for all Maven-based projects. What else would you like to do with a Java project other than compile, test, package, or deploy it? Maven defines these project life cycles for us. When you want to compile a project using Maven as a build tool, you will have to type $ mvn compile to compile the project. You can do that even before understanding what the project actually is.
As we have the same directory structure and the same goals, the actual tasks leading to the goals are also all the same. When we create a Maven project, we do not have to describe what the build process has to do and how it has to do it. We will have to describe the project, and only the parts that are project specific.
The build configuration of a Maven project is given in an XML file. The name of this file is usually pom.xml, and it should be in the root directory of the project, which should be the current working directory when firing up Maven. The word POM stands for Project Object Model, and it describes the projects in a hierarchical way. The source directories, the packaging, and other things are defined in a so-called super POM. This POM is part of the Maven program. Anything that the POM defines, overrides the defaults defined in the super POM. When there is a project with multiple modules, the POMs are arranged into a hierarchy, and they inherit the configuration values from the parent down to the modules. As we will use Maven to develop our sorting code, we will see some more details later.