Apache Maven

from Wikipedia, the free encyclopedia
Apache Maven

logo
Basic data

developer Apache Software Foundation
Publishing year March 30, 2002
(Version 1.0-beta-2)
Current  version 3.6.1
( April 4, 2019 )
operating system cross-platform
programming language Java
category Build management tool
License Apache license 2.0
maven.apache.org

Maven is a build management tool from the Apache Software Foundation and is based on Java . In particular, it can be used to create and manage Java programs in a standardized manner.

The name Maven comes from Yiddish and means something like "collector of knowledge".

Conceptual

Maven tried the basic idea " convention over configuration " (English Convention over Configuration ) consistently mapped for the entire cycle of software development. The aim is to support software developers from setting up a software project to compiling, testing and “packing” to distributing the software on application computers so that as many steps as possible can be automated. If you follow the standards specified by Maven, you only need to store very few configuration settings for most build management tasks in order to map the life cycle of a software project.

The standard life cycle

The Maven standard lifecycle consists of clean (to delete the target directory), default or build to carry out the phases mentioned below, and site to compile websites that serve as project documentation. In contrast to the clean and site cycle, which are already linked to preconfigured plug-ins , the default (build) cycle does not have a preconfigured plug-in. Maven assumes a cycle that is run through frequently when creating software. It is not assumed that every software project uses all phases of the default cycle shown below:

  • archetype ( scaffolding ): This can be used tocreatea template for a software project. Dependencies are resolved and downloaded if necessary.
  • validate : This checks whether the project structure is valid and complete.
  • compile : In this phase the source code is compiled.
  • test : Here the compiled code is tested with a suitable test framework. In later cycles, Maven takes into account that test classes are usually not available in the software to be delivered.
  • package : The compilation is packaged - possibly with other non-compilable files - for distribution. Often it is a Jar file.
  • integration-test (test of the possibility of integration): The software package is loaded onto an environment (different computer, different directory, application server) and its functionality is checked.
  • verify (validity check of the software package): Checks whether the software package has a valid structure and, if applicable, fulfills certain quality criteria.
  • install (install in local Maven repository): Install the software package in the local Maven repository so that it can be used in other projects that Maven manages. This is particularly important for modular projects.
  • deploy (installation in the remote Maven repository): Stable versions of the software are installed on a remote Maven repository and are therefore available to everyone in environments with several developers.

This life cycle may still substantially by Maven plugin and Maven archetypes (Engl. Archetypes ) be extended. Maven archetypes can be used to create frameworks for a wide variety of software projects that correspond to the standard structure of Maven.

Maven plug-ins make it possible to use new processing steps (e.g. distribution to an application server) and / or to extend the steps in the standard life cycle.

The configuration file: pom.xml

Normally, the information is for a software project, which is supported by Maven in an XML file with the file name pom.xml (for P roject O bject M odel saved). This file contains all information about the software project and follows a standardized format. If Maven is executed, it first checks whether this file contains all the necessary information and whether all information is syntactically valid before it continues to work.

Standard directory structure

An essential element of the Convention over Configuration principle is the standard Maven directory structure. If a project adheres to this, the path names do not have to be specified, which greatly simplifies the central configuration file pom.xml . At the top level there are two directories, src and target . src contains all files that serve as input for the processing process and all files generated are automatically stored in target . Other directory levels are also standardized and plug-ins that process new types of input files or generate new types of output files provide standard paths for this.

The following structure shows some of the most important directories.

  • src : all input files
    • src / main : input files for creating the actual product
    • src / test : input files that are required for automated test runs
      • src / test / java : JUnit test cases for automated tests
  • target : all generated files
    • target / classes : compiled Java classes

Resolution of dependencies, central repositories

The pom.xml specifies software dependencies that a software project supported by Maven has on other software projects. These dependencies are resolved in that Maven first determines whether the required files already exist in a local directory, the local Maven repository. If they are, Maven uses e.g. B. when compiling the locally available file from there, i.e. without copying it into the project directory.

If the dependency cannot be resolved locally, Maven tries to connect to a configured Maven repository on the intranet or the Internet and from there to copy the files to the local repository so that they can be used locally from now on. Well-known public Maven repositories are Apache, Ibiblio, Codehaus or Java.Net. Company-wide Maven repositories, which can be accessed via the intranet, are used to make libraries and frameworks that have been developed or purchased in-house available for all projects throughout the company. These repositories are usually implemented using software such as Apache Archiva , Nexus, Artifactory, Proximity, Codehaus Maven Proxy or Dead Simple Maven Proxy.

Customizability

Almost all specifications that Maven makes can be changed individually, except for the structure of the project file ( pom.xml ): You can choose different project paths or, for example, use compilers for other languages ​​(if supported by plug-ins).

Support in development environments

