Based on Maven pom file usage analysis

project

Maven is a powerful build and dependency management tool. Files are the core configuration files of Maven projects, used to define project construction, dependencies, plug-ins, goals, etc. It is the basis of the Maven build process, and all build configurations need to be defined in this file.

The project element represents the entire Maven project and is the outermost element in the POM file.

A complete file roughly includes the following parts:

• Project basic information
• Organization and License Information
• Custom attribute information
• Module configuration
• Project dependency configuration
• Maven relies on repository information
• Maven plug-in warehouse information
• Build configuration
• Version control information
• Distribute information
• Report configuration
• Environment configuration

Sub-element classification

Project basic information

- parent

The parent element is used to define the parent project information of the current project, that is, which module the module where the current project is located inherits from. Information that can be inherited includes but is not limited to: dependencies, plugins, build, reporting, etc. It is often used in situations where many modules in a project have common configuration.

Through the parent element inheriting attributes from the parent POM file, the child module can reuse the configurations and elements defined in the parent component, etc., while also facilitating the child module to modify and overwrite the inherited content.

• A complete parent element should contain at least two required child elements: groupId and artifactId, which represent the groupId and artifactId of the parent project respectively.
• In addition, you can also use the version element to specify the version number of the parent project. If the version is omitted, Maven automatically searches the local and remote repositories for the latest version.

Maven first looks for the local repository, and then goes to the central repository to download the specified parent artifactId and groupId POM files. By inheriting the parent POM file, you can avoid repeatedly defining the same attributes in the submodule.

property:

• groupId: GroupId of the parent project.
• artifactId: ArtifactId of the parent project.
• version: Defines the version number inherited from the parent.
• relativePath: Provides an optional relative path to determine the location of the parent POM. When this element is undefined, searches from local repositories and Maven central repositories by default.

Restrictions on inheriting parent:

• Using inheritance hierarchy as a central library is not a good design choice when publishing your own projects. While it would be more convenient to do so, it forces many restrictions.
• If you rely on a library and find that the library does not define some configuration information you need, you can solve the problem by independently defining a parent (adjust the corresponding part) point.
• If the managed version in the parent of a library does not meet the latest criteria and you cannot notify the author of the project to update its parent, in this case, you can also independently define a POM file and inherit from the desired target.

Example:

<parent>
    <groupId></groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.6.3</version>
    <relativePath/>
</parent>

- modelVersion

The modelVersion element specifies the version number of the current POM file and is used to identify the Maven model version used by the current POM. If the element is not explicitly defined and the current POM file is created based on version 4.0.0 or later, it will default to version 4.0.0.

ModelVersion can only use the version number supported by Maven. Once the version number is determined, you should always use the same version number unless you have a good reason to upgrade it. Also, if you want backwards compatible with other versions of POM files, you can keep the old version and add new attributes instead of updating existing elements.

Example:

<modelVersion>4.0.0</modelVersion>

- groupId

The groupId element defines a unique identifier for the organization or company to which the project belongs. It is the globally unique ID of the Maven project and is used to identify projects and dependencies in the repository.

Typically, groupId recommends prefixing the domain name of the organization or company, which avoids namespace conflicts.

• The value of groupId should not contain spaces or other special characters, and it is recommended to use lowercase letters and hyphens as separators between words.
• The groupId element should be specified explicitly in the POM file and once specified, it should not change throughout the project, otherwise it may cause various different problems.
• maven is case sensitive to groupId. Therefore, in different modules of the same project, if groupId is written in different cases, it may cause the construction of the dependent module to fail. Therefore, it is recommended to maintain groupId consistency throughout the project.

Example:

<groupId></groupId>

- artifactId

The artifactId element refers to the unique identifier of the current Maven project, which is used to represent the currently built project.

The artifactId element can also allow other dependencies to refer to the project POM file that it is used as a dependency.

If project B needs to rely on project A's jar package, you need to configure the coordinates of project A (groupId, artifactId, version), and Maven will retrieve and download project A's jar package to meet project B's dependencies.

Example:

<artifactId>my-project</artifactId>

- name

The name element defines the project name. This element is an optional option, but it is highly recommended to use it in each POM to describe the current project in order to make it easier to understand and identify the role of the project. This property will also be used frequently in other places such as Maven lifecycle, plug-ins, etc.

