Advanced usage of Maven sub-module-inheritance-aggregation-private server

Advanced usage of Maven sub-module-inheritance-aggregation-private server

JavaWeb knowledge, introduce the advanced usage of Maven! ! !

Maven is a tool for building and managing Java projects . When it is necessary to develop some medium and large projects, it is difficult to cope with the basic knowledge of Maven learned earlier. You also need to learn some advanced functions provided by Maven, which are also used a lot when building and managing Java projects.

Maven Advanced Content includes:

• Sub-module design and development
• Inheritance and Aggregation
• private server

1. Sub-module design and development

1.1 Introduction

The so-called sub-module design, as the name implies, means that when we design a Java project, we split a Java project into multiple modules for development.

1). The problem of undivided module design

If the project is not divided into modules, it means that all business codes are written in this Java project. With the business expansion of this project, there may be more and more business functions in the project.

If we are developing a large-scale e-commerce project, it may include the functions of the commodity module, the function of the search module, the shopping cart module, the order module, the user center, and so on. We write all these business codes in a Java project.

At this point, you can imagine that if we are developing a large-scale e-commerce website, the project team will have at least dozens or even hundreds of developers, and all of these developers will operate this Java project. At this time, everyone will find that our project management and maintenance will be very difficult. And let’s look at it again, if in our project, we define some common tool classes and common components, and the company has other project teams, other project teams also want to use these components and tool classes we encapsulate , which is actually very inconvenient. Because the Java project contains all the business codes of the current project, some components encapsulated in it will be difficult to reuse.

To sum up, there are two main problems: inconvenient project maintenance and management, and common components in the project are difficult to reuse.

2). Sub-module design

Sub-module design When we are in the project design stage, we can split a large project into several modules, and each module is independent.

For example, we can put the related functions of the product in the product module, and I encapsulate the related business functions of the search in the search module, as well as the shopping cart module and the order module. For the reuse of components, we can also extract the entity classes, tool classes, and common components we define into a module separately.

If the current module, such as the order module, needs to use these entity classes and tool classes or these general components, it is enough to directly introduce the coordinates of the tool class into the order module. In this way, we split a project into several modules, which is the sub-module design.

After the sub-module design, let's take a look. When we are doing project management, I can work in groups of several people, a few people are in charge of the order module, and a few other people are in charge of the shopping cart module, which is more convenient for project management and later maintenance of the project.

And after the sub-module design, if we need to use the function of another module, we can directly rely on the module. For example, the product module, search module, and shopping cart order module all need to rely on some tool classes encapsulated in the general component. I only need to introduce the coordinates of the general component.

The sub-module design is to split the project into several sub-modules according to the function/structure, which facilitates the management, maintenance and expansion of the project, and also facilitates the mutual calling of module keys and resource sharing.

1.2 Practice

1.2.1 Analysis

• Option 1: directly rely on our current project tlias-web-management, but there are two major disadvantages:

  • This project contains all business function codes, and the resources to be shared are only entity classes under pojo and tool classes under utils. If all dependencies are included, all classes will be loaded when the project starts, which will affect performance .
  • If we directly depend on this project, it means that all our business codes are exposed to the outside world, which is very unsafe .

• Solution 2: Sub-module design

  • Extract the entity classes under the pojo package into a maven module tlias-pojo
  • Extract the tool classes under the utils package into a maven module tlias-utils
  • Other business codes are placed in the tlias-web-management module. In this module, the entity class pojo and tool class utils are needed, and the corresponding dependencies can be directly introduced.
    

​Note : The development of sub-modules needs to be designed for the module functions first, and then coded. The project will not be developed first and then split.

​ PS: At present, we are demonstrating the development of sub-modules, so we split them based on the case projects we developed earlier. In fact, they are designed by sub-modules and then developed.

1.2.2 Implementation

After we have analyzed the ideas, next, we will split them according to the following modules according to the ideas we analyzed:

1. Create a maven module tlias-pojo to store entity classes

A. Create a normal Maven module, the module name is tlias-pojo

B. Then create a package com.iheima.pojo in tlias-pojo (same as the pojo package name in the original case project)

C. Copy the entity classes under the pojo package in the original case project tlias-web-management to the tlias-pojo module