Plug-ins are available for the most common development environments (e.g. Eclipse , IntelliJ IDEA or NetBeans ), with which Maven can be operated directly from the development environment. In addition, Maven plug-ins are available that generate files that enable importing a pure Maven project into the development environment (see also examples ).

Sub-projects

The development of Maven is divided into different sub-projects.

  • Maven 1 and Maven 2 have stopped being developed since February 2014.
  • Maven 3 represents the current development branch of core development.
  • Plugins develops most of the Maven plugins.
  • Shared Components provides software components that can be used by the other sub-projects.
  • Ant Tasks makes it possible to use Maven functionality from Ant scripts.
  • Doxia is a framework for generating content from the formats Almost Plain Text (APT), Confluence , DocBook , FML (FAQ Markup Language), LaTeX , Markdown , Rich Text Format (RTF), TWiki , XDoc and XHTML .
  • SCM (Source Code Management) develops software for connecting Apache to various version management systems such as CVS or Subversion .
  • Surefire is developing a test framework for Maven.
  • Wagon provides an abstraction layer for communication protocols such as "file access", HTTP or FTP .

design

Maven is based on a plug-in architecture that enables plug-ins for various applications ( compile, test, build, deploy, checkstyle , pmd , scp-transfer ) to be applied to the project without having to install them explicitly. The number of plug-ins is now very extensive: The bandwidth ranges from plug-ins that allow a web application to be started directly from Maven in order to test it in the browser, via which it is possible to test databases or to those that generate web services. The activities required for this are often limited to determining and using the desired plug-in.

Examples

The following examples can be run after installation. Maven will attempt to load various files ("artifacts") from the Internet or a local repository the first time the specified commands are executed.

Create a software project

Input Enter
on the command line: 

mvn archetype:generate -DgroupId=org.beispielurl -DartifactId=meine-anwendung

Result
A subdirectory my-application is created in the current directory. This directory contains the pom.xml file (see above) and directories that correspond to the standard Maven directory structure.

Support for the development environment

After a Maven project has been created, you want to work on it in a development environment (here: Eclipse ). On the command line you change to the root directory of the project.

input 

mvn eclipse:eclipse

Result

The files .project and .classpath are created - depending on the settings in the pom.xml file . The project can now be imported into Eclipse. If a corresponding Eclipse plug-in is available, further dependencies on Maven artifacts can also be added via the graphical user interface.

Create a quality report with PMD

Input Enter
in the root directory of the software project: 

 mvn pmd:pmd

Result
The PMD software is loaded from the Internet, the project is analyzed and a report page is created automatically.

history

The first version, Maven 1.x, was introduced in 2003 and completed on July 13, 2004 as version 1.0. However, the implementation happened very quickly, so that some peculiarities were not considered. For example, there were performance problems and too many configuration files and information.

Therefore the concept was revised and since 2005 started to develop Maven 2.x in parallel, version 2.0 of which was completed on October 19, 2005.

Maven 3.x began development in 2008. Maven 3.0 was released on October 8, 2010. Particular attention was paid to the compatibility between Maven 2 and 3.

On February 18, 2014, Maven 1.x announced the End of Life. The last published version is Maven 1.1 from June 25, 2007.

On February 18, 2014, Maven 2.x announced the End of Life. The last published version is Maven 2.2.1 from November 2009.

See also

literature

  • Vincent Massol, Jason van Zyl, Brett Porter, John Casey, Carlos Sanchez: Better Builds with Maven . How-to Guide for Maven 2.0. Ed .: Exist Global. August 2007 ( wisc.edu [PDF]).
  • Tim O'Brien, Jason van Zyl, Brian Fox, John Casey, Juven Xu, Thomas Locher: Maven: By Example . An Introduction to Apache Maven. Ed .: Sonatype. Mountain View, California 2010, ISBN 978-0-9842433-3-4 ( sonatype.com ).
  • Tim O'Brien, Jason van Zyl, Brian Fox, John Casey, Juven Xu, Thomas Locher: Maven: The Complete Reference . Ed .: Sonatype. Mountain View, California 2010, ISBN 978-0-9842433-4-1 ( sonatype.com ).

Web links

Individual evidence

  1. ↑ Maven 3.6.1 - Announce .
  2. ↑ Release Notes - Maven 3.6.1 .
  3. ↑ What is Maven? maven.apache.org
  4. ^ Maven - Introduction to the Standard Directory Layout. In: Apache Maven Project. Retrieved July 13, 2009 .
  5. ↑ a b c Maven Releases History. In: maven.apache.org. Retrieved December 21, 2015 .
  6. ↑ Historical archive of Maven versions
  7. ↑ Maven 1.x homepage with reference to Maven 2 ( Memento from February 15, 2012 in the Internet Archive )