Maven - why?

In the vastness of the network in general, and in particular, I hated to see more than one topic dedicated to Maven. And wherever there was a discussion , there were questions like:

• What gives its use in a project of type X?
• How is it better Ant / Make / sh?
• And what if I want to use antlr / JAX-WS / XDoclet in the project?

I suppose that all these questions come from ignorance that Google has a lack of understanding what Maven is and what approach to solving the tasks of build management it offers. Which in turn grows out of the lack of attention that the authors of the articles devote to the ideas behind the xml files and fascinating console commands.


I understand that when Mavens are said they mean 3 rather weakly related things:

• Pom. Project object model. Model of the project - it describes what the project consists of and how its life cycle is arranged.
• Artifact repositories. Storage locations for product builds of software modules along with metadata.
• Utility mvn and plugins to it. Actually a tool for assembling modules lifecycle management projects .

Let's look at each one individually to see how they can be used together.

POM

This is a general project model. It describes such common characteristics as name, version, authors and their contact information, project VCS and network resources associated with it, project type (for example, a library or a web module, in the original terminology is called packaging, although it affects not only the type of artifact), links with other projects, plug-ins used in assembling and descriptions of how they are used. Two components of this model seem especially important to me.
')

Links to other modules

POM allows three types of relationships with other modules: dependency, inclusion, and inheritance.

Dependency , this connection says that for some phases of the life cycle of our module, some artifacts of dependency modules are required (it turned out abstractly - it’s already very scary). What exactly and at what phase of the life cycle is required is determined by the so-called scope of dependence. Maven understands several predefined scopes and allows you to add your own. As an example, I’ll confine myself to one scope: compile - it says that binary dependency assemblies are required at compile time, test execution, and run time.

Inclusion - says that the connected module is an integral part of our module. In order for our module to pass through some phase of the life cycle, the part of it must also go through this phase. A classic example is an enterprise module that includes a web module, an EJB package, and a shared library. Obviously, its assembly requires the assembly of each of the included modules.

Inheritance . Such a relationship implies transferring to the heir part of the ancestor's model. The transfer rules are somewhat confused, but basically the principle is that the value of the ancestor model parameter becomes the default for the descendant model. An example from my practice: a module was created that installs the JDK version for compiling projects, internal repositories for results, a set of rules for verifying that the source code complies with the coding standard; within the project modules.

Description of the plugins used in the assembly

The description consists of the name of the plug-in used, some of its settings (they are determined by the plug-ins individually), and the goals it actually performs at each phase of the life cycle (a detailed description of the ideas behind these terms see below).

This element is somewhat alien to the general idea of ​​POM - it carries not a declarative description of the module, but instructions for assembling it with a specific tool.

Results

1. POM is a generic, unified model for describing software modules.
2. It supports storing not only the attributes of individual modules but also high-level links between them.
3. It also carries information about the tools needed to support the life cycle of a module.

Artifact Repositories

Artifact repositories are dedicated repositories of build results designed to make it easier to find the desired artifact (by name, version, artifact type). They allow a group of developers to use the results of each other's work without having to have copies of the source codes of their modules and build the dependency tree with 0. Maven-compatible repositories have become the standard for publishing the results of various open source projects.

It should be noted that the pom-files containing the project model are also artifacts and can be stored in the repositories along with everyone else (in fact, at least their trimmed versions containing only the identification of the module and the dependencies are always stored). Thus, the repository is also a source of information (as minimum enough for distribution) about the modules stored in it.

So, what bonuses do they give us:

1. Structured storage of artifacts, their cataloging.
2. Reuse artifacts.

Lifecycle management utility

The name turned out quite pathetic, but it is fully consistent with the high mission and complexity of the subject.

Before you dive into its functions, you need to get a little acquainted with the theory of the organization of the life cycle of the module in Maven. The life cycle is the whole set of operations on the module from the initialization of the assembly to deployment. In the course of the life cycle, certain operations are performed on the module, some artifacts are formed. The life cycle is divided into phases. Each phase involves the transfer of the module to a new state as a result of its passage and the appearance of new artifacts. Each previous phase prepares the groundwork for the next. The list of phases is essentially a part of the POM, but global, common to all modules. It’s pointless to list the new list, but for an example I’ll give several phases (quite intuitively named, in my opinion :)) in the order they follow: compile, ... test, ... deploy.