D. Introduce dependencies in the pom.xml file of the tlias-pojo module

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

E. Delete the pojo package of the original case project tlias-web-management [do not hesitate to delete it directly, we have already split the module], and then introduce the dependency of tlias-pojo in pom.xml

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>tlias-pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

2. 创建Maven模块 tlias-utils，存放相关工具类

A. 创建一个正常的Maven模块，模块名tlias-utils

B. 然后在 tlias-utils 中创建一个包 com.itheima.utils (和原来案例项目中的utils包名一致)

C. 将原来案例项目 tlias-web-management 中的utils包下的实体类，复制到tlias-utils模块中

D. 在 tlias-utils 模块的pom.xml文件中引入依赖

<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <version>0.9.1</version>
    </dependency>

    <!--阿里云OSS-->
    <dependency>
        <groupId>com.aliyun.oss</groupId>
        <artifactId>aliyun-sdk-oss</artifactId>
        <version>3.15.1</version>
    </dependency>
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.3.1</version>
    </dependency>
    <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
        <version>1.1.1</version>
    </dependency>
    <!-- no more than 2.3.3-->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.3</version>
    </dependency>

    <!--WEB开发-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.7.5</version>
    </dependency>

    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

E. 删除原有案例项目tlias-web-management的utils包【直接删除不要犹豫，我们已经将该模块拆分出去了】，然后在pom.xml中引入 tlias-utils的依赖

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>tlias-utils</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

到此呢，就已经完成了模块的拆分，拆分出了 tlias-pojo、tlias-utils、tlias-web-management ，如果其他项目中需要用到 pojo，或者 utils工具类，就可以直接引入依赖。

1.3 总结

1). 什么是分模块设计：将项目按照功能拆分成若干个子模块

2). 为什么要分模块设计：方便项目的管理维护、扩展，也方便模块间的相互调用，资源共享

3). 注意事项：分模块设计需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分

2. 继承与聚合

在案例项目分模块开发之后啊，我们会看到tlias-pojo、tlias-utils、tlias-web-management中都引入了一个依赖 lombok 的依赖。我们在三个模块中分别配置了一次。

如果是做一个大型的项目，这三个模块当中重复的依赖可能会很多很多。如果每一个 Maven 模块里面，我们都来单独的配置一次，功能虽然能实现，但是配置是比较繁琐的。

而接下来我们要讲解的 Maven 的继承用来解决这问题的。

2.1 继承

我们可以再创建一个父工程 tlias-parent ，然后让上述的三个模块 tlias-pojo、tlias-utils、tlias-web-management 都来继承这个父工程 。 然后再将各个模块中都共有的依赖，都提取到父工程 tlias-parent中进行配置，只要子工程继承了父工程，依赖它也会继承下来，这样就无需在各个子工程中进行配置了。

• 概念：继承描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承。

• 作用：简化依赖配置、统一管理依赖

• 实现：

  <parent>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
      <relativePath>....</relativePath>
  </parent>
  

这是我们在这里先介绍一下什么是继承以及继承的作用，以及在 maven 当中如何来实现这层继承关系。接下来我们就来创建这样一个 parent 父工程，我们就可以将各个子工程当中共有的这部分依赖统一的定义在父工程 parent 当中，从而来简化子工程的依赖配置。接下来我们来看一下具体的操作步骤。

我们在这里先介绍一下什么是继承以及继承的作用，以及在 maven 当中如何来实现这层继承关系。接下来我们就来创建这样一个 parent 父工程，我们就可以将各个子工程当中共有的这部分依赖，统一的定义在父工程 parent 当中，从而来简化子工程的依赖配置。

2.1.1 继承关系

2.1.1.1 思路分析

我们当前的项目 tlias-web-management，还稍微有一点特殊，因为是一个springboot项目，而所有的springboot项目都有一个统一的父工程，就是spring-boot-starter-parent。 与java语言类似，Maven不支持多继承，一个maven项目只能继承一个父工程，如果继承了spring-boot-starter-parent，就没法继承我们自己定义的父工程 tlias-parent了。

那我们怎么来解决这个问题呢？

