Maven is a building automation tool primarily used for Java projects.
Maven deals with two aspects of building software: first, describing how software is built, and secondly, it describes its dependencies. Unlike initial tools such as Apache Ant, it uses conventions for manufacturing procedures, and only exceptions need to be written. The XML file describes the software project being built, its dependencies on the modules and other external components, the order of manufacture, the directory, and the necessary plug-ins. It comes with a predetermined target for performing certain well-defined tasks such as code compilation and packaging.
Maven dynamically downloads Java libraries and Maven plug-ins from one or more repositories such as Maven 2 Central Repository, and stores them in the local cache. Local downloaded artifact cache can also be updated with artifacts created by local projects. Public repositories can also be updated.
Maven can also be used to build and manage projects written in C #, Ruby, Scala, and other languages. The Maven project is hosted by the Apache Software Foundation, which was previously part of the Jakarta Project.
Maven is built using a plugin-based architecture that allows it to use any application that can be controlled via standard input. Theoretically, this will allow anyone to write plugins to interface with build tools (compilers, unit test tools, etc.) for other languages. In fact, support and use for languages ​​other than Java is minimal. Currently plugins for.NET framework exist and are maintained, and the original C/C plugins are maintained for Maven 2.
Alternate technologies like Gradle and sbt as development tools do not depend on XML, but still keep the key concepts that Maven introduces. With Apache Ivy, a dedicated dependency manager is also developed which also supports the Maven repository.
Video Apache Maven
Contoh
The Maven project is configured using Project Object Model, which is stored in pom.xml -file. Here's an example:
This POM defines only the unique identifier for the project ( coordinates ) and its dependency on the JUnit framework. However, that is enough to build the project and run unit tests associated with the project. Maven completed this by embracing the idea of ​​the Convention on Configuration, that is, Maven provides default values ​​for project configuration.
The normal idiomatic Maven project directory structure has the following directory entry:
Then the command
will compile all Java files, run any test, and package the code and resources that can be submitted to target/my-app-1.0.jar (assuming artifactId is my-app and its version is 1.0.)
Using Maven, the user only provides configuration for the project, while the configurable plug-in does the actual job of compiling the project, cleans the target directory, runs unit tests, creates API documentation, and so on. In general, users do not need to write their own plugins. Compare this with Ant and create, where someone writes an important procedure for performing those tasks.
Maps Apache Maven
Drafts
Project Object Model
A Object Object Model (POM) provides all the configurations for a single project. The general configuration includes the name of the project, its owner and its dependence on other projects. One can also configure an individual phase of the build process, which is implemented as a plugin. For example, one can configure plugin-compilers to use Java version 1.5 for compilation, or specify project packaging even if some test units fail.
Larger projects should be divided into several modules, or subprojects, each with its own POM. One can then write a POM root through which one can compile all modules with one command. POM can also inherit configuration from other POM. All POMs inherit from Super POM by default. Super POM provides default configuration, such as the default source directory, default plugins, and so on.
Plugins
Most of the Maven functions are in plugins. The plugin provides a set of executable destinations using the following syntax:
For example, a Java project can be compiled with compiler-purpose plugins by running mvn compiler: compile .
There are Maven plugins to build, test, source control management, run web servers, create Eclipse project files, and more. Plugins are introduced and configured in & lt; plugins & gt; -section of the file pom.xml . Some basic plugins are included in each project by default, and they have reasonable default settings.
However, it will be complicated if the archetypical build order, testing and packing of required software projects run each of their individual objectives manually:
The Maven life cycle concept takes care of this issue.
Plugins are the main way to extend Maven. Developing Maven plugins can be done by extending the org.apache.maven.plugin.AbstractMojo class. Code and explanation examples for the Maven plugin to create a cloud-based virtual machine running the application server are provided in the Automation development and management article of the virtual cloud machine .
Build life cycle
Build lifecycle is a list of phases named that can be used to give commands to destination execution. One of the standard Maven life cycles is the default life cycle , which includes the following phases, in this order:
The purpose provided by the plugin can be attributed to various phases of the life cycle. For example, by default, the purpose of "compiler: compile" is associated with the "compile" phase, while the goal "isal: test" is associated with the "test" phase. Consider the following commands:
mvn test
When the previous command is executed, Maven runs all the goals associated with each phase up to and including the "test" phase. In such a case, Maven runs a "resource: resource" goal associated with the "resource-process" phase, then "compiler: compile", and so on until it finally runs a "definite: test" goal.
Maven also has a standard phase for cleaning projects and for generating project sites. If cleaning is part of the default life cycle, the project will be cleaned every time it is built. This is definitely not desirable, so cleaning has been given its own life cycle.
The standard life cycle allows new users to project to have the ability to precisely create, test, and install each Maven project by issuing a single command:
mvn install
By default, Maven packs the POM file in the generated JAR and WAR files. Tools like diet4j can use this information to resolve recursively and run Maven modules on-the-go without requiring "uber" -jar that contains all project code.
Dependencies
The main feature in Maven is dependency management. The Maven dependency handling mechanism is organized around a coordinate system that identifies individual artifacts such as libraries or software modules. Example of POM above JUnit coordinate reference as direct dependency of the project. A project that needs, say, Hibernate libraries should only state the coordinates of the Hibernate project in its POM. Maven will automatically download dependencies and dependencies that Hibernate itself requires (called transitive dependencies) and store them in the user's local repository. Maven 2 Central Repository is used by default to search libraries, but one can configure the repositories to be used (for example, private-company repositories) within the POM.
There are search engines like The Central Repository Search Engine that can be used to find coordinates for various open source libraries and frameworks.
Projects developed on one machine can depend on each other via a local repository. A local repository is a simple folder structure that works both as cache for downloaded dependencies and as centralized storage for locally created artifacts. The Maven command mvn install builds a project and places its binaries in the local repository. Then other projects can take advantage of this project by determining its coordinates on their POM.
Maven compared to Ant
The fundamental difference between Maven and Ant is that the Maven design assumes all projects have a specific structure and a set of tasks workflows supported (for example, getting resources from source control, compiling projects, unit testing, etc.). While most software projects basically support this operation and actually have well-defined structures, Maven requires that this structure and the details of the operations implementation be defined in the POM file. As such, Maven relies on conventions on how to define projects and workflow lists that are generally supported across all projects.
This design constraint resembles how IDE handles projects, and provides many benefits, such as concise project definitions, and possibly automatic integration of Maven projects with other development tools such as IDEs, build servers, etc.
But one drawback to this approach is that Maven requires users to first understand what the project from Maven's point of view is, and how Maven works with the project, because what happens when someone runs the phase in Maven is not immediately obvious just from checking the Maven project file. In many cases, this required structure is also a significant obstacle in the migration of mature projects to Maven, as it is usually difficult to adapt from other approaches.
In Ants, the project does not really exist from the technical perspective of the tool. Ants work with XML build scripts defined in one or more files. It processes the targets of these files and each target performs the task. Each task performs technical operations such as running the compiler or copying the files around. Targets are executed mainly in the order given by the dependencies specified on the other targets. Thus, Ant is a tool that unifies targets and executes them based on inter-dependencies and other Boolean conditions.
The benefits provided by Ant are also numerous. It has an XML language that is optimized for a clearer definition of what every task does and what it depends on. Also, all the information about what will be executed by the target ant can be found in Ant script.
A developer who is not familiar with Ant will usually be able to determine what is meant by a simple Ant script just by checking the script. This does not usually apply to Maven.
However, even the new experienced developers in projects using Ant can not deduce the high-level structure of the Ant script and what it does without checking the script in detail. Depending on the complexity of the script, this can quickly become a daunting challenge. With Maven, developers who previously worked with other Maven projects can quickly examine the structure of an unprecedented Maven project and run the standard Maven workflow against it while already knowing what to expect as a result.
It is possible to use Ant scripts that are defined and behave uniformly for all projects in workgroups or organizations. However, as the number and complexity of projects increase, it is also very easy to deviate from the original uniformity desired. With Maven, this is not a problem because the tool always implements a certain way of doing things.
Note that it is also possible to expand and configure Maven in a way that departs from the Maven way of doing things. This is especially true for Maven 2 and later releases, such as Mojos or more formally, plugins and custom project directory structures.
IDE Integration
Add-ons for some popular integrated development environments that target Java programming languages ​​exist to provide Maven integration with IDE development mechanisms and source editing tools, enabling Maven to compile projects from inside the IDE, as well as to set the classpath for code completion, highlight compiler errors, etc. Examples of popular IDEs that support development with Maven include:
- Eclipse
- NetBeans
- IDEA IntelliJ
- JBuilder
- JDeveloper (version 11.1.2)
- MyEclipse
This add-on also provides the ability to edit POM or use POM to specify the full set of dependencies of projects directly inside the IDE.
Some IDE default features will be lost when the IDE no longer compiles. For example, Eclipse's JDT has the ability to recompile single java source files after editing. Many IDEs work with a flat set of projects rather than the folder hierarchies favored by Maven. This complicates the use of SCM systems in IDEs when using Maven.
History
Maven, created by Takari Jason van Zyl, started as an Apache Turbine subproject in 2002. In 2003, he was selected and accepted as a top-level Apache Software Foundation project. In July 2004, the Maven release was the first critical milestone, v1.0. Maven 2 was announced v2.0 in October 2005 after about six months in the beta cycle. Maven 3.0 was released in October 2010 as it is mostly compatible with Maven 2.
Maven 3
Maven 3.0 information started out in 2008. After eight alpha releases, the first beta version of Maven 3.0 was released in April 2010. Maven 3.0 has reworked the main infrastructure of Project Builder that generates POM file-based representations separated from memory object representations. This has expanded the possibilities for the Maven 3.0 plugin to utilize non-XML-based project definition files. Recommended languages ​​include Ruby (already in private prototype by Jason van Zyl), YAML, and Groovy.
Special attention is given to ensuring Maven 3 compatibility to Maven 2. For most projects, upgrades to Maven 3 will not require adjustment of their project structure. The first beta of Maven 3 looks at the introduction of a parallel build feature that utilizes the number of cores that can be configured on multi-core machines and is perfect for large multi-module projects.
See also
- Apache Ant, an alternative dependency management tool for Java
- Apache Continuum, integrated server integration with Maven
- Apache Jelly, a tool for converting XML into executable code
- Apache Ivy, an alternative dependency management tool for Java
- Gradle, builder tool based on conventions over configuration
- Hudson
- Jenkins
- List of building automation software
References
Further reading
External links
- Official website
Source of the article : Wikipedia
0 Comments