1, Two ways to judge the version of jar
In Maven, the role of dependency management is actually equivalent to a manager for version management of dependent jar packages. It is the default dependency information inherited from all subprojects of the project.
pom. There are two ways to judge the version of jar in XML file:
-
If the dependency in the dependencies does not declare a version element, maven will go to the dependency management to find out whether the artifact ID and groupId have been declared. If so, inherit it. If not, an error will be reported, telling you that you must declare a version for the dependency
-
If the dependency in dependencies declares version, the version in dependency shall prevail regardless of whether there is a version declaration for the jar in dependency management.
pom.xml
//It only manages the version and does not actually introduce jar s
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.2.7</version>
</dependency>
</dependencies>
</dependencyManagement>
//Will actually download the jar package
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
</dependencies>
2, Significance of dependency management
In maven multi module project, in order to maintain the unity of dependencies among modules, the general practice is to use dependency management in the parent model to predefine the dependencies required by all modules, and then introduce the predefined dependencies in the parent in the sub model according to the actual needs
Benefits:
1. Dependency unified management (defined in the parent, the dependency version needs to be changed, just modify one place);
2. The code is concise (the sub model only needs to specify groupId and artifactId)
3. Dependency management will only affect the configuration of existing dependencies, but will not introduce dependencies, that is, the child model will not inherit all the predefined dependencies of dependency management in the parent, but only introduce the required dependencies, which is simply "import dependencies on demand" or "inherit on demand"; Therefore, it is strictly forbidden to directly use dependency predefined dependencies in the parent. The disadvantage is that the sub model will automatically inherit all predefined dependencies in dependency;
Note:
1. maven's inheritance is the same as java, single inheritance, that is, only one parent tag can appear in the sub model;
2. maven's dependencies are transitive. In order to solve the compatibility problem, we use exclusions to exclude the dependencies that cause the compatibility problem. Exclusions are configured in a specific dependency.
3, packaging tag configuration
<?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">
<modelVersion>4.0.0</modelVersion>
<groupId>com.t.test.center</groupId>
<artifactId>test-centerr</artifactId>
<version>1.0-SNAPSHOT</version>
<!--In the parent project packaging General configuration pom-->
<packaging>pom</packaging>
<name>test-center</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<!--Project sub module-->
<modules>
<module>test-module1</module>
<module>test-module2</module>
<module>test-module3</module>
</modules>
The default type of packaging is jar. If no configuration is made, maven will type the project into jar packages. Packaging types of common projects: pom, jar, war:
- pom ----------- > all parent types are pom types
- Jar ----------- > internal call or service use
- War ----------- > projects to be deployed (generally related to web)
Summary: the packaging method in the parent project is generally configured as pom. pom means that there is no java code in the project and no code is executed. It is only for aggregation engineering or dependency transfer.
4, Maven build tag
1. In Maven's POM In the XML file, there are two < build >:
(1) Global configuration (project build)
It is effective for all situations of the whole project, including the basic build element and two special elements, namely <... Directory > and < extensions >.
(2) Configuration (profile build)
For different profile configurations, basic build elements are included.
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<!-- "Project Build" contains elements of the BaseBuild set and the Build set-->
<!--First global configuration( project build)-->
<build>
<!-- implement build When a task is, if no target is specified, the default value of is used.-->
<defaultGoal>install</defaultGoal>
<!-- build The storage directory of the target file. It is in by default ${basedir}/target catalogue-->
<directory>${basedir}/target</directory>
<!--build The name of the target file. The default is ${artifactId}-${version}-->
<finalName>${artifactId}-${version}</finalName>
/**Definition * The properties file contains a list of properties that will be applied to resources that support filter. In other words, the name=value key value pair defined in the filter file will be applied to resources instead of ${name} value in the build era. The default filter folder for maven is ${basedir}/src/main/filters **/
<filters><filter>filters/filter1.properties</filter> </filters>
...
</build>
<!--Another configuration( profile build)-->
<profiles>
<profile>
<!-- "Profile Build" contains elements of the BaseBuild set only -->
<build>...</build>
</profile>
</profiles>
</project>
Summary: there are more elements in the build tag. For more, please refer to the blog post POM XML file details: https://blog.csdn.net/weixin_47061482/article/details/109817802
2. Resources configuration and plugins configuration commonly used in < build >
There are many elements in the build tag. Here we focus on the following common configurations:
- Resources configuration
Used to include or exclude certain resource files - plugins configuration
Used to specify which plug-ins to use
Common code snippets eg:
<build>
<!-- Load those files-->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<!-- in the light of spring-boot of maven pack,executable Indicates whether to make an executable file-->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.1.6.RELEASE</version>
<configuration>
<executable>false</executable>
</configuration>
</plugin>
<!-- maven Pack into war package,If it's old web In theory, the project must have web.xml,If there is no choice, report the error,however springboot No web.xml,So no verification-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.3</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- Class file compilation level and encoding format-->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<!-- Configuration file encoding format-->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
Next, let's take a look at these configurations
(1) Resources configuration:
<build>
...
<resources>
<resource>
<targetPath>META-INF/plexus</targetPath>
<filtering>true</filtering>
<directory>${basedir}/src/main/plexus</directory>
<includes>
<include>configuration.xml</include>
</includes>
<excludes>
<exclude>**/*.properties</exclude>
</excludes>
</resource>
</resources>
<testResources>
...
</testResources>
...
</build>
1)resources
A list of resources elements. Each describes what and where the files associated with the project are
2)targetPath
Specify the folder where the built resource is stored. The default is basedir.
The target path of resources usually packaged in jar is META-INF
3)filtering
true/false indicates whether the resource filter is activated
4)directory
Define the folder where the resource file is located. The default is ${basedir}/src/main/resources
5)includes
Specify which files will be matched, using * as a wildcard
6)excludes
Specify which files will be ignored
7)testResources
The definition is similar to resource, except it is used in test
(2)Plugins,pluginManagement:
pluginManagement is generally used to define in the parent POM and provide it to the child POM. The child POM can also override this definition. Moreover, after you define the version in the parent POM, groupId and artifact ID are directly applied in the child module without specifying the version. At the same time, it is also convenient for unified management; pluginManagement in the parent POM does not involve Maven's life cycle.
plugins is to directly introduce a plugin, which can be bound to Maven related life cycle.
pluginManagement is mainly used to manage plug-ins uniformly and ensure that the versions of plug-ins used by all sub POM S are consistent, similar to dependencies and dependency management.
<!--eg:father pom-->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1</version>
<configuration>
<attach>true</attach>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<!--eg:son pom-->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>