The original:www.yuque.com/uy2gee/yfyp…

Maven configuration

Maven configuration takes effect

Default: Configuration takes effect (overwrite from front to back, merge different configurations)

  • Settings. XML in the ~ /.m2 file

  • Conf /settings.xml in the locally installed Apache Maven file

  • Project in pom. XML

Its essence: If we specify the maven settings. XML path in IDEA, then ~ /.m2/settings. XML will not take effect. If we specify the maven settings. XML path in IDEA, then ~ /.m2/settings. XML will not take effect

Profile mechanism in Pom

A profile does not normally take effect unless it is specified to activate it.

Configuration:

<profiles> <profile> <id>dev</id> <properties> <! -- Environment --> <spring.profiles. Active >dev</spring.profiles. Active > </properties> <activation> <! -- Enabled by default --> <activeByDefault>true</activeByDefault> </activation> </profile> </profiles>Copy the code

Effective mode:

-p Specifies the MVN install -pdev parameter

Default boot parameter always on: activeByDefault

IDEA development tool check:

Maven’s dependency mechanism

Coordinate mechanism

GroupId + artifactId + Version + Packaging + classifier: coordinates of five dimensions to uniquely locate a dependent package

For any project, a distribution is uniquely positioned with these five dimensions

In fact, the latter two dimensions are rarely used. In 99% of scenarios, only three dimensions, groupId + artifactId + Version, are used to locate a dependency

GroupId: indicates the organization ID

ArtifactId: indicates the project module ID

Version:

The version number

SNAPSHOT: The version suffixed with SNAPSHOT is unstable and will be pulled from the repository every time it is packed. The deploy version can be overwritten all the time. Other versions are release versions and cannot be overwritten after deploy.

Packaging:

Currently, the following configurations are supported:

<packaging>pom</packaging>
<packaging>jar</packaging>
<packaging>war</packaging>
Copy the code

The time tag used when referencing

Classifier:

< the dependency > < groupId > org. Hibernate < / groupId > < artifactId > hibernate - hikaricp < / artifactId > < version > 1.0.0 < / version > <type>jar</type> <classifier>jdk8</classifier> </dependency>Copy the code

For example, hibernate- hikarICP-1.0.0-jdk8.jar

Introduction of depend on

Find the dependency website: mvnrepository.com/

Examples of dependent coordinates:

< the dependency > < groupId > org. Hibernate < / groupId > < artifactId > hibernate - hikaricp < / artifactId > < version > 1.0.0 < / version > <type>jar</type> <scope>test</scope> <optional>true</optional> <classifier></classifier> </dependency>Copy the code

Optional:

true

The dependency pass is invalid and will not be passed up

If A depends on B, B depends on C, and B’s dependence on C is optional, then A won’t depend on C. On the other hand, if there were no optional, A would depend on C by transitive dependency.

Scope:

Maven has a classpath for compiling source code; There is a classpath for compiling and executing test code; When you run a project, you have a classpath; Dependency scopes are used to control the relationship of dependency packages to the three classpath types.

You can set the following parameters:

Compile: Default, valid for compile, test, and running classpath. This kind of scope is generally used

Test: valid only for the classpath where the test code is being run, not when the main code is being compiled or run. Dependencies that only test code needs are generally set to this range, such as junit. Some test frameworks, or dependencies that are used only in the test code, will be set to test. The advantage of this is that the test scope dependencies will not be included in the final release package when packaged. Reduce the volume of published packages.

Provided: this is available at compile and test time, but not at run time, because the environment may already provide it, such as servlet-API, which is generally in this scope. At run time, the servlet container will provide dependencies. Servlet-api is used to develop Java Web projects. You may need to declare this servlet-API dependency in POM.xml when you are developing code and performing unit tests because you are writing and testing code. However, when you finally complete the package and run it into the Tomcat container, you don’t need to put the servlet-API dependencies into the distribution, because the Tomcat container will provide you with servlet-API packages.

