setting.xml is mainly used to configure a series of common attributes such as maven's running environment, and is a global-level configuration file; while pom.xml mainly describes the project's maven coordinates, dependencies, rules that developers need to follow, defect management system, organization and licenses, as well as all other project-related factors, and is a project-level configuration file.
Basic configuration
A typical pom.xml file configuration is as follows:
<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.0http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- Model version. maven2.0 must be written like this, now it is the only supported version of maven2 --> <modelVersion>4.0.0</modelVersion> <!-- The unique flag of the company or organization, and the path generated during configuration is also generated from this. For example, com.winner.trade, maven will place the jar package of the project into a local path: /com/winner/trade --> <groupId>com.winner.trade</groupId> <!-- The unique ID of this project, multiple projects under a groupId may be distinguished by artifactId --> <artifactId>trade-core</artifactId> <!-- The current version number of this project --> <version>1.0.0-SNAPSHOT</version> <!-- The version number of this project is currently in --> <version>1.0.0-SNAPSHOT</version> <!-- Packaging mechanisms, such as pom, jar, maven-plugin, ejb, war, ear, rar, par, default is jar --> <packaging>jar</packaging> <!-- Help define some auxiliary components output by component. The auxiliary components correspond to the main component. Sometimes you need to add a classifier to uniquely determine that the component cannot directly define the classifer of the project, because the auxiliary components are not generated directly by the project, but are generated by the help of additional plug-ins --> <classifier>...</classifier> <!-- Define the dependencies of this project --> <dependencies> <!-- Each dependency corresponds to this jar package --> <dependency> <!--Usually, maven searches the component through the three element values (commonly known as coordinates) of groupId, artifactId, and version, and then introduces your project. If someone wants to reference the project you are developing now (provided that it has been developed and published to the remote repository), --> <!-- You need to create a dependency node in its pom file and write the groupId, artifactId, and version of this project. Maven will download the jar package you uploaded to its local--> <groupId>com.winner.trade</groupId> <artifactId>trade-test</artifactId> <version>1.0.0-SNAPSHOT</version> <!-- maven believes that the program's dependence on external factors will change with the stage and application scenario of the program, so the dependencies in maven have scope restrictions. --> <!--scope contains the following values: compile (compile scope), provided (provided scope), runtime (runtime scope), test (test scope), system (system scope) --> <scope>test</scope> <!-- Setting refers to whether the dependency is optional, default is false, that is, the sub-projects inherit by default: true, the introduction that the sub-project must display is similar to the dependency defined in dependencyManagement --> <optional>false</optional> <!-- Mask dependencies. For example, the libA used in the project depends on the 1.0 version of a library, and libB depends on the 2.0 version of a library. Now if you want to use the 2.0 version in a unified way, you should block the dependency on the 1.0 version --> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </exclusion> </exclusions> </dependency> </dependencies> <!-- Define some constants for pom. You can directly reference and use them in other places in the pom as follows: ${file.encoding} --> <properties> <file.encoding>UTF-8</file.encoding> <java.source.version>1.5</java.source.version> <java.target.version>1.5</java.target.version> </properties> ... </project>Generally speaking, the above configuration items are essential for any project and define the basic properties of the project.
Here it is necessary to explain a less commonly used property classifier, because sometimes a certain jar package is quoted and if the classifier is not written, it will report an error.
The classifier element is used to help define some of the auxiliary components that are outputted by the component. The auxiliary components correspond to the main components. For example, the main components are kimi-app-2.0.0.jar. This project may also generate two auxiliary components such as kimi-app-2.0.0-javadoc.jar (Java documentation) and kimi-app-2.0.0-sources.jar (Java source code) by using some plug-ins. At this time, javadoc and sources are the classifiers of these two auxiliary components, so that the auxiliary components have their own unique coordinates.
The purpose of classifier is:
1. When mavendownloadjavadoc/sourcesjar package, you need to use the classifier to specify which auxiliary component to download
2. When introducing dependencies, sometimes a certain component cannot be uniquely determined based on groupId, artifactId, and version. Classifiers are needed to further clarify the goal. For example, JSON-lib sometimes provides multiple jar packages in the same version, which is one set in JDK1.5 environment and one set in JDK1.3 environment:
When quoting it, you must indicate the JDK version, otherwise maven will not know which jar package you need:
<dependency> <groupId>net.sf.json-lib</groupId> <artifactId>json-lib</artifactId> <version>2.4</version> <classifier>jdk15</classifier> </dependency>
Build configuration
<build> <!-- The file name of the generated component, the default value is ${artifactId}-${version}. --> <finalName>myPorjectName</finalName> <!-- The directory where all files generated are stored in the build is ${basedir}/target, that is, the target in the root directory of the project --> <directory>${basedir}/target</directory> <!--The default value when the project does not specify the target (Maven2 is called phase), --> <!--The parameter must be the same as the command line, such as jar:jar, or the same as a phase, such as install, compile, etc. --> <defaultGoal>install</defaultGoal> <!--The filter attribute file list used when the filtering switch is turned on. --> <!-- Placeholders such as ${spring.version} in the project configuration information will be replaced by the actual value in the property file --> <filters> <filter>../filter.properties</filter> </filters> <!-- List of all resource paths related to the project, such as configuration files and property files related to the project, which are included in the final packaged file. --> <resources> <resource> <!--Describes the target path of the resource. The path is relative to the target/classes directory (e.g. ${project.build.outputDirectory}). --> <!--For example, if you want the resource to be in a specific package (org.apache.maven.messages), you must set the 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>resources</targetPath> <!--Whether to use parameter values instead of parameter names. The parameter value is taken from the properties element or the properties configured in the file, and the file is listed in the filters element. --> <filtering>true</filtering> <!--Describe the directory where the resource is stored, which is relative to the POM path --> <directory>src/main/resources</directory> <!--Included pattern list--> <includes> <include>**/*.properties</include> <include>**/*.xml</include> </includes> <!--Excluded pattern list If <include> conflicts with the scope defined by <exclude>, the <exclude> shall prevail --> <excludes> <exclude>jdbc.properties</exclude> </resource> </resources> <!--All resource paths related to unit tests, the configuration method is similar to resources--> <testResources> <testResource> <targetPath /> <filtering /> <directory /> <includes /> <excludes /> </testResource> </testResources> <!--Project source code directory. When building a project, the build system will compile the source code in the directory. This path is a relative path relative to pom.xml. --> <sourceDirectory>${basedir}/src/main/java</sourceDirectory> <!--The source code directory of the project script is different from the source code directory. <!-- In most cases, the contents in this directory will be copied to the output directory (because the script is interpreted, not compiled). --> <scriptSourceDirectory>${basedir}/src/main/scripts </scriptSourceDirectory> <!--The source code directory used for project unit testing. When testing the project, the build system will compile the source code in the directory. This path is a relative path relative to pom.xml. --> <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory> <!--The directory where the compiled application class files are stored. --> <outputDirectory>${basedir}/target/classes</outputDirectory> <!--The directory where the compiled test class file is stored. --> <testOutputDirectory>${basedir}/target/test-classes </testOutputDirectory> <!--A series of construction extensions of the project, which are products to be used in a series of build processes and will be included in the running bulid's classpath. --> <!--They can turn on extensions, or they can activate plugins by providing conditions. --> <!--Simply put, extensions are products that are activated during the build process --> <extensions> <!--For example, usually, after the program development is completed, it may require a series of tedious steps such as packaging, --> <!--Passing package files to the server, connecting SSH to the server, and typing commands to start the program. --> <!--In fact, these steps can be automatically completed through a plug-in of Maven, wagon-maven-plugin --> <!--The following extension plug-in wagon-ssh is used to connect to remote servers through SSH. --> <!--Similar wagon-ftp plug-in that supports ftp---> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh</artifactId> <version>2.8</version> </extensions> <!--The list of plug-ins used. --> <plugins> <plugin> <groupId></groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.5.5</version> <!--Execute a set of target configurations during the build life cycle. Each target may have a different configuration. --> <executions> <execution> <!--Identifier of the execution target, used to identify the target during the construction process, or to match the execution target that needs to be merged during the inheritance process --> <id>assembly</id> <!--Binding the target's build lifecycle phase. If omitted, the target will be bound to the default phase configured in the source data --> <phase>package</phase> <!--Configuration of the execution target--> <goals> <goal>single</goal> </goals> <!--Does the configuration be propagated to the subPOM --> <inherited>false</inherited> </execution> </execution> </executions> <!--As a DOM object, the configuration items vary by plug-in --> <configuration> <finalName>${finalName}</finalName> <appendAsemblyId>false</appendAsemblyId> <descriptor>assembly.xml</descriptor> </configuration> <!--Whether to download Maven extensions (such as packaging and type processors) from this plugin, --> <!--For performance reasons, this element is set to true only if downloads are really needed. --> <extensions>false</extensions> <!--Extra dependencies required for project introduction plug-ins --> <dependencies> <dependency>...</dependency> </dependencies> <!--Whether any configuration is propagated to a subproject--> <inherited>true</inherited> </plugin> </plugins> <!--Official definition of the common elements and extended elements of the plug-in, similar to dependencyManagement, --> <!--All subprojects inherited from this project can be used. This plugin configuration item is not parsed or bound to the lifecycle until it is referenced. --> <!--Any local configuration for a given plugin will override the configuration here --> <pluginManagement> <plugins>...</plugins> </pluginManagement> </build>The repository in pom has the same functions as the repository in setting.xml. The main difference is that the warehouses in the pom are personalized. For example, the setting file in a large company is public, and all projects use a setting file, but each sub-project will refer to different third-party libraries, so you need to set the repository address you need in the pom.
Distribution configuration
<!--Project distribution information, after executing mvn deploy, it indicates the location to be published. --> <!--With this information, you can deploy the website to a remote server or deploy components to a remote repository. --> <distributionManagement> <!--Information required for deploying the widgets generated by the project to the remote repository --> <repository> <!--Is it assigned a unique version number (by timestamp and build flow number) to the snapshot, or is it used the same version number every time --> <!--See repositories/repository element --> <uniqueVersion>true</uniqueVersion> <id> repo-id </id> <name> repo-name</name> <url>file://${basedir}/target/deploy </url> <layout /> </repository> <!--Where to deploy the snapshot of the widget? If the element is not configured, it is deployed to the repository configured by the repository element by default --> <snapshotRepository> <uniqueVersion /> <id /> <name /> <name /> <url /> <layout /> </snapshotRepository> <!--Information required by the website for deploying the project --> <site> <!--The unique identifier of the deployment location, used to match the configuration in the site and settings.xml file --> <id> site-id </id> <!--The name of the deployment location --> <name> site-name</name> <!--The URL of the deployment location, according to protocol://hostname/path--> <url>scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web </url> </site> <!--The URL of the project download page. If this element is not available, the user should refer to the home page. --> <!--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 groupID and artifact ID (the component moved to a new position), the component's relocation information is listed here. --> <relocation> <!--Article's new group ID --> <groupId /> <!--Article's new artifact ID --> <artifactId /> <!--Article's new version number --> <version /> <!--Article's new information about movement, such as the reason. --> <message /> </relocation> <!--Give the status of the component in the remote repository. This element must not be set in the local project, as this is automatically updated by the tool. --> <!--Valid values are: none (default), converted (the warehouse administrator converts from the Maven 1 POM), --> <!--partner (synchronized directly from the partner Maven 2 repository), deployed (deployed from the Maven 2 instance), verified (verified and final). --> <status /> </distributionManagement>Warehouse configuration
<!--Discover a list of remote repositories that dependencies and extensions. --> <repositories> <!--Contains information that needs to be connected to the remote repository --> <repository> <!--How to deal with downloading of published versions in the remote repository --> <releases> <!--true or false indicates whether the repository is open for downloading a certain type of component (release version, snapshot version). --> <enabled /> <!--This element specifies the frequency at which update occurs. Maven compares the timestamps of the local POM and the remote POM. --> <!--The options here are: always, daily (default, daily), --> <!--interval:X (here X is a time interval in minutes), or never (never). --> <updatePolicy /> <!--What to do when the Maven verification component verification file fails: --> <!--ignore, fail, or warning. --> <checksumPolicy /> </releases> <!--How to deal with downloading snapshot versions in remote repository. With the two sets of configurations, releases and snapshots, --> <!--POM can adopt different strategies for each type of component in each separate repository. --> <!--For example, someone might decide to enable support for snapshot version downloads only for development purposes --> <snapshots> <enabled /> <updatePolicy /> <checksumPolicy /> </snapshots> <!--Remote Repository Unique Identifier. It can be used to match the remote repository configured in the settings.xml file --> <id> repo-id </id> <!--Remote repository name --> <name> repo-name</name> <!--Remote repository URL, in the form of protocol://hostname/path --> <url>http://192.168.1.169:9999/repository/ </url> <!--Repository layout type used to locate and sort components - can be default (default) or legacy (legacy). --> <!--Maven 2 provides a default layout for its repository; --> <!-- However, Maven1.x has a different layout. --> <!-- We can use this element to specify whether the layout is default or legacy. --> <layout> default</layout> </repository> </repository> </repository> <!--Discover the remote repository list of plugins for building and reporting --> <pluginRepositories> <!--Contains information that needs to be connected to the remote plugin repository. See repositories/repository elements --> <pluginRepository /> </pluginRepositories>
profile configuration
<!--Build a profile in the column. If activated, the build process will be modified --> <profiles> <!--Activate a build process based on environment parameters or command line parameters--> <profile> <!--The conditional logic of automatically triggering the profile. Activation is the opening key of the profile. --> <activation> <!--identity of whether the profile is activated by default-> <activeByDefault>false</activeByDefault> <!--activation has a built-in Java version detection. If the jdk version is detected as expected, the profile is activated. --> <jdk>1.7</jdk> <!-- When the matching operating system attribute is detected, the profile is activated. The os element can define some operating system-related attributes. --> <os> <!--The name of the operating system that activates the profile --> <name>Windows XP</name> <!--The family of the operating system that activates the profile (such as 'windows') --> <family>Windows</family> <!--The operating system architecture of the profile --> <arch>x86</arch> <!--The operating system version of the profile --> <version>5.1.2600</version> </os> <!--If Maven detects a certain property (its value can be referenced by ${name} in the POM), it has the corresponding name and value, and the Profile will be activated. --> <!-- If the value field is empty, the profile will be activated if the property name field exists. Otherwise, the property value field will be matched in case-sensitive manner --> <property> <!--The name of the property that activates the profile--> <name>mavenVersion</name> <!--The value of the property that activates the profile--> <value>2.0.3</value> </property> <!--Provides a file name that activates the profile by detecting the existence or non-existence of the file. Missing checks whether the file exists, and activates the profile if it does not exist. --> <!--On the other hand, exists will check whether the file exists, and activate the profile if it exists. --> <file> <!-- If the specified file exists, activate the profile. --> <exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</exists> <!-- If the specified file does not exist, activate the profile. --> <missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/</missing> </file> </activation> <id /> <build /> <modules /> <repositories /> <pluginRepositories /> <dependencies /> <reporting /> <dependencyManagement /> <distributionManagement /> <properties /> </profile> Profile configuration items are also available in setting.xml, which is a cropped version of the profile element in pom.xml, including id, activation, repositories, pluginRepositories and properties elements. The profile element here only contains these five child elements because setting.xml only cares about the whole building system (this is exactly the role positioning of the settings.xml file), rather than the separate project object model settings. If a profile in a settings is activated, its value overwrites any other profile defined in the POM or profile.xml with the same id.
The profile in pom.xml can be regarded as a copy of pom.xml, with the same child elements and configuration methods as pom.xml. It contains optional activation (profile trigger) and a series of changes. For example, the test process may point to different databases (relative to the final deployment) or different dependencies or different repositories, and is changed according to different JDKs. Only one of them is established to activate the profile. If the first condition is met, there will be no matching in the future.
Report configuration
<!--Describe the specifications for generating reports using the report plug-in. The specific maven plug-in can output corresponding customized and configured reports. --> <!--When the user executes "mvn site", these reports will run, and you can see links to all reports in the page navigation bar. --> <reporting> <!--true, 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 /> <!--Used report plugins and their configuration. --> <plugins> <plugin> <groupId /> <artifactId /> <version /> <inherited /> <configuration> <links> <link>http://java.sun.com/j2se/1.5.0/docs/api/</link> </links> </configuration> <!-- Multiple specifications for 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, 9 reports. --> <!--1, 2, 5 constitutes the A report set, corresponding to an execution target. 2, 5, 8 constitute the B report set, corresponding to another execution target --> <reportSets> <!--represents a set of reports and the configuration that generates the set --> <reportSet> <!--The unique identifier of the report set, used when POM inherits --> <id>sunlink</id> <!--Configuration of the report used when generating the report set --> <configuration /> <!--Whether the configuration is inherited to child POMs --> <inherited /> <!--What reports are used in this set --> <reports> <report>javadoc</report> </reports> </reportSet> </reportSet> </plugin> </plugins> </reporting>Environment configuration
<!--The name and URL of the project's problem management system (Bugzilla, Jira, Scarab, or any problem management system you like). In this example, jira --> <issueManagement> <!--The name of the problem management system (such as jira), --> <system> jira </system> <!--The URL of the problem management system used by the project --> <url> http://jira.clf.com/</url> </issueManagement> <!--The name of the continuous integration system, such as continuum --> <system /> <!--The URL of the continuous integration system used by the project (if the continuous integration system has a web interface). --> <url /> <!--Configuration items of the developer/user that need to be notified when the build is completed. Includes the notification information and notification conditions (Error, Failure, Success, Warning) --> <notifiers> <!--Configure a way to notify users/developers in this way when the build is interrupted --> <notifier> <!--The way to send notifications --> <type /> <!--Is it notified when an error occurs --> <sendOnError /> <!--Is it notified when a build fails --> <sendOnFailure /> <!--Is it notified when a build is successful --> <sendOnSuccess /> <!--Is it notified when a warning occurs --> <sendOnWarning /> <!--Is it notified when a warning occurs --> <sendOnWarning /> <!--Is it notified when a warning occurs --> <sendOnWarning /> <!--Is it notified when a use is notified. Where to send the notification --> <address /> <!--Extended Configuration Items --> <configuration /> </notifier> </notifiers> </ciManagement>
Project information configuration
<!--The name of the project, for the document generated by Maven --> <name>banseon-maven </name> <!--The URL of the project homepage, for the document generated by Maven --> <url>http://www.clf.com/ </url> <!--Detailed description of the project, for the document generated by Maven. When this element can be described in HTML format --> <!-- (for example, text in CDATA will be ignored by the parser and can contain HTML tags), plain text descriptions are discouraged. --> <!-- If you need to modify the index page of the generated web site, you should modify your own index page file instead of adjusting the documentation here. --> <description>A maven project to study maven. </description> <!--Describes the prerequisites in the construction environment of this project. --> <prerequisites> <!--The minimum version of Maven required to build the project or use the plugin --> <maven /> </prerequisites> <!--The year of project creation, 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 refer to this information. --> <mailingList> <!--The name of the email--> <name> Demo </name> <!--The address or link for sending the email. If it is an email address, the mailto: link will be automatically created when creating the document --> <post> [email protected]</post> <!--The address or link for subscribing the email. If it is an email address, the mailto: link will be automatically created when creating the document --> <subscribe> [email protected]</subscribe> <!--The address or link for unsubscribe to the email. If it is an email address, the mailto: link will be automatically created when creating the document --> <unsubscribe> [email protected]</unsubscribe> <!--You can browse the URL of the email information --> <archive> http:/hi.clf.com/</archive> </mailingList> </mailingLists> <!--Project Developer List--> <developers> <!--Information of a project developer--> <developer> <!--Unique identifier of the project developer in SCM--> <id> HELLO WORLD </id> <!--Full name of the project developer--> <name> banseon </name> <!--Project Developer's email --> <email> [email protected]</email> <!--The URL of the project developer's homepage --> <url /> <!--The role played by the project developers in the project, the role elements describe various roles--> <roles> <role> Project Manager</role> <role> Architect </role> </roles> <!--The organization to which the project developer belongs--> <organization> demo</organization> <!--The URL of the organization to which the project developer belongs --> <organizationUrl>http://hi.clf.com/ </organizationUrl> <!--Project developer properties, such as how to handle instant messages, etc. --> <properties> <dept> No </dept> </properties> <!--The time zone where the project developer is located, an integer in the range -11 to 12. --> <timezone> -5</timezone> </developer> </developers> <!--The other contributors of the project --> <contributors> <!--Other contributors of the project. See developers/developer element --> <contributor> <name /> <email /> <url /> <organization /> <organizationUrl /> <roles /> <timezone /> <properties /> </contributor> </contributors> <!--This element describes all the license lists of the project. You should only list the license list for the project, and do not list the license list for the dependency project. --> <!--If multiple licenses are listed, the user can select one of them instead of accepting all licenses. --> <licenses> <!--Describes the license of the project, which is used to generate the license page of the web site of the project. Some other reports and validation will also use this element. --> <license> <!--license is used for legal name --> <name> Apache 2 </name> <!--The URL of the official license body page --> <url>http://www.clf.com/LICENSE-2.0.txt </url> <!--The main way of project distribution: repo, you can download manual from the Maven library, users must manually download and install dependencies --> <distribution> repo</distribution> <!--Supplementary information about license--> <comments> Abusiness-friendly OSS license </comments> </license> </license> <!--SCM(Source Control Management) tag allows you to configure your code base for use by Maven web sites and other plug-ins. --> <scm> <!--SCM URL, which describes the repository and how to connect to the repository. For more information, please see the URL format and list provided by SCMs. This connection is read-only. --> <connection>svn:http://svn.baidu.com/banseon/maven/</connection> <!--For developers, similar to connection elements. That is, the connection is not just read--> <developerConnection>scm:svn:http://svn.baidu.com/banseon/maven/ </developerConnection> <!--The tag of the current code is defaulted to HEAD in the development stage --> <tag /> <!--Point to the URL of the project's browsable SCM library (such as ViewVC or Fisheye). --> <url> http://svn.baidu.com/banseon</url> </scm> <!--Describe various attributes of the organization to which the project belongs. Use of documents generated by Maven --> <organization> <!--The full name of the organization --> <name> demo </name> <!--The URL of the organization homepage --> <url> http://www.clf.com/</url> </organization>
Summarize
The above is all the content of this article about the pom.xml configuration file in Maven. I hope it will be helpful to everyone. Interested friends can continue to refer to other related topics on this site. If there are any shortcomings, please leave a message to point it out.