At this time, you can think about it. Although Java does not support multiple inheritance, it can support multiple inheritance. For example: A inherits B, and B inherits C. Maven also supports multiple inheritance, so we can let the three modules we created inherit tlias-parent, and tlias-parent inherits spring-boot-starter-parent, that's it. The specific structure is as follows:

2.1.1.2 Implementation

1). Create the maven module tlias-parent, which is the parent project, and set the packaging method pom (default jar).

The project structure is as follows:

The pom.xml file configuration of the parent project tlias-parent is as follows:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.5</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<groupId>com.itheima</groupId>
<artifactId>tlias-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>

Maven packaging method:

• jar: Common module packaging, springboot projects are basically jar packages (embedded tomcat running)
• war: common web program packaging, need to be deployed in the external tomcat server to run
• pom: parent project or aggregation project, this module does not write code, only for dependency management

2). In the pom.xml file of the sub-project, configure the inheritance relationship.

<parent>
    <groupId>com.itheima</groupId>
    <artifactId>tlias-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../tlias-parent/pom.xml</relativePath>
</parent>

<artifactId>tlias-utils</artifactId>
<version>1.0-SNAPSHOT</version>

Here we take tlias-utils as an example, specifying its parent project. Other modules are configured in the same way.

Notice:

• In the sub-project, after the inheritance relationship is configured, the groupId in the coordinates can be omitted, because it will automatically inherit the parent project.
• relativePath specifies the relative location of the pom file of the parent project (if not specified, the project will be searched from the local warehouse/remote warehouse).
  • .../ represents the parent directory

3). Configure the common dependencies of each project in the parent project (the child project will automatically inherit the dependencies of the parent project).

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

At this point, we have defined the common dependencies (lombok) in each sub-project in the parent project, and this dependency in the sub-project can be deleted directly. After deletion, we will see the dependency lombok configured in the parent project, and the child project is directly inherited.

Engineering structure description:

• Our current project structure is:

  

Because after the project development is completed, we will give you each module split based on the existing project, tlias-web-management already exists, and then create each module and the parent project, so the parent project and the module are at the same level.

• In actual projects, you may also see the following engineering structure:

  

In real enterprise development, the modules are designed first, and then the modules are created and the projects are developed. At this time, the parent project tlias-parent is generally created first, and then the created sub-modules are placed under the parent project parent. This will make the hierarchical structure clearer.

​

PS: The above two engineering structures can be used normally without any problem. However, for the second structure, it seems that the parent-child project structure is clearer and more intuitive.

2.1.2 Version Locking

2.1.2.1 Scenarios

If this part of the dependency is common in all modules in the project, we can directly define it in the parent project, thus simplifying the configuration of the sub-project. However, in project development, there are still some dependencies that are not shared by all modules, and may only be used in a small number of modules.

For example: in the three subprojects of tlias-web-management, tlias-web-system, and tlias-web-report, jwt dependencies are used. But tlias-pojo and tlias-utils do not need this dependency. At this time, we will not directly configure this dependency in the parent project tlias-parent, but configure it in whichever module needs it.

And because there are multiple modules in a project, the version of the same dependency we want to use in those multiple modules must be consistent, which facilitates the unified management of project dependencies. For example: this jwt dependency, we all use the version 0.9.1.

So if we want to upgrade our project and use a new function in the latest version 0.9.2 of jwt, then we need to upgrade the dependent version to 0.9.2, what should we do at this time?

Step 1: Find the pom.xml configuration files of all modules in the current project to see which modules use jwt dependencies.

Step 2: After finding this dependency, replace its version with 0.9.2.

Problem: If the project is divided into many modules, every time we change the version, we have to find every module in the project and change them one by one. It is easy to miss a module and forget to change the version.

Then how do we solve this problem, how to manage the versions of each dependency in a unified way?

Answer: Maven's version locking feature.

2.1.2.2 Introduction

In maven, <dependencyManagement>the dependency version can be managed uniformly in the pom file of the parent project.

Parent project:

<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Subproject:

<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
    </dependency>
</dependencies>

Notice:

• The configuration in the parent project <dependencyManagement>can only manage the dependency version uniformly, and will not directly introduce this dependency. This <dependencies>is different from .

