Maven - reflections after two years of use
For the past two years, I have been using Maven as a tool for building projects. As a result, I was very unhappy with Mawen, unhappy so much that I was seriously considering the translation of the current project to Ant.
Before discussing the reasons for my discontent, you 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 tool for managing software projects (software project management tool). In reality, Maven is a system for managing the build of a project, in terms of goals in many respects similar to tools like Ant and make. The distinctive features of Maven are:
')
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, many very tangible shortcomings.
Let's start with the merits. Building with Maven is very simple. It is enough to write mvn clean install in the project root - and the project will come together! You do not need to search and download the necessary libraries, you do not need to study scripts. This team will always work, regardless of the type of project.
In addition, since Maven is very conducive to the standardization of 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.
Since the project is described as a model, some interesting things become possible. For example, you can automatically create a project from, for example, Eclipse from the Mavena project - while in the Eclipse project, all directories will already be properly configured, libraries will be connected, and so on.
This list of advantages ends. Go to the shortcomings.
Maven is poorly documented. Documentation seems to be as it is, but finding the answer to many questions is almost impossible. This applies to both Maven himself and his plug-ins. Moreover, even the book “Maven: the definitive guide”, although it clarifies many things, leaves many questions open.
Maven is talkative, but at the same time not intelligible. In standard mode, it displays a huge amount of all sorts of information at the time of assembly, usually completely unnecessary. Debug mode is just a disaster! On our project in this mode, Maven, when assembling, outputted over 80 thousand lines! At the same time error messages and problems are often extremely vague and mysterious.
Project models are long, poorly readable and difficult to change. Bastard syntax based on XML; model inheritance, as a result of which it is often necessary to look through several models to determine which configuration will eventually be used during assembly; smearing the configuration in different parts of the model - this is not a complete list of factors that lead to this situation.
The assembly process depends on external systems. Precisely - from repositories. I had a case when one new employee had inexplicable problems with the project assembly. In the end, it turned out that one of the repositories changed the URL. Those from whom Maven had already downloaded everything they needed did not notice anything; But the new staff could not collect the project.
Maven in the build process downloads a huge number of various files. The fact is that one of the elements of the Mavena dependency management system is a local repository. All that is necessary for the assembly, Maven downloads and installs into this very local repository. On the one hand, this is good - if a library is needed in several projects, it will be downloaded only once, and then Maven will take it from this local repository. On the other hand, the amount downloaded downloaded is amazing. For example, on my work computer, on which I collected about five different (but of the same type) projects, the repository occupies more than a gigabyte, and contains four and a half thousand files and directories!
Maven is poorly suited for automating near-assembly tasks. I often had different actions in different projects, often unrelated to the main build, which 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 at the same time, but everything was documented). Maven just does not give such an opportunity.
Mavena’s very tough approach to the assembly sequence creates great difficulties in cases where it is necessary to move at least a step away from this sequence. For example, at some point I needed to compile the same module twice, but with different settings, and then place the two results in different places under different names. It turned out to be very, very nontrivial.
Maven is difficult to understand and master. The reasons are all of the above.
Features Mavena, for the most part, bring more problems than good. Perhaps Maven can be good for projects in a stable phase, when changes in the project structure 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 being moved - Maven turns into an endless source of headaches.
I myself want to stop using Maven, and go to the Ant + Ivy combination. Ant will do an excellent job with the project build, and Ivy will add the ability to manage dependencies to it, the same Maven opportunity that was lacking in other tools.
Before discussing the reasons for my discontent, you 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 tool for managing software projects (software project management tool). In reality, Maven is a system for managing the build of a project, in terms of goals in many respects similar to tools like Ant and make. The distinctive features of Maven are:
- 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. In the project description, only what is different from the standard is indicated (for example, a non-standard directory structure).
- Dependency Management (dependency management). If the assembly (or execution) of the project requires some additional libraries, it is enough to indicate them in the project description - Maven downloads them himself, figure out what 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), in which libraries and their descriptions are stored.
- Descriptive language Unlike other similar tools, Maven uses exactly the project description, which is called the Project Object Model (Project Object Model), abbreviated POM (I will call this the “project model”). The model does not indicate what, how and when should be performed to assemble the project; instead, it describes how the project works, what it depends on, and so on. It is supposed that Maven will independently figure out how to build a project on the basis of this information.
- Rigid assembly sequence. Maven assumes that the assemblies of all projects fit into several types of assembly sequences (in Maven's terminology of life cycles, lifecycles). The sequence consists of certain phases (resource processing, compilation, tests, packaging, installation ...), which the project runs in a strictly defined order. The project model specifies specific details of what exactly should be done in one phase or another (“use the following 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, many very tangible shortcomings.
Let's start with the merits. Building with Maven is very simple. It is enough to write mvn clean install in the project root - and the project will come together! You do not need to search and download the necessary libraries, you do not need to study scripts. This team will always work, regardless of the type of project.
In addition, since Maven is very conducive to the standardization of 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.
Since the project is described as a model, some interesting things become possible. For example, you can automatically create a project from, for example, Eclipse from the Mavena project - while in the Eclipse project, all directories will already be properly configured, libraries will be connected, and so on.
This list of advantages ends. Go to the shortcomings.
Maven is poorly documented. Documentation seems to be as it is, but finding the answer to many questions is almost impossible. This applies to both Maven himself and his plug-ins. Moreover, even the book “Maven: the definitive guide”, although it clarifies many things, leaves many questions open.
Maven is talkative, but at the same time not intelligible. In standard mode, it displays a huge amount of all sorts of information at the time of assembly, usually completely unnecessary. Debug mode is just a disaster! On our project in this mode, Maven, when assembling, outputted over 80 thousand lines! At the same time error messages and problems are often extremely vague and mysterious.
Project models are long, poorly readable and difficult to change. Bastard syntax based on XML; model inheritance, as a result of which it is often necessary to look through several models to determine which configuration will eventually be used during assembly; smearing the configuration in different parts of the model - this is not a complete list of factors that lead to this situation.
The assembly process depends on external systems. Precisely - from repositories. I had a case when one new employee had inexplicable problems with the project assembly. In the end, it turned out that one of the repositories changed the URL. Those from whom Maven had already downloaded everything they needed did not notice anything; But the new staff could not collect the project.
Maven in the build process downloads a huge number of various files. The fact is that one of the elements of the Mavena dependency management system is a local repository. All that is necessary for the assembly, Maven downloads and installs into this very local repository. On the one hand, this is good - if a library is needed in several projects, it will be downloaded only once, and then Maven will take it from this local repository. On the other hand, the amount downloaded downloaded is amazing. For example, on my work computer, on which I collected about five different (but of the same type) projects, the repository occupies more than a gigabyte, and contains four and a half thousand files and directories!
Maven is poorly suited for automating near-assembly tasks. I often had different actions in different projects, often unrelated to the main build, which 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 at the same time, but everything was documented). Maven just does not give such an opportunity.
Mavena’s very tough approach to the assembly sequence creates great difficulties in cases where it is necessary to move at least a step away from this sequence. For example, at some point I needed to compile the same module twice, but with different settings, and then place the two results in different places under different names. It turned out to be very, very nontrivial.
Maven is difficult to understand and master. The reasons are all of the above.
findings
Features Mavena, for the most part, bring more problems than good. Perhaps Maven can be good for projects in a stable phase, when changes in the project structure 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 being moved - Maven turns into an endless source of headaches.
I myself want to stop using Maven, and go to the Ant + Ivy combination. Ant will do an excellent job with the project build, and Ivy will add the ability to manage dependencies to it, the same Maven opportunity that was lacking in other tools.
Source: https://habr.com/ru/post/102181/
All Articles