Apache Maven

Maven is a build management tool from the Apache Software Foundation and is based on Java. With it you can create particular standardized Java programs and manage.

The name Maven comes from the Yiddish word meaning " collector of knowledge".

• 3.1 Create a software project
• 3.2 Support for the development environment
• 3.3 Create a quality report with PMD

Conceptual

Maven tries, the basic idea of ​​" convention over configuration " (English Convention over Configuration ) consistently represent for the entire cycle of software creation. Here are software developers are supported by the system of a software project about compiling, testing and " packing" to distribute the software to use computers so that as many steps can be automated. Following this the default Maven standards, you need for most tasks the build management to deposit very few configuration settings to reflect the life cycle of a software project.

The default lifecycle

Maven is based on a cycle that is run frequently when designing the software. It is not assumed that each software project uses all phases of the cycle shown in the following:

• Archetype ( Scaffolding ): This can be a template for a software project can be created. Dependencies are resolved and downloaded as needed.
• Validate ( Validation ): Here it is checked whether the project structure is valid and complete.
• Compile ( compile ): In this phase, the source code is compiled.
• Test ( Test ): The compiled code is tested with a suitable testing framework. Maven taken into account in later cycles that test classes are not normally present in the software to be delivered.
• Package ( packaging): The compilation is - possibly with other nichtkompilierbaren files - packaged for distribution. Frequently, this is a jar file.
• Integration test ( test the possibility of integration ): The software package is downloaded to an environment ( another computer, another directory, application server) and its functionality tested.
• Verify ( validation of the software package ): checks whether the software package has a valid structure and possibly with certain quality criteria.
• Install ( Install in the local Maven repository ): Install the software package to the local Maven repository to use it in other projects that are managed by Maven. This is particularly interesting for modular projects.
• Deploy ( install in remote Maven repository ): Stable releases of the software to be installed on a remote Maven repository, and are thus in environments with multiple developers available to all.

This life cycle can be extended still substantially by Maven plugins and Maven archetypes (English Archetypes ). With Maven Archetypes frameworks for a variety of software projects can be created that correspond to the standard structure of Maven.

Maven plugins allow new processing steps to use (eg distribution on an application server ) and / or the steps in the standard life cycle to expand.

The configuration file: pom.xml

Normally, the information for a software project, which is supported by Maven, in an XML file with the filename pom.xml are stored ( for Project Object Model). This file contains all information about the software project and follows a standardized format. When Maven runs, it first checks whether this file contains all the necessary information and whether the information provided is syntactically valid, before it continues to work.

Default directory structure

An essential element of the principle of Convention over Configuration is the default directory structure of Maven. If a project adheres to it, the path name must not be specified what the main configuration file pom.xml greatly simplified. At the highest level, there are two directories src and target. src contains all the files that serve as input to the manufacturing process and target all the files you create will appear. Even more directory levels are standardized and plugins that handle new types of input files or create new types of output files, give it before default paths.

The following structure shows some of the major directories.

• Src: all input files src / main: Input files for creating the actual product src / main / java: Java source code
• Src / main / resources: other files that are required for translation or at run time, such as Java properties files

• Src / test / java: JUnit test cases for automated testing

• Target / classes: compiled Java classes

Dependency resolution, centralized repositories

In the pom.xml software dependencies are specified, which has a supported Maven software project to other software projects. These dependencies are resolved by Maven first determined whether the required files are already available in a local directory, the local Maven repository. If they are, using Maven for example, when compiling the locally existing file from there, ie without copying it to the project directory.

Can not be resolved locally dependency, Maven tries to connect to a configured Maven repository on the intranet or Internet, and then copy them from the files in the local repository to use it locally from now on can. Known public Maven repositories are Apache, Ibiblio, Codehaus or Java.Net. Company-wide via the intranet addressable Maven repositories are used to provide self-developed or purchased libraries and frameworks across the company all projects. These repositories are typically implemented using software such as Apache Archiva, Nexus, Artifactory, Proximity, Codehaus Maven proxy or Dead Simple Maven proxy.

Customizability

Almost all specifications, which makes Maven can be changed individually, except for the structure of the project file ( pom.xml ): You can choose different project paths, compilers for other languages ​​use (if plugins support ).

Support in development environments

For the most popular development environments (such as Eclipse, IntelliJ IDEA or NetBeans ) are plugins available over which you can operate directly from the development environment Maven. In addition, Maven plug-ins are available that produce files which allow the import of a pure Maven project in the development environment (see examples).

Subprojects

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

Design

Maven is based on a plugin architecture, which allows plugins for different applications ( compile, test, build, deploy, checkstyle, pmd, scp transfer) applied to the project without having to install it explicitly. The number of plugins is now very extensive: They range from plugins that allow you to launch directly from Maven out a web application to test it in the browser, what that make it possible to test databases or to create, to to ones that generate Web services. The necessary activities are often limited only on identifying the desired plug-in and use.

Examples

The following examples can be run after installation. Maven is the first time you run the specified command try several files to load ( "artifacts" ) from the Internet or a local repository.

Create a software project

Input Enter at the command line:

Mvn archetype: generate- DgroupId = - DartifactId = my - org.beispielurl application result A sub-directory my - application- is created in the current directory. This directory can be found next to the pom.xml file (see above) directories that match the default directory structure of Maven.

Support for the development environment

After a Maven project is created, you want this in a development environment ( here: Eclipse) to continue editing. At the command line, change to the root directory of the project.

Input

Mvn eclipse: eclipse result

.. Files project and classpath are - pom.xml depends on the settings in the file - generated. The project can now import it into Eclipse. If a corresponding Eclipse plugin available, for more dependencies to Maven artifacts can also be added through 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 software PMD is loaded from the Internet, the project will be analyzed and a report page is created.

Revision history

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

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

Maven 1.x is no longer being developed and is limited to support and bug fixes. The latest version of Maven 1.x ( version 1.1) was delivered on 25 June 2007.

The development of Maven 3.0 began in 2008. According eight alpha releases, the first beta release of Maven 3.0 in April 2010 has been published. Particular attention was paid to the compatibility between Maven 2 and 3