• To use this dependency, the sub-project still needs to be imported, but at this time there is no need to specify <version>the version number, and the parent project is managed uniformly. To change the dependent version, you only need to unify the changes in the parent project.

2.1.2.3 Implementation

Next, we can hand over the versions of the dependencies configured separately in the tlias-utils module to tlias-parent for unified management.

Specific steps are as follows:

1). Configuration in tlias-parent

<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>

        <!--阿里云OSS-->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>3.15.1</version>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1.1</version>
        </dependency>
        <!-- no more than 2.3.3-->
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>2.3.3</version>
        </dependency>
    </dependencies>
</dependencyManagement>

2). pom.xml configuration in tlias-utils

If the dependent version has been managed uniformly in the parent project, there is no need to configure the dependent version in the sub-project.

<dependencies>
    <!--JWT令牌-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
    </dependency>

    <!--阿里云OSS-->
    <dependency>
        <groupId>com.aliyun.oss</groupId>
        <artifactId>aliyun-sdk-oss</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
    </dependency>
    <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
    </dependency>
    <!-- no more than 2.3.3-->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
    </dependency>

    <!--WEB开发-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

The reason why we often introduce dependency coordinates in the springboot project does not need to specify the version of the dependency <version>, because the parent project spring-boot-starter-parent has already carried out <dependencyManagement>unified management and maintenance on the version of the dependency.

2.1.2.4 Property configuration

We can also centrally manage and maintain the dependent version number in the parent project through custom properties and property references. The specific syntax is:

1). Custom attributes

<properties>
	<lombok.version>1.18.24</lombok.version>
</properties>

2). Reference property

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>${lombok.version}</version>
</dependency>

Next, we can centrally manage and maintain all version numbers in the parent project.

<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

    <lombok.version>1.18.24</lombok.version>
    <jjwt.version>0.9.1</jjwt.version>
    <aliyun.oss.version>3.15.1</aliyun.oss.version>
    <jaxb.version>2.3.1</jaxb.version>
    <activation.version>1.1.1</activation.version>
    <jaxb.runtime.version>2.3.3</jaxb.runtime.version>
</properties>


<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
    </dependency>
</dependencies>

