Maven - Reflections After Two Years of Use
Over the past two years, I have used Maven as a tool for building projects. As a result, I was very dissatisfied with Maven, so dissatisfied that I seriously considered translating the current project to Ant.
Before discussing the reasons for my dissatisfaction, I need to say a few words about Maven. I will not describe it in detail, just briefly outline its main features.
The description on the site says that Maven is a software project management tool. In reality, Maven is a system for managing the assembly of a project, in terms of goals in many ways similar to tools like Ant and make. Distinctive features of Maven are as follows:
As you can see, in theory, Maven is a very powerful and interesting tool. In practice, the picture looks somewhat different. Of course, Maven has certain advantages, but also, alas, there are many very tangible shortcomings.
Let's start with the virtues. Assembly with Maven is very easy. It is enough to write mvn clean install at the root of the project - and the project will assemble! No need to search and download the necessary libraries, no need to study scripts. This team will always work, regardless of the type of project.
In addition, since Maven is very helpful in standardizing the directory structure (read: it is extremely difficult to work with a non-standard structure), it is always quite easy to understand where what is located.
Since the project is described in the form of a model, some interesting things become possible. For example, you can automatically create a project for, for example, Eclipse from the Maven project - in this case, all directories will be correctly configured in the Eclipse project, libraries will be connected, and so on.
On this list of advantages ends. We turn to the disadvantages.
Maven is poorly documented. The documentation seems to be there, but it is almost impossible to find the answer to many questions. This applies to both Maven and its plugins. Moreover, even the book “Maven: the definitive guide”, although it clarifies many things, but leaves a lot of questions open.
Maven is talkative, but at the same time unintelligible. In standard mode, it displays during assembly a huge amount of all kinds of information, usually completely unnecessary. Debug mode is just a disaster! On our project in this mode, Maven displayed more than 80 thousand lines during assembly! At the same time, error messages and problems are often extremely foggy and mysterious.
Project models are long, poorly readable, and difficult to modify. Dirty XML-based syntax; model inheritance, as a result of which it is often necessary to look at several models to determine which configuration will ultimately be used in the assembly; the smearing of the configuration in different parts of the model is far from a complete list of factors that lead to such a situation.
The build process depends on external systems. Namely - from the repositories. I had a case when one new employee had unexplained problems with the assembly of the project. In the end, it turned out that one of the repositories changed URL. Those from whom Maven already managed to download all that is needed did not notice anything; but new employees could not assemble the project.
Maven during the assembly process downloads a huge number of all kinds of files. The fact is that one of the elements of the Maven dependency management system is the local repository. Everything that is needed for assembly, Maven downloads and installs in this very local repository. On the one hand, it’s good - if a library is needed in several projects, it will be downloaded only once, and then Maven will take it from this very local repository. On the other hand, the amount downloaded is amazing. For example, on my working computer, on which I collected about five different (but of the same type) projects, the repository takes up more than a gigabyte, and contains four and a half thousand files and directories!
Maven is poorly suited for the automation of "near-assembly" tasks. I often met in different projects some actions, often not related to the main assembly, that required automation: copy files from one part of the project to another, process the code with analyzers, clean some directories, and so on. When I used Ant, I created additional goals in the project - and everything was fine (well, yes, the project was complicated, but everything was documented). Maven just does not give such an opportunity.
The very tough Maven approach with respect to the assembly sequence creates great difficulties in those cases when you need to move at least a step from this sequence. For example, at some point I needed to compile the same module twice, but with different settings, and then put the two results in different places under different names. It turned out to be very, very non-trivial.
Maven is difficult to understand and master. Reasons - all of the above.
The features of Maven, for the most part, bring more problems than benefits. Perhaps Maven may be good for projects in a stable phase, when changes in the structure of the project are almost not happening. In the active phase of the project, when the assembly process has not yet been fully formed - new modules are added, parts are moving - Maven turns into an endless source of headache.
I myself want to abandon the use of Maven, and switch to the combination of Ant + Ivy . Ant will do a great job of building the project, and Ivy will add to it the ability to manage dependencies, the very ability of Maven, which was very lacking in other tools.
Before discussing the reasons for my dissatisfaction, I need to say a few words about Maven. I will not describe it in detail, just briefly outline its main features.
What is Maven?
The description on the site says that Maven is a software project management tool. In reality, Maven is a system for managing the assembly of a project, in terms of goals in many ways similar to tools like Ant and make. Distinctive features of Maven are as follows:
- The primacy of convention over configuration. If the project follows certain standards, then Maven himself will understand what and how to do to assemble the project. The description of the project indicates only what differs from the standard (for example, a non-standard directory structure).
- Dependency Management If some additional libraries are required to build (or execute) a project, it is enough to specify them in the project description - Maven will download them himself, figure out which version is needed, and if these libraries, in turn, depend on other libraries, then Maven downloads them, and so on. For this, Maven uses remote repositories (repositories, repositories), which store libraries and their descriptions.
- Descriptive language. Unlike other similar tools, Maven uses exactly the project description, which is called the Project Object Model, abbreviated as POM (I will call it the “project model” in the future). The model does not indicate what, how and when should be completed to assemble the project; instead, it describes how the project is structured, what it depends on, and so on. It is assumed that Maven will independently figure out how to assemble the project based on this information.
- Rigid assembly sequence diagram. Maven suggests that assemblies of all projects fit into several types of assembly sequences (in Maven’s terminology “life cycles”, lifecycles). The sequence consists of certain phases (processing of resources, compilation, tests, packaging, installation ...), which the project passes in a strictly specified order. The project model specifies specific details of what should be done in one or another phase (“use these compiler options when compiling ...”).
Reality
As you can see, in theory, Maven is a very powerful and interesting tool. In practice, the picture looks somewhat different. Of course, Maven has certain advantages, but also, alas, there are many very tangible shortcomings.
Let's start with the virtues. Assembly with Maven is very easy. It is enough to write mvn clean install at the root of the project - and the project will assemble! No need to search and download the necessary libraries, no need to study scripts. This team will always work, regardless of the type of project.
In addition, since Maven is very helpful in standardizing the directory structure (read: it is extremely difficult to work with a non-standard structure), it is always quite easy to understand where what is located.
Since the project is described in the form of a model, some interesting things become possible. For example, you can automatically create a project for, for example, Eclipse from the Maven project - in this case, all directories will be correctly configured in the Eclipse project, libraries will be connected, and so on.
On this list of advantages ends. We turn to the disadvantages.
Maven is poorly documented. The documentation seems to be there, but it is almost impossible to find the answer to many questions. This applies to both Maven and its plugins. Moreover, even the book “Maven: the definitive guide”, although it clarifies many things, but leaves a lot of questions open.
Maven is talkative, but at the same time unintelligible. In standard mode, it displays during assembly a huge amount of all kinds of information, usually completely unnecessary. Debug mode is just a disaster! On our project in this mode, Maven displayed more than 80 thousand lines during assembly! At the same time, error messages and problems are often extremely foggy and mysterious.
Project models are long, poorly readable, and difficult to modify. Dirty XML-based syntax; model inheritance, as a result of which it is often necessary to look at several models to determine which configuration will ultimately be used in the assembly; the smearing of the configuration in different parts of the model is far from a complete list of factors that lead to such a situation.
The build process depends on external systems. Namely - from the repositories. I had a case when one new employee had unexplained problems with the assembly of the project. In the end, it turned out that one of the repositories changed URL. Those from whom Maven already managed to download all that is needed did not notice anything; but new employees could not assemble the project.
Maven during the assembly process downloads a huge number of all kinds of files. The fact is that one of the elements of the Maven dependency management system is the local repository. Everything that is needed for assembly, Maven downloads and installs in this very local repository. On the one hand, it’s good - if a library is needed in several projects, it will be downloaded only once, and then Maven will take it from this very local repository. On the other hand, the amount downloaded is amazing. For example, on my working computer, on which I collected about five different (but of the same type) projects, the repository takes up more than a gigabyte, and contains four and a half thousand files and directories!
Maven is poorly suited for the automation of "near-assembly" tasks. I often met in different projects some actions, often not related to the main assembly, that required automation: copy files from one part of the project to another, process the code with analyzers, clean some directories, and so on. When I used Ant, I created additional goals in the project - and everything was fine (well, yes, the project was complicated, but everything was documented). Maven just does not give such an opportunity.
The very tough Maven approach with respect to the assembly sequence creates great difficulties in those cases when you need to move at least a step from this sequence. For example, at some point I needed to compile the same module twice, but with different settings, and then put the two results in different places under different names. It turned out to be very, very non-trivial.
Maven is difficult to understand and master. Reasons - all of the above.
conclusions
The features of Maven, for the most part, bring more problems than benefits. Perhaps Maven may be good for projects in a stable phase, when changes in the structure of the project are almost not happening. In the active phase of the project, when the assembly process has not yet been fully formed - new modules are added, parts are moving - Maven turns into an endless source of headache.
I myself want to abandon the use of Maven, and switch to the combination of Ant + Ivy . Ant will do a great job of building the project, and Ivy will add to it the ability to manage dependencies, the very ability of Maven, which was very lacking in other tools.