Runtime: Classpath is valid for testing and running, but not for compiling code such as JDBC driver implementation classes such as mysql drivers. Because the code is written based on the standard interface in the Javax. SQL package. The javax. SQL interface is all you need for compilation, not the mysql driver class. When declaring mysql drivers, we don’t set it to Runtime because you may be developing code that uses the mysql driver specific API, not just javax.sql.

The system:

The dependency is the same as provided except that it is not extracted from the Maven repository, but from the local file system, which extracts the dependency with reference to the systemPath properties.

Import:

This attribute is available after Maven 2.0.9. Import can only be used in dependencyManagement. Import dependencies do not actually limit transitivity of dependencies.

Depend on the transfer

For example, A->B->C->X(1.0), A->D->X(2.0), A has two transitive dependencies on X, different versions

In this case, we rely on mediation, the proximity principle, and the closest choice to A is the 2.0 version of X

If A->B->X(1.0) and A->D->X(2.0),

The path is the same length then the first declaration principle will be chosen, whichever dependency is declared first in POM.xml will be used

Eliminating transitive dependencies

<dependency> <groupId>org.hibernate</groupId> <artifactId> hibernate-hikarICP </artifactId> <version>1.0.0</version> <! --> <exclusions> <artifactId> slf4J-log4j12 </artifactId> <groupId>org.slf4j</groupId> </exclusion> </exclusions> </dependency>Copy the code

Rely on the conflict

why

Older versions of dependencies do not take effect because of the mechanism by which they are passed.

The solution

1, use MVN Dependency :tree to check the dependency path. Where are the conflicting jars referenced

2. Then identify one of the higher-version jars

3. Use the above method to exclude pass-through dependencies for that or that lower version of the JAR

Maven’s warehouse

Introduction of several warehouses

Local warehouse:

Function:

For a cache repository of a remote repository, packages used are pulled from the remote repository to the local repository for use.

Configuration:

The default address is ~.m2/repository

This can be specified via /User/c/maven/repository in setting.xml

The repository address can also be specified in IDEA via Maven’s Settings

Central warehouse:

Generally refers to the default maven centralrepo.maven.apache.org/maven2 warehouse, configuration in (maven – model – builder – 3.6.3 jar: Org, apache maven. Model. Pom – 4.0.0. XML), the central warehouse and the other, such as jboss, but rarely used.

Private servers:

Function:

Build their own private service in the enterprise, to manage their own warehouse

Configuration:

Configuration in settrings. XML or pem. XML in a project is available in two ways: </repositories> </repositories> Configure repository by profile <profile> < ID >nexus</ ID > <repositories> </repositories> </profile>Copy the code

Mirror warehouse:

Function:

Repositorie of the image configuration to change the URL of the repository to that of the image configuration.

Configuration:

<mirrors>
	<mirror>
    <id>aliyun-maven</id>
    <mirrorOf>central</mirrorOf>
    <name>Nexus aliyun</name>
    <url>https://maven.aliyun.com/repository/public</url>
  </mirror>
</mirrors>
Copy the code

MirrorOf: Specifies the ID of the repository to be mirrored. Multiple repositories are separated by commas (,). Central is maven’s default central repository address. The URL configured for the mirrored repository will be invalid.

Warehouse configuration takes effect

There are two main types of Settings: Settings files and POM files

There are two configuration modes:

Configure repository directly </repositories> </repositories> Configure repository through profile <profile> < ID > Nexus </ ID ></repositories> </profile>Copy the code

There are two kinds of principles:

Settings is better than that of pom

The profile is better than that of the repositories

Situation:

settings:profile -> pom:profile -> setting:repositories -> pom:repositories

Upload warehouse configuration

Maven determines whether the module version is a SNAPSHOT version or an official version based on whether the module version number (the version number in the POM file) contains -snapshot.

