Maven pom.xml: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
No edit summary
 
(32 intermediate revisions by the same user not shown)
Line 8: Line 8:


=Overview=
=Overview=
A POM file is a Maven-specific project metadata document.


<project> is the root element.
<project> is the root element.
Line 46: Line 48:


Optional. For more details about packaging, see [[Maven_Concepts#Classifier|Maven Concepts - Classifier]].
Optional. For more details about packaging, see [[Maven_Concepts#Classifier|Maven Concepts - Classifier]].
==<parent>==
<font color=darkgray>TODO</font>
For more details about project inheritance, see: {{Internal|Maven_Concepts#Project_Inheritance|Project Inheritance}}


==<name>==
==<name>==
Line 53: Line 61:
If specified, will be used in the "Reactor Summary" report, generated at the end of the build.
If specified, will be used in the "Reactor Summary" report, generated at the end of the build.


IntelliJ IDEA will use it as the project name, the text that will show up at the top of the editor window.
Conventionally, we will use something similar to "User-Friendly Name (projects-dir-name)". IntelliJ IDEA ''will NOT'' use it as the project name, so we will have to explicitly use the same value when creating the corresponding IntelliJ project.


See [[#.3CartifactId.3E|<artifactId>]] and [[Maven_Concepts#Name|Maven Concepts - Name]].
Also see [[#.3CartifactId.3E|<artifactId>]] and [[Maven_Concepts#Name|Maven Concepts - Name]].


==<properties>==
==<properties>==


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
<syntaxhighlight lang='xml'>
:[[Maven Custom System Properties]]
<project>
</blockquote>
  ...
  <properties>
    <some.property>something</some.property>
    <some.other.property>something else</some.other.property>
  </properties>
  ...
</syntaxhighlight>
 
Also see
{{Internal|Maven_Concepts#Set_in_the_.3Cproperties.3E_Elements|Maven Concepts - Variables}}
 
==<distributionManagement>==


<syntaxhighlight lang='xml'>
<project>
  ...
  <distributionManagement>
      <repository>
          <uniqueVersion>false</uniqueVersion>
          <id>novaordis-nexus</id>
          <name>NovaOrdis Nexus 3 OpenShift Repository</name>
          <url>https://maven.apps.openshift.novaordis.io/repository/maven-releases/</url>
        <layout>default</layout>
      </repository>
      <snapshotRepository>
          <uniqueVersion>true</uniqueVersion>
          <id>novaordis-nexus-snapshots</id>
          <url>https://maven.apps.openshift.novaordis.io/repository/maven-snapshots/</url>
          <layout>default</layout>
      </snapshotRepository>
  </distributionManagement>
  ...
</syntaxhighlight>


==<modules>==
==<modules>==
Line 87: Line 126:
</dependencyManagement>
</dependencyManagement>
</pre>
</pre>
==<servers>==
Declares [[Maven_Concepts#Servers|servers]]. The reason to use a <servers> element is mainly to specify sensitive credentials for a remote server, so it is not very common to use this element in a shared pom.xml. It is possible to encrypt the password with a master password that is only available locally, but it is far more common to specify credentials in a local settings.xml, as shown here:
{{Internal|Maven_settings.xml#.3Cservers.3E|<servers> element in settings.xml}}
==<repositories>==
Ideally, repositories should not be declared in pom.xml, but in [[Maven settings.xml|settings.xml]], as part of a [[Maven Profile|profile]]. However, there are situations when declaring repositories in pom.xml is acceptable. The syntax is:
<syntaxhighlight lang='xml'>
<project ...>
  ...
  <repositories>
      <repository>
          ...
      <repository>
      <repository>
          ...
      <repository>
  </repositories>
  ...
</project>
</syntaxhighlight>
where the syntax of the <repository> element is described here: [[Maven_Repositories#Elements|Maven Repositories]].


==<build>==
==<build>==
Line 134: Line 202:


===<plugins>===
===<plugins>===
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;">
:https://maven.apache.org/pom.html#Plugins<br>
</blockquote>
The <plugins> container specifies the list of plugins to be used for the current project, along with their configuration.


===<pluginManagement>===
===<pluginManagement>===
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;">
:https://maven.apache.org/pom.html#Plugin_Management<br>
</blockquote>
The <pluginManagement> container is also a list of plugins, similar to <plugins>, but rather than configuring plugin information for this specific project, it is intended to configure project builds that [[Maven_Concepts#Project_Inheritance|inherit]] from the POM that specifies it. When a plugin is configured in the parent POM <pluginManagement>, it can be referred from the child's <plugins>, recursively, by name and without any configuration. The reference, however, ''must'' exists in the child's <plugins> for the plugin to be associated with the child's build. The reference consists in the plugin's <groupId> and plugin's <artifactId>. Children can override the <pluginManagement> definitions.
Also see: {{Internal|Maven_Concepts#Project_Inheritance|Project Inheritance}}

Latest revision as of 23:34, 19 September 2018

External

Internal

Overview

A POM file is a Maven-specific project metadata document.

<project> is the root element.

Example

Simple pom.xml Example

Elements

<modelVersion>

Mandatory. Should be:

<modelVersion>4.0.0</modelVersion>

<groupId>

Mandatory. For more details about Group ID, see Maven Concepts - Group ID.

<artifactId>

Mandatory. For more details about Artifact ID, see Maven Concepts - Artifact ID.

<version>

Mandatory. For more details about Version, see Maven Concepts - Version.

<packaging>

Optional, the default value is "jar". For more details about packaging, see Maven Concepts - Packaging.

<classifier>

Optional. For more details about packaging, see Maven Concepts - Classifier.

<parent>

TODO

For more details about project inheritance, see:

Project Inheritance

<name>

Optional.

If specified, will be used in the "Reactor Summary" report, generated at the end of the build.

Conventionally, we will use something similar to "User-Friendly Name (projects-dir-name)". IntelliJ IDEA will NOT use it as the project name, so we will have to explicitly use the same value when creating the corresponding IntelliJ project.

Also see <artifactId> and Maven Concepts - Name.

<properties>

<project>
  ...
  <properties>
    <some.property>something</some.property>
    <some.other.property>something else</some.other.property>
  </properties>
  ...

Also see

Maven Concepts - Variables

<distributionManagement>

<project>
  ...
  <distributionManagement>
      <repository>
          <uniqueVersion>false</uniqueVersion>
          <id>novaordis-nexus</id>
          <name>NovaOrdis Nexus 3 OpenShift Repository</name>
          <url>https://maven.apps.openshift.novaordis.io/repository/maven-releases/</url>
         <layout>default</layout>
      </repository>
      <snapshotRepository>
          <uniqueVersion>true</uniqueVersion>
          <id>novaordis-nexus-snapshots</id>
          <url>https://maven.apps.openshift.novaordis.io/repository/maven-snapshots/</url>
          <layout>default</layout>
      </snapshotRepository>
  </distributionManagement>
  ...

<modules>

<dependencyManagement>

For more details about dependency management, see:

Dependency Management Concepts

Example:

<dependencyManagement>
    <dependencies>
        <dependency>
           <groupId>org.slf4j</groupId>
           <artifactId>slf4j-api</artifactId>
           <version>1.7.6</version>
        </dependency>
   </dependencies>
</dependencyManagement>

<servers>

Declares servers. The reason to use a <servers> element is mainly to specify sensitive credentials for a remote server, so it is not very common to use this element in a shared pom.xml. It is possible to encrypt the password with a master password that is only available locally, but it is far more common to specify credentials in a local settings.xml, as shown here:

<servers> element in settings.xml

<repositories>

Ideally, repositories should not be declared in pom.xml, but in settings.xml, as part of a profile. However, there are situations when declaring repositories in pom.xml is acceptable. The syntax is:

<project ...>

   ...
   <repositories>
       <repository>
          ...
       <repository>
       <repository>
          ...
       <repository>
   </repositories>
   ...

</project>

where the syntax of the <repository> element is described here: Maven Repositories.

<build>

<finalName>

<finalName> can be used to customize the name of the artifact. The value allows for system properties (standard or custom), as in the following examples:

<build>
    <finalName>simple-webapp</finalName>
</build>
<build>
    <finalName>${artifactId}</finalName>
</build>
<build>
    <finalName>archimedes-${project.version}</finalName>
</build>
<build>
    <finalName>${parent.artifactId}-${artifactId}</finalName>
</build>

finalName modifies the name of the artifact created in the local target directory of the project. However, irrespective of using finalName, Maven will still install conventionally named artifacts in the repository.

For more details on artifact name, see:

Artifact Name

For considerations of using <finalName> as part of an assembly plug-in configuration, see:

<finalName> and the assembly plugin

<plugins>

https://maven.apache.org/pom.html#Plugins

The <plugins> container specifies the list of plugins to be used for the current project, along with their configuration.

<pluginManagement>

https://maven.apache.org/pom.html#Plugin_Management

The <pluginManagement> container is also a list of plugins, similar to <plugins>, but rather than configuring plugin information for this specific project, it is intended to configure project builds that inherit from the POM that specifies it. When a plugin is configured in the parent POM <pluginManagement>, it can be referred from the child's <plugins>, recursively, by name and without any configuration. The reference, however, must exists in the child's <plugins> for the plugin to be associated with the child's build. The reference consists in the plugin's <groupId> and plugin's <artifactId>. Children can override the <pluginManagement> definitions.

Also see:

Project Inheritance