Maven's role is as follows:
- Maven manages all dependent packages in a unified and centralized manner, and programmers do not need to look for them.
- Corresponding to the common jar s used by third-party components, Maven automatically solves the problems of duplication and conflict.
- As an open architecture, Maven provides a public interface to facilitate integration with third-party plug-ins. Programmers can dynamically integrate the plug-ins they need into Maven to expand new management functions.
- Maven can unify the construction process of each project and realize the compatibility management of different projects.
Maven's directory structure
1)bin
After the java script and the Java path are configured, the system is ready to execute these commands.
2)boot
This directory contains only one file. Take maven 3.8.1 as an example. The file is plexus-classworlds-2.6.0. Plexus classworlds is a class loader framework. Compared with the default java class loader, it provides richer syntax to facilitate configuration. Maven uses this framework to load his own class library.
3)conf
This directory contains a very important file settings xml. By directly modifying the file, Maven's behavior can be customized globally on the machine.
4)lib
This directory contains all Java class libraries required by Maven runtime. Maven itself is developed in modules.
Deep life cycle
1. clean life cycle
The purpose of the clean life cycle is to clean up the project. It includes the following three stages.
Pre clean: work to be completed before cleaning.
Clean: clean up the files generated during the last build, such as the compiled class files.
Post clean: the work to be completed after cleaning.
2. default life cycle
The default life cycle defines the execution steps required to build a project. It is the most core part of all life cycles. The phases included are described in the table below, and the commonly used phases are marked in bold.
Name} description
validate verifies whether the project structure is normal and whether the necessary configuration files exist
initialize performs initialization operations before construction, such as initializing parameters, creating necessary directories, etc
Generate sources generates the source code needed in the compilation process
Process sources processes source code, such as filter values
Generate resources generates the package of resources in the main code in the classpath
Process resources copies the resource file to the corresponding package of classpath
compile compiles the source code in the project
Process classes generates files generated during compilation
Generate test sources generates test related code during compilation
Process test sources process test code
Generate test resources generates the package of resources in the test in the classpath
Process test resources copies the test resources to the classpath
Test compile compile test code
Process test classes generates files for compiling test code
Test run test case
Prepare package handles the preparations that need to be initialized before packaging
package packages the compiled class es and resources into compressed files, such as rar
Pre integration test make preparations before integration test, such as parameter setting of integration environment
Integration test
Post integration test completes the final work after the integration test, such as cleaning up the values of the integration environment
verify checks whether the tested package is intact
install installs the packaged components in the form of components into the local dependency warehouse for sharing with other local projects
deploy runs the integration and publishing environment, and releases the final package after testing to the remote warehouse in the form of components, which is convenient for all programmers to share
3. site life cycle
The purpose of the site life cycle is to establish and publish project sites. Maven can automatically generate the project site based on the information described in pom. At the same time, it can also generate relevant reports and documents as needed, which are integrated into the site to facilitate the team to communicate and publish project information. The site life cycle includes the following stages.
Pre site: perform the preparations before generating the site.
Site: generate site documents.
Post site: perform the work that needs to be closed after generating the site.
Site deploy: publish the generated site to the server.
1) mvn clean: call the clean phase of the clean life cycle, and actually execute the pre clean and clean phases in the clean life cycle.
2) mvn test: this command calls the test phase in the default lifecycle. The actual execution stages include validate, initialize, generate sources... Compile... Test compile, process test classes and test, that is, all the stages from the beginning to test in the default life cycle are executed in sequence.
3) mvn clean install: this command calls the clean phase of the clean life cycle and the install phase of the default life cycle.
The actual execution is the pre clean and clean phases in the clean life cycle and all phases from the start of validate to install in the default life cycle. This command combines two lifecycles. In the actual project construction, it is a good habit to clean up the old files built before each line of construction
4) MVN clean deploy site deploy: this command calls the pre clean and clean phases in the clean life cycle, all phases from validate to deploy in the default life cycle, and the pre site, site, post site and site deploy phases in the site life cycle.
Maven coordinates
<artifactId>spring-boot-parent</artifactId>
<groupId>org.springframework.boot</groupId>
<version>2.1.18.RELEASE</version>
<packaging>jar</packaging>
1. groupId
Defines the actual project to which the current Maven project belongs. The understanding of groupId is as follows.
1) Maven project and actual project do not necessarily correspond one-to-one. For example, the spring framework has many Maven projects, such as spring core, spring context, spring security, etc. The reason for this is the concept of modules, so an actual project is often divided into many modules.
2) groupId should not correspond to the company or organization developing the project. The reason is easy to understand. A company and an organization will develop many actual projects. If the groupId is used to correspond to the company and organization, the artifact ID can only correspond to each actual project, and the next modules cannot be described. Often, each module in the project forms a component in a separate form, so that other projects can be used repeatedly.
3) The expression of groupId is similar to that of Java package name, which usually corresponds to the reverse of domain name one by one.
2. artifactId
Define a Maven project in the actual project (a module in the actual project).
The recommended naming method is: actual project name - module name.
For example, org Spring framework is the name of the actual project, and now the core module is used, and its artifact ID is spring core.
3. version
Define the current version of Maven. As described above, 4.2.7.1 is used Release version. It should be noted that Maven has a set of specifications for the definition of version number. For specific specifications, please refer to the introduction of version management.
4. packaging
Define how Maven projects are packaged.
The packaging method usually corresponds to the extension of the generated component file, for example jar,. ear,. war,. pom et al. In addition, the packaging method corresponds to the life cycle of engineering construction. For example, jar packaging and war packaging use different commands. Finally, it should be noted that packaging can not be specified. At this time, Maven will automatically default to jar.
Dependent range
1)compile
Compile dependency range. If it is not specified during configuration, this range is used by default. Using this range of dependencies is effective for compiling, testing and running three Classpaths.
2)test
Test dependency range. The dependency using this range is only valid for testing classpath. This dependency is invalid when compiling the main code or running the project.
3)provided
Dependency scope provided. Dependencies using this range are only valid when compiling and testing classpath, but not when running the project. For example, the servlet API in Web applications requires this dependency when compiling and testing. When running, because the servlet API comes with the container, it is not necessary to use it. If it is used, there may be conflicting versions.
4)runtime
Runtime dependency range. Using this range of dependencies is only valid for the classpath tested and run, but it is invalid when compiling the main code. For example, the jdbc driver implementation class needs to be used when running the test and running the main code. When compiling, it only needs the JDBC interface.
5)system
System dependency range. The relationship between this range and classpath is the same as provided. However, when using system access, you must specify the path of the dependent file through the systemPath element. Because the dependency is not resolved through Maven warehouse, it is recommended to use it with caution.
<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<!--Coordinates of the parent project. If the value of an element is not specified in the project, the corresponding value in the parent project is the default value of the project. Coordinates include group ID，artifact ID and version. -->
<parent>
<!--The component identifier of the inherited parent project-->
<artifactId/>
<!--Globally unique identifier of the inherited parent project-->
<groupId/>
<!--The version of the inherited parent project-->
<version/>
<!-- Parent item purpose pom.xml The relative path of the file. Relative paths allow you to choose a different path. The default value is../pom.xml. Maven First, look for the name of the parent project where the current project is built pom，Second, in this location of the file system( relativePath Location), then find the location of the parent project in the local warehouse and finally in the remote warehouse pom. -->
<relativePath/>
</parent>
<!--Which item descriptor follows POM Model version. The version of the model itself rarely changes, but it is still essential to be Maven Ensure stability when new features or other model changes are introduced.-->
<modelVersion>4.0.0</modelVersion>
<!--The globally unique identifier of the project, which usually uses a fully qualified package name to distinguish the project from other projects. And the path generated during construction is also generated from this, such as com.mycompany.app The generated relative path is:/com/mycompany/app-->
<groupId>asia.banseon</groupId>
<!-- Identifier of the component, which is associated with group ID Together, uniquely identify a component. In other words, you can't have two different projects with the same artifact ID and groupID；In a particular group ID Next, artifact ID It must also be unique. A component is something produced or used by a project, Maven The components produced for the project include: JARs，Source code, binary release and WARs Wait.-->
<artifactId>banseon-maven2</artifactId>
<!--The type of component produced by the project, such as jar,war,ear,pom. Plug ins can create their own component types, so not all component types listed above-->
<packaging>jar</packaging>
<!--The current version of the project in the format:Main version.Minor version.Incremental version-Restricted version number-->
<version>1.0-SNAPSHOT</version>
<!--Name of the project, Maven Generated documents-->
<name>banseon-maven</name>
<!--Project home page URL, Maven Generated documents-->
<url>http://www.baidu.com/banseon</url>
<!-- Detailed description of the project, Maven The generated document is used. When this element can be used HTML Format description (for example, CDATA The text in is ignored by the parser and can be included HTML Tags), plain text descriptions are discouraged. If you need to modify the generated web For the index page of the site, you should modify your own index page file instead of adjusting the documents here.-->
<description>A maven project to study maven.</description>
<!--Describes the prerequisites in the project build environment.-->
<prerequisites>
<!--Required to build the project or use the plug-in Maven Minimum version of-->
<maven/>
</prerequisites>
<!--Project problem management system(Bugzilla, Jira, Scarab,Or any problem management system you like)Name and URL，This example is jira-->
<issueManagement>
<!--Problem management system (e.g jira)Your name,-->
<system>jira</system>
<!--The problem management system used in the project URL-->
<url>http://jira.baidu.com/banseon</url>
</issueManagement>
<!--Project continuous integration information-->
<ciManagement>
<!--Name of the continuous integration system, e.g continuum-->
<system/>
<!--The continuous integration system used in the project URL(If the continuous integration system has web Interface).-->
<url/>
<!--Developers to be notified when the build is complete/User's configuration item. Include notifiee information and notification conditions (error, failure, success, warning)-->
<notifiers>
<!--Configure a way to notify the user when the build is interrupted/developer-->
<notifier>
<!--Route of notification-->
<type/>
<!--Notify when an error occurs-->
<sendOnError/>
<!--Notify if build fails-->
<sendOnFailure/>
<!--Notify when the build is successful-->
<sendOnSuccess/>
<!--Notify when a warning occurs-->
<sendOnWarning/>
<!--Do not approve of using. Where is the notification sent-->
<address/>
<!--Extended configuration item-->
<configuration/>
</notifier>
</notifiers>
</ciManagement>
<!--Project creation year, 4 digits. This value is required when generating copyright information.-->
<inceptionYear/>
<!--Project related mailing list information-->
<mailingLists>
<!--This element describes all mailing lists related to the project. Automatically generated websites reference this information.-->
<mailingList>
<!--The name of the message-->
<name>Demo</name>
<!--The address or link to which the email is sent. If it is an email address, when creating a document, mailto: The link will be created automatically-->
<post>banseon@126.com</post>
<!--Subscribe to the email address or link. If it is an email address, when creating a document, mailto: The link will be created automatically-->
<subscribe>banseon@126.com</subscribe>
<!--Unsubscribe from the email address or link. If it is an email address, when creating a document, mailto: The link will be created automatically-->
<unsubscribe>banseon@126.com</unsubscribe>
<!--You can browse email information URL-->
<archive>http:/hi.baidu.com/banseon/demo/dev/</archive>
</mailingList>
</mailingLists>
<!--Project developer list-->
<developers>
<!--Information about a project developer-->
<developer>
<!--SCM Unique identifier of the project developer in the-->
<id>HELLO WORLD</id>
<!--Full name of the project developer-->
<name>banseon</name>
<!--Project developer's email-->
<email>banseon@126.com</email>
<!--Project developer's home page URL-->
<url/>
<!--The role of the project developer in the project. The role element describes various roles-->
<roles>
<role>Project Manager</role>
<role>Architect</role>
</roles>
<!--Organization of project developer-->
<organization>demo</organization>
<!--Organization of the project developer URL-->
<organizationUrl>http://hi.baidu.com/banseon</organizationUrl>
<!--Project developer attributes, such as how to handle instant messages, etc-->
<properties>
<dept>No</dept>
</properties>
<!--The time zone of the project developer, -11 An integer in the range from to 12.-->
<timezone>-5</timezone>
</developer>
</developers>
<!--List of other contributors to the project-->
<contributors>
<!--Other contributors to the project. See developers/developer element-->
<contributor>
<name/>
<email/>
<url/>
<organization/>
<organizationUrl/>
<roles/>
<timezone/>
<properties/>
</contributor>
</contributors>
<!--This element describes all elements of the project License List. You should list only for this item license List, do not list dependent items license List. If more than one is listed license，Users can choose one of them instead of accepting all of them license. -->
<licenses>
<!--Describes the of the project license，Used to build the project web Site license Page, some other reports and validation This element will also be used.-->
<license>
<!--license Used as a legal name-->
<name>Apache 2</name>
<!--Official license Text page URL-->
<url>http://www.baidu.com/banseon/LICENSE-2.0.txt</url>
<!--Main methods of project distribution:
repo，Can from Maven Library Download
manual， Users must manually download and install dependencies-->
<distribution>repo</distribution>
<!--about license Supplementary information for-->
<comments>A business-friendly OSS license</comments>
</license>
</licenses>
<!--SCM(Source Control Management)Tags allow you to configure your code base for Maven web Site and other plug-ins.-->
<scm>
<!--SCM of URL,Should URL Describes the version library and how to connect to it. For details, please see SCMs Provided URL Format and list. The connection is read-only.-->
<connection>scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk)</connection>
<!--For developers, similar connection Element. That is, the connection is not only read-only-->
<developerConnection>scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk</developerConnection>
<!--The label of the current code, which defaults to HEAD-->
<tag/>
<!--Browsable to an item SCM Library (e.g ViewVC perhaps Fisheye)of URL. -->
<url>http://svn.baidu.com/banseon</url>
</scm>
<!--Describes various attributes of the organization to which the project belongs. Maven Generated documents-->
<organization>
<!--Full name of the organization-->
<name>demo</name>
<!--Organization home page URL-->
<url>http://www.baidu.com/banseon</url>
</organization>
<!--Information needed to build the project-->
<build>
<!--This element sets the project source code directory. When building a project, the construction system will compile the source code in the directory. The path is relative to pom.xml Relative path of.-->
<sourceDirectory/>
<!--This element sets the project script source directory, which is different from the source directory: in most cases, the contents of this directory will be copied to the output directory(Because scripts are interpreted, not compiled). -->
<scriptSourceDirectory/>
<!--This element sets the source code directory used by the project unit test. When testing the project, the construction system will compile the source code in the directory. The path is relative to pom.xml Relative path of.-->
<testSourceDirectory/>
<!--Compiled application class Directory where files are stored.-->
<outputDirectory/>
<!--Compiled tests class Directory where files are stored.-->
<testOutputDirectory/>
<!--Use a series of build extensions from the project-->
<extensions>
<!--Describes the build extensions used.-->
<extension>
<!--Build extended groupId-->
<groupId/>
<!--Build extended artifactId-->
<artifactId/>
<!--Build extended version-->
<version/>
</extension>
</extensions>
<!--When the project has no specified objectives( Maven2 Default value when called phase)-->
<defaultGoal/>
<!--This element describes the path list of all resources related to the project, such as the property file related to the project. These resources are included in the final packaging file.-->
<resources>
<!--This element describes all resource paths related to the project or test-->
<resource>
<!-- Describes the target path of the resource. The path is relative target/classes Directory (e.g ${project.build.outputDirectory}). For example, if you want resources in a specific package(org.apache.maven.messages)，You must set this element to org/apache/maven /messages. However, if you just want to put resources into the source directory structure, you don't need this configuration.-->
<targetPath/>
<!--Whether to use parameter value instead of parameter name. Parameter values are taken from properties Element or attribute configured in the file filters Elements.-->
<filtering/>
<!--Describes the directory where resources are stored. This path is relative POM route-->
<directory/>
<!--Contains a list of modes, such as**/*.xml.-->
<includes/>
<!--List of excluded modes, for example**/*.xml-->
<excludes/>
</resource>
</resources>
<!--This element describes all the resource paths related to the unit test, such as the property files related to the unit test.-->
<testResources>
<!--This element describes all resource paths related to the test. See build/resources/resource Description of the element-->
<testResource>
<targetPath/>
<filtering/>
<directory/>
<includes/>
<excludes/>
</testResource>
</testResources>
<!--The directory where all files generated by the build are stored-->
<directory/>
<!--The file name of the generated component. The default value is ${artifactId}-${version}. -->
<finalName/>
<!--When filtering List of filter property files used when the switch is on-->
<filters/>
<!--Default plug-in information that can be referenced by subprojects. The plug-in configuration item will not be resolved or bound to the life cycle until it is referenced. Any local configuration of a given plug-in will override the configuration here-->
<pluginManagement>
<!--List of plug-ins used.-->
<plugins>
<!--plugin The element contains the information needed to describe the plug-in.-->
<plugin>
<!--The plug-in is in the warehouse group ID-->
<groupId/>
<!--The plug-in is in the warehouse artifact ID-->
<artifactId/>
<!--Version (or version range) of the plug-in being used-->
<version/>
<!--Download from this plugin Maven Extensions (such as packaging and type processors), for performance reasons, this element is set to only when it really needs to be downloaded enabled. -->
<extensions/>
<!--The configuration of a set of goals is performed during the build lifecycle. Each target may have a different configuration.-->
<executions>
<!--execution The element contains the information required for plug-in execution-->
<execution>
<!--The identifier of the execution target, which is used to identify the target in the construction process or match the execution target to be merged in the inheritance process-->
<id/>
<!--The construction life cycle phase of the target is bound. If omitted, the target will be bound to the default phase configured in the source data-->
<phase/>
<!--Configured execution target-->
<goals/>
<!--Is the configuration propagated to the child POM-->
<inherited/>
<!--As DOM Object configuration-->
<configuration/>
</execution>
</executions>
<!--Additional dependencies required for the project to introduce plug-ins-->
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
<!--Is any configuration propagated to subprojects-->
<inherited/>
<!--As DOM Object configuration-->
<configuration/>
</plugin>
</plugins>
</pluginManagement>
<!--List of plug-ins used-->
<plugins>
<!--See build/pluginManagement/plugins/plugin element-->
<plugin>
<groupId/>
<artifactId/>
<version/>
<extensions/>
<executions>
<execution>
<id/>
<phase/>
<goals/>
<inherited/>
<configuration/>
</execution>
</executions>
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
<goals/>
<inherited/>
<configuration/>
</plugin>
</plugins>
</build>
<!--Project build in column profile，If the build is activated, it will be processed-->
<profiles>
<!--Activate a build process based on environment parameters or command line parameters-->
<profile>
<!--Unique identifier of the build configuration. It is used not only for command line activation, but also for merging objects with the same identifier during inheritance profile. -->
<id/>
<!--Automatic trigger profile Conditional logic. Activation yes profile Open the key. profile The power of comes from it
Can automatically use certain specific values in certain specific environments; These environments pass activation Element assignment. activation Element is not active profile The only way.-->
<activation>
<!--profile Flag of whether to activate by default-->
<activeByDefault/>
<!--When matched jdk Detected, profile Activated. For example, 1.4 activation JDK1.4，1.4.0_2，and!1.4 Activate all versions instead of 1.4 initial JDK. -->
<jdk/>
<!--When matching operating system attributes are detected, profile Activated. os Element can define some operating system related attributes.-->
<os>
<!--activation profile The name of the operating system-->
<name>Windows XP</name>
<!--activation profile Family of operating systems(as 'windows')-->
<family>Windows</family>
<!--activation profile Operating system architecture -->
<arch>x86</arch>
<!--activation profile Operating system version-->
<version>5.1.2600</version>
</os>
<!--If Maven A property is detected (its value can be in POM Passed in ${name}Reference), which has the corresponding name and value, Profile Will be activated. If value
If the field is empty, the attribute name field will be activated profile，Otherwise, attribute value fields are matched case sensitive-->
<property>
<!--activation profile The name of the property-->
<name>mavenVersion</name>
<!--activation profile The value of the property-->
<value>2.0.3</value>
</property>
<!--Provide a file name to activate by detecting the presence or absence of the file profile. missing Check whether the file exists, and activate if it does not exist
profile. on the other hand, exists The file is checked for existence and activated if it exists profile. -->
<file>
<!--Activate if the specified file exists profile. -->
<exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</exists>
<!--Activate if the specified file does not exist profile. -->
<missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</missing>
</file>
</activation>
<!--Information needed to build the project. See build element-->
<build>
<defaultGoal/>
<resources>
<resource>
<targetPath/>
<filtering/>
<directory/>
<includes/>
<excludes/>
</resource>
</resources>
<testResources>
<testResource>
<targetPath/>
<filtering/>
<directory/>
<includes/>
<excludes/>
</testResource>
</testResources>
<directory/>
<finalName/>
<filters/>
<pluginManagement>
<plugins>
<!--See build/pluginManagement/plugins/plugin element-->
<plugin>
<groupId/>
<artifactId/>
<version/>
<extensions/>
<executions>
<execution>
<id/>
<phase/>
<goals/>
<inherited/>
<configuration/>
</execution>
</executions>
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
<goals/>
<inherited/>
<configuration/>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<!--See build/pluginManagement/plugins/plugin element-->
<plugin>
<groupId/>
<artifactId/>
<version/>
<extensions/>
<executions>
<execution>
<id/>
<phase/>
<goals/>
<inherited/>
<configuration/>
</execution>
</executions>
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
<goals/>
<inherited/>
<configuration/>
</plugin>
</plugins>
</build>
<!--Modules (sometimes called subprojects) are built as part of the project. Each module element listed is a relative path to the directory of the module-->
<modules/>
<!--Discover the list of dependent and extended remote warehouses.-->
<repositories>
<!--See repositories/repository element-->
<repository>
<releases>
<enabled/>
<updatePolicy/>
<checksumPolicy/>
</releases>
<snapshots>
<enabled/>
<updatePolicy/>
<checksumPolicy/>
</snapshots>
<id/>
<name/>
<url/>
<layout/>
</repository>
</repositories>
<!--Discover a list of remote repositories for plug-ins that are used to build and report-->
<pluginRepositories>
<!--Contains information about the need to connect to the remote plug-in repository.See repositories/repository element-->
<pluginRepository>
<releases>
<enabled/>
<updatePolicy/>
<checksumPolicy/>
</releases>
<snapshots>
<enabled/>
<updatePolicy/>
<checksumPolicy/>
</snapshots>
<id/>
<name/>
<url/>
<layout/>
</pluginRepository>
</pluginRepositories>
<!--This element describes all dependencies related to the project. These dependencies constitute each link in the project construction process. They are automatically downloaded from the repository defined by the project. For more information, see project dependency mechanism.-->
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
<!--Disapprove of using. Now? Maven Ignore this element.-->
<reports/>
<!--This element includes specifications for generating reports using the report plug-in. When the user executes“ mvn site"，These reports will run. You can see the links of all reports in the page navigation bar. See reporting element-->
<reporting>......</reporting>
<!--See dependencyManagement element-->
<dependencyManagement>
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
</dependencyManagement>
<!--See distributionManagement element-->
<distributionManagement>......</distributionManagement>
<!--See properties element-->
<properties/>
</profile>
</profiles>
<!--Modules (sometimes called subprojects) are built as part of the project. Each module element listed is a relative path to the directory of the module-->
<modules/>
<!--Discover the list of dependent and extended remote warehouses.-->
<repositories>
<!--Contains information that needs to be connected to the remote warehouse-->
<repository>
<!--How to handle the download of release version in remote warehouse-->
<releases>
<!--true perhaps false Indicates whether the warehouse is opened for downloading certain types of components (release version, snapshot version). -->
<enabled/>
<!--This element specifies how often updates occur. Maven Will compare local POM And remote POM The timestamp of the. The options here are: always(All the time), daily(Default, daily), interval: X(here X Is the time interval in minutes), or never(Never).-->
<updatePolicy/>
<!--When Maven What to do when verifying the component verification file fails: ignore(Ignore), fail(Failure), or warn(Warning).-->
<checksumPolicy/>
</releases>
<!-- How to handle the download of snapshot version in remote warehouse. Yes releases and snapshots These two sets of configurations, POM You can adopt different strategies for each type of component in each separate warehouse. For example, someone may decide to turn on support for snapshot version download only for development purposes. See repositories/repository/releases element -->
<snapshots>
<enabled/>
<updatePolicy/>
<checksumPolicy/>
</snapshots>
<!--Unique identifier of the remote warehouse. Can be used to match in settings.xml Remote warehouse configured in file-->
<id>banseon-repository-proxy</id>
<!--Remote warehouse name-->
<name>banseon-repository-proxy</name>
<!--Remote warehouse URL，Press protocol://hostname/path form -- >
<url>http://192.168.1.169:9999/repository/</url>
<!-- Warehouse layout type used to locate and sort components-Can be default(Default) or legacy(Legacy). Maven 2 Provide a default layout for its warehouse; However, Maven 1.x There is a different layout. We can use this element to specify whether the layout is default(Default) or legacy(Legacy).-->
<layout>default</layout>
</repository>
</repositories>
<!--Discover a list of remote repositories for plug-ins that are used to build and report-->
<pluginRepositories>
<!--Contains information about the need to connect to the remote plug-in repository.See repositories/repository element-->
<pluginRepository>......</pluginRepository>
</pluginRepositories>
<!--This element describes all dependencies related to the project. These dependencies constitute each link in the project construction process. They are automatically downloaded from the repository defined by the project. For more information, see project dependency mechanism.-->
<dependencies>
<dependency>
<!--Dependent group ID-->
<groupId>org.apache.maven</groupId>
<!--Dependent artifact ID-->
<artifactId>maven-artifact</artifactId>
<!--Dependent version number. stay Maven 2 in, You can also configure the range of version numbers.-->
<version>3.8.1</version>
<!-- Dependency type. The default type is jar. It usually represents the extension of the dependent file, but there are exceptions. A type can be mapped to another extension or classifier. Types often correspond to the packaging method used, although there are exceptions. Examples of some types: jar，war，ejb-client and test-jar. If set extensions by true，Can be in plugin Define new types in. So the previous examples of types are incomplete.-->
<type>jar</type>
<!-- Dependent classifier. Classifiers can distinguish between belonging to the same POM，However, components with different construction methods. The classifier name is appended to the version number of the file name. For example, if you want to build two separate components into JAR，One use Java 1.4 Compiler, another uses Java 6 Compiler, you can use the classifier to generate two separate JAR Components.-->
<classifier/>
<!--Dependency range. In the process of project publishing, it helps to decide which components are included. For details, please refer to the dependency mechanism.
- compile : Default range for compilation
- provided: Similar to compiling, but support your expectations jdk Or provided in containers, similar to classpath
- runtime: Required for execution
- test: be used for test Use in task
- system: Corresponding elements need to be provided externally. adopt systemPath To get
- systemPath: Only for use in the range system. Provide corresponding path
- optional: When the project itself is dependent, mark whether the dependency is passed. Used for continuous dependencies-->
<scope>test</scope>
<!--Only system Scope of use. Note that this element is discouraged and may be overwritten in the new version. This element specifies the path on the file system for the dependency. An absolute path is required instead of a relative path. It is recommended to use attributes to match absolute paths, such as ${java.home}. -->
<systemPath/>
<!--When calculating the transfer dependency, list the excluded dependent component set from the dependent component list. Namely tell maven You only depend on the specified project, not the project. This element is mainly used to resolve version conflicts-->
<exclusions>
<exclusion>
<artifactId>spring-core</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
</exclusions>
<!--Optional dependencies if you are in the project B Middle handle C If the dependency declaration is optional, you need to B Project (e.g. project) A)Explicit reference pairs in C Dependence on. Optional dependencies block the transitivity of dependencies.-->
<optional>true</optional>
</dependency>
</dependencies>
<!--Disapprove of using. Now? Maven Ignore this element.-->
<reports/>
<!--This element describes the specification for generating reports using the report plug-in. When the user executes“ mvn site"，These reports will run. You can see the links of all reports in the page navigation bar.-->
<reporting>
<!--true，Then, the website does not include the default report. This includes reports in the project information menu.-->
<excludeDefaults/>
<!--Where are all generated reports stored. The default value is ${project.build.directory}/site. -->
<outputDirectory/>
<!--Report plug-ins used and their configuration.-->
<plugins>
<!--plugin The element contains the information needed to describe the report plug-in-->
<plugin>
<!--Application of report plug-in in warehouse group ID-->
<groupId/>
<!--Application of report plug-in in warehouse artifact ID-->
<artifactId/>
<!--Version (or version range) of the report plug-in used-->
<version/>
<!--Is any configuration propagated to subprojects-->
<inherited/>
<!--Configuration of report plug-in-->
<configuration/>
<!--Multiple specifications of a set of reports. Each specification may have different configurations. A specification (report set) corresponds to an execution target. For example, there are 1, 2, 3, 4, 5, 6, 7, 8 and 9 reports. Composition of 1, 2 and 5 A Report set, corresponding to an execution target. Composition of 2, 5 and 8 B Report set, corresponding to another execution target-->
<reportSets>
<!--Represents a collection of reports and the configuration that generates the collection-->
<reportSet>
<!--Unique identifier of the report collection, POM Used in inheritance-->
<id/>
<!--The configuration of the report used when generating the report collection-->
<configuration/>
<!--Whether the configuration is inherited to the child POMs-->
<inherited/>
<!--Which reports are used in this collection-->
<reports/>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
<!-- Default dependency information inherited from all subprojects of the project. This part of the dependency information will not be resolved immediately,But when the subproject declares a dependency (must be described) group ID and artifact ID Information), if group ID and artifact ID If some information other than is not described, it can be passed group ID and artifact ID Match the dependencies here and use the dependency information here.-->
<dependencyManagement>
<dependencies>
<!--See dependencies/dependency element-->
<dependency>......</dependency>
</dependencies>
</dependencyManagement>
<!--Project distribution information, during implementation mvn deploy After indicates the location to publish. With this information, you can deploy the website to a remote server or components to a remote warehouse.-->
<distributionManagement>
<!--The information required to deploy the components generated by the project to the remote warehouse-->
<repository>
<!--Is a unique version number (by timestamp and build serial number) assigned to the snapshot? Or use the same version number every time? See repositories/repository element-->
<uniqueVersion/>
<id>banseon-maven2</id>
<name>banseon maven2</name>
<url>file://${basedir}/target/deploy</url>
<layout/>
</repository>
<!--Where is the snapshot of the component deployed? If this element is not configured, it will be deployed to by default repository Warehouse of element configuration, see distributionManagement/repository element-->
<snapshotRepository>
<uniqueVersion/>
<id>banseon-maven2</id>
<name>Banseon-maven2 Snapshot Repository</name>
<url>scp://svn.baidu.com/banseon:/usr/local/maven-snapshot</url>
<layout/>
</snapshotRepository>
<!--Information needed to deploy the project's Web site-->
<site>
<!--Unique identifier of the deployment location to match the site and location settings.xml Configuration in file-->
<id>banseon-site</id>
<!--The name of the deployment location-->
<name>business api website</name>
<!--Deployment location URL，Press protocol://hostname/path form -- >
<url>scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web</url>
</site>
<!--Of the project download page URL. The user should refer to the home page if there is no such element. The reason for using this element is to help locate components that are not in the warehouse (due to license Restrictions).-->
<downloadUrl/>
<!--If the component has a new group ID and artifact ID(The relocation information of the component is listed here.-->
<relocation>
<!--Component NEW group ID-->
<groupId/>
<!--Component NEW artifact ID-->
<artifactId/>
<!--The new version number of the component-->
<version/>
<!--Additional information displayed to the user about the move, such as the reason.-->
<message/>
</relocation>
<!-- The status of the component in the remote warehouse is given. This element must not be set in a local project because it is automatically updated by the tool. Valid values are: none(Default), converted(Warehouse keeper from Maven 1 POM Switch over), partner(Directly from partner Maven 2 Warehouse synchronization), deployed(from Maven 2 Instance deployment), verified(Correct and final when verified).-->
<status/>
</distributionManagement>
<!--Replace the name with a value, Properties Can be in the whole POM It can also be used as a trigger condition (see settings.xml In the configuration file activation Description of the element). Format is<name>value</name>. -->
<properties/>
</project>