It should be noted that when used in IDE or other Maven tools, the name element can help users identify and distinguish different modules, and help users quickly find documents or other related information.

Example:

<name>My App Name</name>

- version

The version element represents the version number of the current project, which is used to uniquely identify the project and manage dependencies.

In Maven, there are usually three types of version numbers:

• SNAPSHOT: The development version means that it is still in the development process and will be updated continuously as the development progresses;
• RELEASE: A stable version, which means that the development work has been completed and can be officially released and used;
• Other custom version numbers: Specify them according to specific needs.

The version element can be defined in the following locations:

• Version element in external parent POM file: If you are using an external parent POM to manage the project, the version number can be defined from there.
• Version element of the project itself: If you are not using an external parent POM, you can define the version number in the project itself file.
• Version element in dependencies: The version number can also be specified in the project's dependencies. The highest priority is the version number specified directly in the dependency, followed by the version number inherited from the parent POM file and the project itself defined.

Example:

<version>1.0-SNAPSHOT</version>

- packaging

The packaging element specifies the type of project packaging.

Optional values ​​for packaging:

• jar: Packed in JAR form, default value
• war: Package in the form of a web application
• ear: Package as Enterprise application
• pom: Only exists as a dependency, no output file is generated

Maven will package the project according to the type specified by the package element and save the output to the target directory (default is the target directory).

- description

The description element is used to describe a brief description of the item. The description element does not affect the construction and deployment process of the project, but only exists as additional information for a text description.

Typically, the description element is immediately following the groupId, artifactId, and version elements and is located at the top of the file.

Example:

<description>This project description</description>

- url

The url element is used to specify the URL address of the project. This element is usually used to specify the project homepage, document location, or address of the source code repository, etc.

Example:

<url>/username/projectname</url>

- inceptionYear

The inceptionYear element represents the year the project was created.

Example:

<inceptionYear>2010</inceptionYear>

Organization and License Information

- organization

The organization element represents the organization information to which the project belongs.

This element is optional and is mainly used to identify the relevant information of the organization to which the project belongs, such as the organization name, the organization URL, etc. If the organization element is specified, Maven uses this information to generate the default developer and organization elements.

Example:

<organization>
    <name>ACME Corporation</name>
    <url></url>
</organization>

- licenses

The licenses element is used to specify the license information related to the project.

This element usually contains multiple license elements, each license element corresponding to one license information.

Example:

<licenses>
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>/licenses/LICENSE-2.</url>
      <distribution>repo</distribution>
    </license>
    ...
</licenses>

- developers

The developers element is used to list the developers and their contact information for the project.

Typically, the developers element is immediately following the description element and is at the top of the file. The information provided by the developers element does not directly affect the project's construction and deployment process, but only exists as additional information described in text.

Example:

<developers>
  <developer>
    <id>john_doe</id>
    <name>John Doe</name>
    <email>@</email>
  </developer>
  <developer>
    <id>jane_doe</id>
    <name>Jane Doe</name>
    <email>@</email>
  </developer>
</developers>

- contributors

The contributors element can be used to enumerate a list of contributors for the project. An element can contain multiple contributor elements.

Each contributor element should contain at least the name element used to specify the contributor's name or nickname, optionally, it can also include child elements such as email, url, and organization to provide more detailed contributor information.

Example:

<contributors>
    <contributor>
      <name>John Doe</name>
      <email>johndoe@</email>
      <url></url>
      <organization>Acme Organization</organization>
      <organizationUrl></organizationUrl>
    </contributor>
    <contributor>
      <name>Jane Smith</name>
    </contributor>
  </contributors>

- mailingLists

The mailingLists element is used to specify the mailing list information related to the project. This element usually contains multiple mailingList elements, each mailingList element corresponding to a mailing list information.

Typically, the mailingLists element follows the developers element and is at the top of the file. The information provided by the mailingLists element does not directly affect the project's construction and deployment process, but only exists as additional information for a text description.

Example:

<mailingLists>
  <mailingList>
    <name>Developers List</name>
    <subscribe>dev-subscribe@</subscribe>
    <unsubscribe>dev-unsubscribe@</unsubscribe>
    <post>dev-post@</post>
    <archive>/mailman/private/dev-list/</archive>
  </mailingList>
</mailingLists>

Custom attribute information

- properties