<!--统一管理依赖版本-->
<dependencyManagement>
    <dependencies>
        <!--JWT令牌-->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>${jjwt.version}</version>
        </dependency>

        <!--阿里云OSS-->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>${aliyun.oss.version}</version>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>${jaxb.version}</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>${activation.version}</version>
        </dependency>
        <!-- no more than 2.3.3-->
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>${jaxb.runtime.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

After centralized version management, if we want to modify the dependent version, we only need to customize the position of the property in the parent project and modify the corresponding property value.

Interview Question: What is the difference <dependencyManagement>between and <dependencies>?

• <dependencies>It is a direct dependency. If the dependency is configured in the parent project, the child project will directly inherit it.
• <dependencyManagement>It is a unified management dependency version, not directly dependent, but also needs to introduce the required dependencies in the sub-project (no need to specify the version)

2.2 Aggregation

分模块设计与开发之后啊，我们的项目被拆分为多个模块，而模块之间的关系，可能错综复杂。 那就比如我们当前的案例项目，结构如下（相对还是比较简单的）：

此时，tlias-web-management 模块的父工程是 tlias-parent，该模块又依赖了tlias-pojo、tlias-utils模块。 那此时，我们要想将 tlias-web-management 模块打包，是比较繁琐的。因为在进行项目打包时，maven会从本地仓库中来查找tlias-parent父工程，以及它所依赖的模块tlias-pojo、tlias-utils，而本地仓库目前是没有这几个依赖的。

所以，我们再打包tlias-web-management 模块前，需要将 tlias-parent、tlias-pojo、tlias-utils分别执行install生命周期安装到maven的本地仓库，然后再针对于 tlias-web-management 模块执行package进行打包操作。

那此时，大家试想一下，如果开发一个大型项目，拆分的模块很多，模块之间的依赖关系错综复杂，那此时要进行项目的打包、安装操作，是非常繁琐的。 而我们接下来，要讲解的maven的聚合就是来解决这个问题的，通过maven的聚合就可以轻松实现项目的一键构建（清理、编译、测试、打包、安装等）。

2.2.1 介绍

• **聚合：**将多个模块组织成一个整体，同时进行项目的构建。
• **聚合工程：**一个不具有业务功能的“空”工程（有且仅有一个pom文件） 【PS：一般来说，继承关系中的父工程与聚合关系中的聚合工程是同一个】
• **作用：**快速构建项目（无需根据依赖关系手动构建，直接在聚合工程上构建即可）

2.2.2 实现

在maven中，我们可以在聚合工程中通过 <moudules> 设置当前聚合工程所包含的子模块的名称。我们可以在 tlias-parent中，添加如下配置，来指定当前聚合工程，需要聚合的模块：

<!--聚合其他模块-->
<modules>
    <module>../tlias-pojo</module>
    <module>../tlias-utils</module>
    <module>../tlias-web-management</module>
</modules>

那此时，我们要进行编译、打包、安装操作，就无需在每一个模块上操作了。只需要在聚合工程上，统一进行操作就可以了。

**测试：**执行在聚合工程 tlias-parent 中执行 package 打包指令

那 tlias-parent 中所聚合的其他模块全部都会执行 package 指令，这就是通过聚合实现项目的一键构建（一键清理clean、一键编译compile、一键测试test、一键打包package、一键安装install等）。

2.3 继承与聚合对比

• 作用

  • 聚合用于快速构建项目

  • 继承用于简化依赖配置、统一管理依赖

• 相同点：

  • 聚合与继承的pom.xml文件打包方式均为pom，通常将两种关系制作到同一个pom文件中

  • 聚合与继承均属于设计型模块，并无实际的模块内容

• 不同点：

  • 聚合是在聚合工程中配置关系，聚合可以感知到参与聚合的模块有哪些

  • 继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己

3. 私服

前面我们在讲解多模块开发的时候，我们讲到我们所拆分的模块是可以在同一个公司各个项目组之间进行资源共享的。这个模块的资源共享，就需要通过我们接下来所讲解的 Maven 的私服来实现。

首先我们先介绍一下什么是私服，以及它的作用是什么。再来介绍一下我们如何将每位模块打包上传到私服，以及从私服当中来下载。

3.1 场景

在介绍什么是私服之前，我们先来分析一下同一个公司，两个项目组之间如何基于私服进行资源的共享。

假设现在有两个团队，A 和 B。 A 开发了一个模块 tlias-utils，模块开发完毕之后，将模块打成jar包，并安装到了A的本地仓库。

那此时，该公司的B团队开发项目时，要想使用 tlias-utils 中提供的工具类，该怎么办呢？ 对于maven项目来说，是不是在pom.xml文件中引入 tlias-utils的坐标就可以了呢？

大家可以思考一下，当B团队在maven项目的pom.xml配置文件中引入了依赖的坐标之后，maven是如何查找这个依赖的？ 查找顺序为：

1). 本地仓库：本地仓库中是没有这个依赖jar包的。

2). 远程中央仓库：由于该模块时自己公司开发的，远程仓库中也没有这个依赖。

因为目前tlias-utils这个依赖，还在A的本地仓库中的。 B电脑上的maven项目，是不可能找得到A电脑上maven本地仓库的jar包的。 那此时，大家可能会有一个想法：因为A和B都会连接中央仓库，我们可以将A本地仓库的jar包，直接上传到中央仓库，然后B从中央仓库中下载tlias-utils这个依赖。

这个想法很美好，但是现实很残酷。这个方案是行不通的，因为中央仓库全球只有一个，不是什么人都可以往中央仓库中来上传jar包的，我们是没有权限操作的。

那此时，maven的私服就出场了，私服其实就是架设在公司局域网内部的一台服务器，就是一种特殊的远程仓库。

有了私服之后，各个团队就可以直接来连接私服了。 A 连接上私服之后，他就可以把jar包直接上传到私服当中。我公司自己内部搭建的服务器，我是不是有权限操作呀，把jar包上传到私服之后，我让 B 团队的所有开发人员也连接同一台私服。连接上这一台私服之后，他就会根据坐标的信息，直接从私服当中将对应的jar包下载到自己的本地仓库，这样就可以使用到依赖当中所提供的一些工具类了。这样我们就可以通过私服来完成资源的共享。