Within each phase, a certain set of goals is fulfilled depending on the model of a particular module. A goal is a specific operation on source codes and / or artifacts.

Now to the utility itself. She is responsible for implementing the life cycle based on the project model. It consists of two main components:

1. First of all, from a very small kernel, which describes (built, as the common people say) the basic principles of project design, the default goals for the phases of standard project types, the working environment for plug-ins (access interfaces to models, repositories, file systems, settings, and .P.).
2. Secondly from the plugins. They actually contain code that accomplishes the goals. Virtually all external mvn functionality is implemented by them. They generate, compile, test, pack, etc. etc.

Communication with this utility is extremely simple: you say to what phase condition you need to bring the client module and it does it. All the complexity of the formulation and execution of tasks to achieve the goal remains on the conscience of plugin developers (well, well, a little remains on the model developer). For example, we say compile and compile for us, and not only what got out of the VCS, but also generate the necessary, for example wsimport, and the results are also compiled.

You can also ask to perform a separate task specific plugin. For example, there is a plugin for generating Eclipse-projects, the task of which is to “generate a project” by default is not tied to any phase, but is called manually by interested parties.

Another extremely interesting feature of mvn is the creation of a project blank based on the archetype. An archetype is a generalized project template that traditionally concentrates on its structure and the plugins used. For example, there are standard archetypes of java-library, web-module, and non-standard, for example grails application. It is important to understand the difference between the archetype and the type of project. An archetype is only a template for the initial structure and individual parts of a project; after creating a project, no information about its archetype remains. Type of project - on the contrary, part of the model that is used throughout the life cycle.

What is the total

So we identified the three pillars of the Maven. What do they give us together?

• Concentration of information about the module in one place and in one format. Not everything is smooth here, but many IDEs can import projects from POM, most auto-compilation servers (continuous integration, as XP adepts say) can also use them to add a project.
• Unified identification system modules. Very simple and very important. We do not have now the designations of the type of bugfix-branch of our super-project, collected at 23 o'clock last Saturday.
• One tool. Although this, frankly, is not a unique feature of Maven. I will not restrain myself and repeat the common truth: the project must be assembled by standard and portable means. Build your favorite IDE First Developer Project - the path to hell.
• Automatic dependency management. Linking a project's source code with binary builds of something is a very fun practice. Of particular note is the difficulty with maintaining source repositories (how many tapes does your svn backup take?))). The inventions of the bicycle in the form of their repositories or scripts that pull source dependencies are also not the best solution in an era when spacecraft travel through the universe .
• Reuse of solutions related to the device and the project assembly procedure. Due to the inheritance and inclusion of projects, we can reuse once developed project models, settings related to infrastructure and tools adopted in our company. The use of archetypes allows you to automate the stage of creating new projects, save time on preparing the project structure and minimize errors in the use of external models.
• A ready tool for managing the results of work and ease of their subsequent use. We set up the infrastructure in an appropriate way and each build settles in the right place and is available for future use. Need to check the performance of different layouts of versions / branches of large project modules? Just rule dependencies in the POM.

Conclusion

Something I sometimes deviated from the central question and came to grips with the question of "how", but oh well ...

From all the information above, we can make a simple, but for some reason, very rare conclusion. Maven is not a utility for building Java applications. Maven is a framework for automating a wide range of tasks with project support. He has no connection with the language and platform, moreover, he is absolutely not obliged to collect anything. You use model description or writing plug-ins to turn it into a particular tool. Yes, the default model adopted by it is the assembly of Java modules, but these are only defaults ...

I hope that after reading the topic, everyone can confidently answer the questions given at the beginning;)

PS I’m also interested in learning about your experience with the non-standard use of Maven. There is an idea in the future to create a post with examples of interesting and unusual use cases for it.