The properties element is used to define some constant values ​​that can be repeatedly referenced in the POM and its subprojects. This element usually contains various key-value pairs, where the key represents the name of the attribute and the value represents the constant value represented by the attribute.

It should be noted that the definition of properties elements is simply a declaration or assignment of properties, and does not define what purpose these properties are used for. The exact use of attributes depends on the actual situation.

Example:

<properties>
  <>UTF-8</>
</properties>

In addition, Maven has many built-in properties.

Maven built-in properties:

Module configuration

- modules

The modules element is used to specify a list of submodules for a multi-module project. Can contain multiple module elements.

Each module element should contain only one child element: a directory name or relative path (default relative to the parent project's file). When using the mvn command to execute a multi-module project, Maven will build based on the submodules listed in the modules element.

Example:

<modules>
    <module>module-a</module>
    <module>module-b</module>
    <module>module-c</module>
  </modules>

Project dependency configuration

- dependencyManagement

The dependencyManagement element provides a mechanism for centralized management of dependency version numbers. This element contains various child elements that specify the various dependencies and their versions used by the project.

Example:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.1</version>
      <scope>test</scope>
    </dependency>
    <!-- ... -->
  </dependencies>
</dependencyManagement>

It should be noted that the dependency declaration in the dependencyManagement element is not used directly in the project. It only defines the version and related configuration information for inheritance and use by other modules of the project.

- dependencies

The dependencies element is used to list the external libraries that the project depends on, which is called "dependencies". This element can contain multiple dependency elements.

dependency element:

• A complete dependency element should include at least three necessary child elements: groupId, artifactId and version.
• When building a project using Maven, it automatically downloads the corresponding dependency package from the repository to the local repository based on these elements.

The child elements of dependency:

• groupId: The unique identifier of the organization or company to which the dependency belongs.
• artifactId: The name of the dependency, usually consisting of the project name and the module name.
• version: The version number of the dependency.
• scope: The scope of the dependency, optional values ​​include compile, provided, runtime, test, etc.
• type: The type of dependency, default is jar.
• classifier: used to distinguish between different build versions under the same artifactId and version.
• optional: Specifies whether to pass the dependency to the project's dependency.
• Exclusions: Used to exclude a transitive dependency.

Example:

<dependencies>
    <dependency>
      <groupId></groupId>
      <artifactId>spring-core</artifactId>
      <version>5.2.</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

Maven relies on repository information

- repositories

The repositories element is used to define where the project dependency is downloaded from and the order in which the project dependency is downloaded. This element mainly contains a set of child elements used to specify various resource libraries. This element can contain multiple repository elements.

Repository element:

The repository element is used to specify the remote repository information of the Maven project. The repository element should contain at least one id, name and url child element.

• id: Repository ID, used to uniquely identify the repository.
• name: The name of the warehouse, used to describe the warehouse.
• url: repository URL, pointing to the remote repository address where the dependencies are stored.

In most cases, Maven automatically downloads the required dependencies because it is able to find these dependencies from the local repository. Of course, if a dependency needs to be downloaded from a remote repository, then you need to configure these repositories first.

Example:

<repositories>
  <repository>
    <id>central</id>
    <url>/maven2/</url>
  </repository>
  <repository>
    <id>jboss</id>
    <name>JBoss Repository</name>
    <url>/nexus/content/groups/public/</url>
  </repository>
  <repository>
    <id>snapshots</id>
    <name>Maven Snapshots</name>
    <url>/content/repositories/snapshots/</url>
    <releases>
      <enabled>false</enabled>
    </releases>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
  </repository>
</repositories>

Use maven central repository as the main software library and add two other external repositories

• The first repository element specifies the default central repository.
• The second repository element is a JBoss library that has only metadata (pom) and will not be able to download the package.
• The third repository element is a Sonatype snapshot library that configures disable release version and enable snapshot version support.

It should be noted that the library does not have to be redefined in every file. In fact, you can define multiple public libraries (central, jcenter, etc.) in the Maven file, and the project will inherit these defined libraries.

Maven plug-in warehouse information

- pluginRepositories

The pluginRepositories element is used to define where to download plugins (plugins) used in the project and the order of downloading.

Very similar to the repositories element, pluginRepositories mainly contains a set of child elements used to specify various plug-in resource libraries. This element can contain multiple pluginRepository elements.

pluginRepository element:

The pluginRepository element is similar to the function in the repository element. The pluginRepository element is used to specify the location of the Maven plugin library. The pluginRepository element can contain the following child elements:

• id: Plugin repository ID, used to uniquely identify the repository.
• name: The name of the plug-in repository, which is used to describe the repository.
• url: Plugin repository URL, pointing to the remote repository address of the storage plugin.

Example:

<pluginRepositories>
  <pluginRepository>
    <id>central</id>
    <url>/maven2/</url>
  </pluginRepository>
  <pluginRepository>
    <id>jboss</id>
    <name>JBoss Repository</name>
    <url>/nexus/content/groups/public/</url>
  </pluginRepository>
  <pluginRepository>
    <id>snapshots</id>
    <name>Maven Snapshots</name>
    <url>/content/repositories/snapshots/</url>
    <releases>
      <enabled>false</enabled>
    </releases>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
  </pluginRepository>
</pluginRepositories>

Use maven central repository as the main plugin library and add external plugin library

• The first pluginRepository element specifies the default central repository.
• The second pluginRepository element is a JBoss library that has only metadata (pom) and will not be able to download the package.
• The third pluginRepository element is a Sonatype snapshot library that configures disable release version and enable snapshot version support.

It should be noted that, likewise, there is no need to redefine the plugin library in every file. You can define multiple public libraries (central, jcenter, etc.) in the Maven file, and the project will inherit these defined libraries.

Build configuration

- build

The build element is used to configure the build options of a project, mainly including plugins, resource files and other construction related information on the project. It can contain multiple child elements, such as plugins, resources, etc.

• plugins: Plugin-related configuration, specify plug-ins and plug-in content, for example:

  • plugin: Specify the specific plugin name.
    • groupId: The group ID where the plugin is located
    • artifactId: Plugin ID
    • version: plugin version number
    • executions: The configuration executed by the plug-in, defining the life cycle binding of the plug-in.
    • configuration: Specify the specific parameters and settings of the plug-in.

• resources: Used to specify the resource files used in the project, usually including attribute files, XML configuration files, Spring configuration files, etc.

  • resource: represents the main resource path of the project.
    • directory: The directory path where the resource file resides.
    • include: The path mode of the resource file included, supporting wildcard characters.
    • excludes: Excluded resource file path mode, supports wildcard characters.
    • filtering: Whether to filter the resource file (such as replacing the ${} placeholder). Default is false.
    • targetPath: Specifies the target path of the resource file in the build output directory.
    • encoding: How to encode the resource file. The default is platform-related encoding.
    • items: Specify one or more resource items to further define the behavior of the resource file.
    • nonFiltered: Specifies the resource file path mode that does not filter.

Example:

<build>
    <plugins>
      <plugin>
        <groupId></groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId></groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
    </plugins>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <includes>
          <include>**/*.properties</include>
          <include>**/*.xml</include>
        </includes>
      </resource>
    </resources>
  </build>

• Two plug-ins are defined: maven-compiler-plugin and spring-boot-maven-plugin, and the source and target code versions of maven-compiler-plugin are configured to be 1.8.
• Specifies that the .properties and .xml files in the src/main/resources directory are used as project resource files.

Version control information

- scm

The scm element is used to define the source code management (SCM) information of a project so that Maven can retrieve and build code from this repository.

A complete scm element should include at least two necessary child elements: connection and developerConnection, which respectively represent the connection between the developer and the version control library. In addition, SCM information can be further specified using other sub-elements such as url, tag, branch, etc.

Scm subelement:

• connection: The connection URL of the source code repository, used to obtain metadata from SCM.
• developerConnection: The connection URL used by developers to push code, usually private.
• url: An open source code repository access URL, usually used to view source code.
• tag: A tag in the source code repository, identifying a specific version.
• branch: The branch name in the source code repository, indicating the branch that was developed or released.
• commit: Specify a specific commit (hash) of the source code to ensure that the correct code is used when building.
• checkoutDirectory: The directory path for source code checkout, the default is the project root directory, and the specific path for checkout source code is specified.

Uses of SCM:

• By specifying the version control system information of the source code, other developers can more easily detect projects into the local environment and participate in project development.
• During project construction, Maven can leverage SCM configuration to automatically obtain source code from the version control system and build the project.
• By specifying the branch or tag information of the version control system, Maven can build specific versions of the project, which facilitates the release and deployment of the project.
• SCM configuration can also be used to specify the URL of the version control system so that Maven can automatically generate metadata such as build information and version numbers for the project, which is important for tracking and managing projects.

Example:

<scm>
  <connection>scm:git:git:///user/</connection>
  <developerConnection>scm:git:ssh:///user/</developerConnection>
  <url>/user/repo/tree/master</url>
  <tag>1.0.0</tag>
</scm>

In the above code, a Git-based source code management information is defined.

Among them, the connection element specifies the connection method to the code base through the https protocol, while the developerConnection element is connected through the ssh protocol. In addition, the URL of the code base (i.e. the homepage address) and the default tag used when tagging are specified.

Distribute information

- distributionManagement

• The distributionManagement element is used to manage where you deploy (or publish) after building. This element contains various child elements for specifying the distribution (or release) related configuration of the project.
• The distributionManagement element is only used to manage the deployment (or release) of the project's distribution version and does not affect the compilation and construction process of the project.

Example:

<distributionManagement>
  <repository>
    <id></id>
    <name>Internal Repository</name>
    <url>file:///usr/local/repo</url>
  </repository>
</distributionManagement>

In the example above, we declare a repository called "Internal Repository" with the address of the /usr/local/repo directory on the local file system.

Once this repository is defined, you can use the command mvn deploy to use the command mvn deploy to upload and deploy the project to the repository during the build process.

Report configuration

- reporting

The reporting element is used to generate some reports for the project, such as code coverage, static code analysis results, etc. This element can contain various child elements to configure which reports need to be generated and how to generate them.

The reporting element is only used to configure the relevant information of Maven to generate reports. It does not affect the compilation and construction process of the project, and the generated reports are usually analyzed and processed based on already built code.

Example:

<reporting>
  <plugins>
    <plugin>
      <groupId></groupId>
      <artifactId>jacoco-maven-plugin</artifactId>
      <version>0.8.6</version>
    </plugin>
    <plugin>
      <groupId></groupId>
      <artifactId>sonar-maven-plugin</artifactId>
      <version>3.9.0.2155</version>
    </plugin>
    <!-- ... -->
  </plugins>
</reporting>

In the example above, we define two plugins, namely Jacoco and SonarQube. By using these plugins, Maven can generate reports on code coverage, static code analysis. Other optional reporting plugins include FindBugs, Checkstyle, Javadoc, etc.

Environment configuration

- profiles

Profiles element is used to define one or more build "profiles". These configurations are different from the usual build options and can flexibly manage project configurations and dependencies in different build environments according to different environments, requirements, etc.

profile

A profile element can contain multiple child elements, such as id, activation, properties, dependencies, etc., and each child element can contain specific configuration information.

• id (name): Required, used to assign a name to the corresponding build configuration.
• activation: used to specify the conditions for triggering the profile, such as: system properties, JDK version, Maven version, operating system, etc.
• properties: defines the property value used in the profile. These properties can be referenced by other elements to use different values ​​in different environments.
• dependencies: Specify the dependencies related to the profile. These dependencies are added to the project only when the profile is activated.
• dependencyManagement: Similar to dependencies, but it only defines the dependency version number and does not introduce actual dependencies.
• build: used to define build settings related to profiles, such as compiler version, packaging method, etc.
• reporting: Specifies the plug-ins and configurations used when generating reports.
• modules: Define specific modules that are built only when the profile is activated.
• repositories: Specify the repository configuration related to the profile.

After you have defined Profile elements in your POM file, you can activate or disable them according to the desired build environment.

To activate the Profile element, you can use command line options, environment variables, or other Maven plugins to specify the required Profile. For example, using the "-P production" command can activate a POM file containing the "production" Profile.

Example:

<profiles>
    <profile>
      <id>development</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <></>
      </properties>
      <dependencies>
        <dependency>
          <groupId>mysql</groupId>
          <artifactId>mysql-connector-java</artifactId>
          <version>8.0.23</version>
        </dependency>
      </dependencies>
    </profile>
  </profiles>

In the above code, a build configuration named development is defined, and the condition for starting this configuration is activated by default (activeByDefault). This configuration uses the MySQL driver as a dependency and sets the property value to use the correct database connection driver in the development environment.

Summarize

The above is personal experience. I hope you can give you a reference and I hope you can support me more.