而如果我们在项目中需要使用其他第三方提供的依赖，如果本地仓库没有，也会自动连接私服下载，如果私服没有，私服此时会自动连接中央仓库，去中央仓库中下载依赖，然后将下载的依赖存储在私服仓库及本地仓库中。

3.2 介绍

• **私服：**是一种特殊的远程仓库，它是架设在局域网内的仓库服务，用来代理位于外部的中央仓库，用于解决团队内部的资源共享与资源同步问题。
• 依赖查找顺序：
  • 本地仓库
  • 私服仓库
  • 中央仓库
• **注意事项：**私服在企业项目开发中，一个项目/公司，只需要一台即可（无需我们自己搭建，会使用即可）。

3.3 资源上传与下载

3.3.1 步骤分析

资源上传与下载，我们需要做三步配置，执行一条指令。

第一步配置：在maven的配置文件中配置访问私服的用户名、密码。

The second step of configuration: configure the address (url address) to connect to the private server in the maven configuration file.

The third step of configuration: configure the location (url address) of the uploaded resource in the pom.xml file of the project.

After configuring the above three steps, to upload resources to the private server warehouse, execute the maven life cycle: deploy.

Description of private server warehouse:

• RELEASE: Store the resources of the RELEASE release version developed by yourself.
• SNAPSHOT: Store the resources of the SNAPSHOT release version developed by yourself.
• Central: Stores the dependencies downloaded from the central warehouse.

Project release notes:

• RELEASE (release version): The function tends to be stable, the current update is stopped, and the version that can be used for release is stored in the RELEASE warehouse in the private server.
• SNAPSHOT (snapshot version): The version with unstable functions and still under development, that is, the snapshot version, is stored in the SNAPSHOT warehouse of the private server.

3.3.2 Concrete operation

In order to simulate enterprise development, here I have prepared a server (192.168.150.101), the private server has been set up, we can visit the private server for testing: http://192.168.150.101:8081 [Unable to access ]

After the private server is ready, we need to configure the following steps:

1. Set the access username/password of the private server (configured in servers in conf/settings.xml in your own maven installation directory)

<server>
    <id>maven-releases</id>
    <username>admin</username>
    <password>admin</password>
</server>
    
<server>
    <id>maven-snapshots</id>
    <username>admin</username>
    <password>admin</password>
</server>

2. Set the address of the warehouse group that the private server depends on downloading (configure in mirrors and profiles in conf/settings.xml in your own maven installation directory)

<mirror>
    <id>maven-public</id>
    <mirrorOf>*</mirrorOf>
    <url>http://192.168.150.101:8081/repository/maven-public/</url>
</mirror>

<profile>
    <id>allow-snapshots</id>
        <activation>
        	<activeByDefault>true</activeByDefault>
        </activation>
    <repositories>
        <repository>
            <id>maven-public</id>
            <url>http://192.168.150.101:8081/repository/maven-public/</url>
            <releases>
            	<enabled>true</enabled>
            </releases>
            <snapshots>
            	<enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>

3. Configure the upload (release) address in the pom file of IDEA's maven project (configure the release address directly in tlias-parent)

<distributionManagement>
    <!-- release版本的发布地址 -->
    <repository>
        <id>maven-releases</id>
        <url>http://192.168.150.101:8081/repository/maven-releases/</url>
    </repository>

    <!-- snapshot版本的发布地址 -->
    <snapshotRepository>
        <id>maven-snapshots</id>
        <url>http://192.168.150.101:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

After the configuration is complete, we can execute the deploy life cycle in tlias-parent and publish the project to the private server warehouse.

Through the logs, we can see that the jar packages of these modules have indeed been uploaded to the private server warehouse (since our current project is a SNAPSHOT version, the jar packages are uploaded to the snapshot warehouse).

Then, let's open the private server again to take a look:

We see that these several modules in our project are available in the private server. Then, when the developers of other project teams are in the project, they can directly import the corresponding dependencies through the coordinates of the dependencies. At this time, if the local warehouse does not exist, it will be automatically downloaded from the private server warehouse.