pom.xml <distributionManagement> <repository> <! --> <id> Nexus -releases</id> <name> Maven-releases </name> The < url > http://192.168.1.15:8081/repository/maven-releases/ < / url > < layout > default < / layout > <! -- Specify the version when uploading. Default is version --> <! - < uniqueVersion > 1.0.0 < / uniqueVersion > -- > < / repository > < snapshotRepository > < id > nexus - snapshots < / id > < name > maven - snapshots < / name > < url > http://192.168.1.15:8081/repository/maven-snapshots/ < / url > < layout > < / layout > <uniqueVersion></uniqueVersion> </snapshotRepository> </distributionManagement> setting.xml <servers> <server> <id>nexus-release</id> <username>admin</username> <password>admin</password> </server> <server> <id>nexus-snapshots</id>  <username>admin</username> <password>admin</password> </server> </servers>Copy the code

Nexus private server build use

Download and install

To baidu

Enterprise private server gameplay

Several core repository functions in nexus

Common warehouses are shown as follows:

Maven-releases: Stores the package of the company Releases version.

Maven-snapshots: Snapshots saved in front of your company.

Maven-central: Proxy for the central repository (aliyun)

Maven-public: Group the above repositories. You can pull packages from all the repositories in the group through this repository.

Maven-public configure gameplay:

Permissions system

Nexus has two default accounts, admin and Anonymous.

Admin: has management rights, can pull, upload, delete, management nexus background

Anonymous: An anonymous user. When we do not provide the account password, we use this anonymous account by default. The account can only be pulled. It is also possible to turn off anonymous users in this setting so that all operations on our private server must be logged in

Rights management

Set whether anonymous accounts are supported

Setting a Scheduled Task

Configure scheduled tasks for the repository, such as deleting incomplete uploads and unused snapshots

Maven Life Cycle

There are three life cycles: Clean, Default, and Site

Phase, Plugin, and Goal in the lifecycle

Complete maven lifecycle and the default configuration: www.processon.com/view/link/6…

There are three life cycles, and each life cycle corresponds to a fixed phase with corresponding execution sequence. Plugin is corresponding to the phase, and GOAL is a function point of plugin. During configuration, the goal of a plugin will be specified to the corresponding phase. Phase and Plugin and goal are many-to-many relationships.

Plugin is configured in conjunction with the lifecycle

pom.xml <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> < artifactId > spring - the boot - maven - plugin < / artifactId > < version > 2.1.1. RELEASE < / version > <! Executions --> <executions> <executions> <executions> <executions> <executions> <executions> <executions> <executions> <executions> <executions> <configuration> <skipTests>true</skipTests> </configuration> </plugin> </plugins> </build>Copy the code

Use the plugin, goal approach

mvn plugin:goal

Example:

mvn compiler:compile

A goal that executes the plugin alone will only execute this goal, regardless of the lifecycle

Archetype about engineering skeleton

To baidu

Enterprise use cases

The aggregation function realizes multiple modules

To baidu

Multi-module dependency version unification

Parent POM.xml <properties> <hutool.version>2.4.1.10</hutool.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>${hutool.version}</version> </dependency> </dependencies> </dependencyManagement> <! <plugins> <plugins> </plugins> </plugins> </plugins> </plugins> </plugins> <dependency> <! Hutool </groupId> <artifactId>hutool-all</artifactId> </dependency> </dependencies> <plugins> <plugin> </plugin> </plugins>Copy the code

The resource filtering +profile function automatically ADAPTS to each publishing environment

pom.xml
<build>
	<resources>
    <resource>
      <directory>src/main/resources</directory>
      <excludes>
        <exclude>application*.properties</exclude>
      </excludes>
    </resource>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
      <includes>
        <include>application.properties</include>
        <include>application-${spring.profiles.active}.properties</include>
      </includes>
    </resource>
  </resources>
</build>
<profiles>
  <profile>
    <id>dev</id>
    <properties>
      <spring.profiles.active>dev</spring.profiles.active>
    </properties>
  </profile>
</profiles>
Copy the code