基于上两篇的JavaWeb的笔记,进行的maven相关知识的补充
Maven 是一个强大的 项目依赖管理和构建工具,主要用于 Java 项目(但也支持其他语言)
一、Maven简介
1、为何需要Maven
1.1. 依赖管理(Dependency Management)
-
自动下载和管理库(JAR 文件):Maven 通过
pom.xml文件声明依赖,自动从中央仓库(如 Maven Central)下载所需的库,并处理传递性依赖(依赖的依赖)。 -
版本一致性:避免手动下载和管理 JAR 文件导致的版本冲突或缺失问题。
1.2. 标准化项目结构
-
Maven 强制约定了一套标准的项目目录结构(如
src/main/java、src/test/resources),使项目易于理解和维护,减少配置混乱。
1.3. 构建生命周期(Build Lifecycle)
-
提供预定义的构建阶段(如
compile、test、package、install、deploy),开发者只需执行简单命令(如mvn install)即可完成复杂的构建过程。 -
支持插件(Plugins)扩展功能(如编译、测试覆盖率、打包成 WAR/JAR)。
1.4. 跨平台一致性
-
基于 XML 的配置(
pom.xml)和命令行工具,确保不同开发环境(Windows/Linux/macOS)下的构建结果一致。
1.5. 集成测试与报告
-
内置单元测试支持(如 JUnit),可自动运行测试并生成报告。
-
集成插件(如 Surefire、Checkstyle)实现代码质量检查。
1.6. 多模块项目管理
-
支持将大型项目拆分为多个子模块(modules),通过父子
pom.xml管理依赖和构建顺序,提升代码复用性和维护性。
1.7. 与开发工具无缝集成
-
主流 IDE(如 IntelliJ IDEA、Eclipse)原生支持 Maven,可自动同步依赖和项目配置。
1.8. 生态系统支持
-
庞大的中央仓库和社区资源,几乎涵盖所有主流 Java 库(如 Spring、Hibernate)。
-
与 CI/CD 工具(Jenkins、GitLab CI)集成,便于自动化构建和部署。
2、GAVP
Maven 里,"GAVP" 并不是某个插件或新版本代号,而是对 pom.xml 中最核心的 4 个坐标(Coordinate)属性的统称:
2.1、G - groupId
组织/公司/业务线的唯一标识,习惯用反向域名,如 com.example.order。
2.2、A - artifactId
项目或模块在本组织下的唯一名称,如 user-service、pay-sdk。
2.3、V - version
当前构件的版本号,如 1.0.0、2.3.8-SNAPSHOT。
2.4、P - packaging(可选,默认为 jar)
打包类型:jar、war、pom、ear、maven-plugin 等。
只要这 4 项确定,Maven 就能在本地或远程仓库里唯一定位到一个构件,因此它们也被称为 Maven 坐标(Coordinate)。在多模块或父子工程中,通过 dependencyManagement、parent 等机制可以统一管理和继承这些坐标信息。
二、Maven安装和配置
下载前往https://maven.apache.org/download.cgi直接下载压缩包即可,以win11为例
原maven默认存储目录~/.m2/repository,现修改为E:\java\maven\repository
配置阿里云的加速

将原先的已拉取的依赖重新拉取


这之后才会重新拉取依赖,下载插件等等
三、基于IDEA创建Maven工程
0、maven工程的项目结构
PROJECT_ROOT
├── pom.xml # 项目对象模型、项目管理核心文件(唯一必须)
├── src
│ ├── main # 主源码/资源
│ │ ├── java # Java 源文件(package 结构展开)
│ │ ├── resources # 主 classpath 资源(xml、properties、yml…)
│ │ ├── filters # 资源过滤文件(*.properties 变量替换,极少用)
│ │ └── webapp # Web 项目才出现:jsp、static、WEB-INF/web.xml …
│ ├── test # 测试源码/资源
│ │ ├── java # 单元测试类(JUnit/TestNG …)
│ │ ├── resources # 测试 classpath 专用资源(logback-test.xml 等)
│ │ └── filters # 测试资源过滤文件
│ └── it # 可选,仅当使用 failsafe 插件做集成测试时出现
│ └── java # 集成测试源码(*IT.java)
├── target # Maven 构建输出(.gitignore 建议忽略)
│ ├── classes # 主代码编译结果
│ ├── test-classes # 测试代码编译结果
│ ├── generated-sources # 注解处理器、jaxb、wsdl 等生成的源码
│ ├── maven-archiver # 打包辅助文件
│ ├── surefire-reports # 单元测试报告
│ ├── failsafe-reports # 集成测试报告
│ └── *.jar / *.war / *.ear # 最终构件
└── README.md / .gitignore / … # 其他项目级文件
1、创建maven的Java工程
2、创建maven的web工程
将当前maven的Java工程的打包方式从jar包改为war包即可
同时还需要添加web.xml文件
四、基于IDEA进行Maven工程项目构建
依赖的寻找可在https://mvnrepository.com/进行搜索
我们已知maven是一个帮助我们进行项目构建和依赖管理的工具,那么什么是项目的构建呢
1、项目构建的概念和过程
项目构建是将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程,在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
项目构建是软件开发过程中至关重要的一部分,它能够大大提高软件开发效率,使得开发人员能够更加专注于应用程序的开发和维护,而不必关心应用程序的构建细节。
同时,项目构建还能够将多个开发人员的代码汇合到一起,并能够自动化项目的构建和部署,大大降低了项目的出错风险和提高开发效率。常见的构建工具包括 Maven、Gradle、Ant 等。
典型 Maven/Java 项目的构建生命周期包括:
-
清理(clean)删除上一次构建生成的
target目录,确保从零开始。 -
验证 & 生成(validate / generate-sources)检查环境、依赖是否完整;通过注解处理器、wsdl2java、protobuf 等生成额外源码。
-
编译(compile)把
src/main/java下的.java编译成.class,输出到target/classes。 -
测试编译 + 运行单元测试(test-compile / test)编译
src/test/java并在 surefire 插件里跑 JUnit/TestNG,失败即终止构建。 -
打包(package)把
target/classes打成 jar/war/ear,也可内嵌依赖(spring-boot-maven-plugin 打可执行 fat-jar)。 -
集成测试(integration-test)启动真实数据库、Docker 容器或嵌入式 Tomcat,用 failsafe 跑 *IT.java,验证接口与切片场景。
-
检查(verify)跑静态质量规则(SpotBugs、Checkstyle、PMD、Sonar),不达标就失败。
-
安装(install)把构件安装到本地仓库
~/.m2/repository,供本机其他项目复用。 -
部署(deploy)把构件上传到远程私服(Nexus/Artifactory),团队或 CI 服务器都能拿到同一份交付物。
以上构建过程通过maven插件进行实现
2、常见构建命令
2.1、命令行使用
必须在含pom.xml文件的路径下使用命令行才可进行以下mvn构建操作
# 清理
mvn clean # 删除 target 目录
# 编译
mvn compile # 只编译主源码即核心程序
mvn test-compile # 可编译测试程序
# 跑单元测试
mvn test # 先 compile → test-compile → 运行 src/test/java
# 打包
mvn package # 先 test → 打包为 jar/war 包
# 安装到本地仓库
mvn install # 先 package → 写入 ~/.m2/repository
# 上传到远程私服
mvn deploy # 先 install → 推到 Nexus/Artifactory
# 跳过测试(提速)
mvn package -DskipTests # 编译测试类但不运行
mvn package -Dmaven.test.skip=true # 连测试类都不编译
# 指定模块/多线程
mvn install -pl user-service -am # 只构建 user-service 及其依赖
mvn -T 1C install # 每核一个线程并行构建
2.2、可视化界面使用
可视化界面即idea中右侧栏中的maven,点击选择其中的生命周期,包含多个命令选择
注意Maven 跑单元测试时,类能被 Surefire 扫到 + 方法带 @Test(JUnit4 或 JUnit5) 这两条同时满足,该方法才会被当成真正的测试方法执行;缺任何一步都会“静默忽略”。
如何确保类能被 Surefire 扫到
-
路径必须落在 src/test/java主代码
src/main/java里的类就算叫FooTest.java也永远不会被 Surefire 执行。(特例:surefire 的testSourceDirectory被手动改到 main,但没人这么干) -
类名必须匹配 Surefire 默认 include 模板
**/Test*.java 例:TestUserService.java **/*Test.java 例:UserServiceTest.java **/*Tests.java 例:UserServiceTests.java **/*TestCase.java 例:UserServiceTestCase.java不符合就扫不到,跟有没有
@Test无关。类名不满足以上模式 → 根本不会进 JVM,方法里就算有 100 个@Test也被忽略例:HelloValidation.java即使放在 test/java 且方法带@Test,也不会执行。 -
想扫自定义名字 → 在
pom.xml显式告诉 Surefire<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.2.5</version> <configuration> <!-- 白名单 --> <includes> <include>**/*Should.java</include> <include>**/spec/*Spec.java</include> </includes> <!-- 也可以排除 --> <excludes> <exclude>**/manual/*Manual.java</exclude> </excludes> </configuration> </plugin> </plugins> </build> -
多级模块工程 → 在当前模块的
src/test/java下建类父模块执行mvn test时,Surefire 会分别到每个子模块的target/test-classes去扫;把测试类放到src/main/java或者别的模块目录,同样不会被当前模块的 Surefire 发现。
如果要打war包可能会由于jdk版本和war包版本不匹配而报错,可在pom.xml手动添加新版本打包插件
3、构建配置
3.1、自定义最终名称
原默认不指定的最终名称使用的是artifactId+version+.war/.jar,可使用在build中添加finalName修改最终名称
<build>
<finalName>yourfinalname</finalName> <!-- 填入你的自定义的最终名称 -->
</build>
3.2、自定义打包范围
原只按照规则,在src/main/java目录下的xml文件在进行打包操作时是不添加的,现为了符合某些特定场景可使用在build中加include修改
<build>
<resources>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
</build>
3.3、提升插件版本
可用于提升插件版本,如提高打包插件、提高tomcat版本、提高JDK版本等等,在build中的plugin添加配置即可
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
</plugins>
</build>
补充:
Lombok常用注解
| 注解 | 作用 | 隐含生成 |
|---|---|---|
@Data | 综合注解 | getter / setter / toString / equals / hashCode / requiredArgsConstructor |
@Getter / @Setter | 单独生成 get 或 set | 可放在类或字段上 |
@ToString | 重写 toString() | 默认打印所有字段;@ToString(exclude = "pwd") 可排除 |
@EqualsAndHashCode | 重写 equals & hashCode | 默认用全部字段;of = {"id"} 可指定 |
@NoArgsConstructor | 无参构造 | 必须有无参时(如 ORM、JSON) |
@AllArgsConstructor | 全参构造 | 所有字段做参数 |
@RequiredArgsConstructor | 必填参构造 | 仅 final 或 @NonNull 字段 |
@Value | 不可变实体 | 类级别 |

<!-- junit5版本,注意和junit4的G、A对比 -->
<!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
</dependency>
<!-- junit4版本 -->
<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
Junit5常用注解
| 注解 | 说明 |
|---|---|
@Test | 标记测试方法 |
@BeforeEach / @AfterEach | 每个测试前后执行 |
@BeforeAll / @AfterAll | 当前类所有测试前后各执行一次(static) |
@Disabled | 临时禁用测试 |
@ParameterizedTest + @ValueSource / @CsvSource / @MethodSource | 多组数据驱动 |
使用junit的单元测试,需要先引入junit的依赖,在src.main.java下进行测试创建,使用@Test注解,命名必须是public void
常见junit5断言
| 场景 | 示例 |
|---|---|
| 相等 | assertEquals(3, result); |
| 不相等 | assertNotEquals("A", str); |
| 布尔真 | assertTrue(list.isEmpty()); |
| 布尔假 | assertFalse(flag); |
| 空指针 | assertNull(obj); |
| 非空 | assertNotNull(obj); |
| 同一引用 | assertSame(a, b); |
| 不同引用 | assertNotSame(a, b); |
| 异常断言(官方推荐) | assertThrows(IllegalArgumentException.class, () -> service.divide(1,0)); |
| 超时 | assertTimeout(ofSeconds(1), () -> slowService.go()); |
| 全部失败 | fail("不该走到这里"); |
五、基于IDEA进行Maven工程依赖管理
依赖的寻找可在https://mvnrepository.com/进行搜索
我们已知maven是一个帮助我们进行项目构建和依赖管理的工具,那么什么是依赖的管理呢
1、依赖管理的概念
Maven依赖管理是Maven软件中最重要的功能之一。Maven的依赖管理能够帮助开发人员自动解决软件包依赖问题,使得开发人员能够轻松地将其他开发人员开发的模块或第三方框架集成到自己的应用程序或模块中,避免出现版本冲突和依赖缺失等问题。
我们通过定义POM文件,Maven能够自动解析项目的依赖关系,并通过Maven仓库自动下载和管理依赖,从而避免了手动下载和管理依赖的繁琐工作和可能引发的版本冲突问题。
总之,Maven的依赖管理是Maven软件的一个核心功能之一,使得软件包依赖的管理和使用更加智能和方便,简化了开发过程中的工作,并提高了软件质量和可维护性。
2、基本依赖配置
<properties>
<maven.compiler.source>24</maven.compiler.source>
<maven.compiler.target>24</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- 可在 properties 中自定义属性 -->
<project.test.version>5.3.8</project.test.version>
</properties>
<dependencies>
<!-- 一个依赖项的配置 -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<!-- 依赖范围 -->
<scope>test</scope>
</dependency>
<!-- 另一个依赖项 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<!-- 使用${}自定义属性管理,可统一版本等 -->
<version>${project.test.version}</version>
<!-- 依赖范围,不写默认是compile -->
</dependency>
<!-- 另一个依赖项 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${project.test.version}</version>
</dependency>
</dependencies>
Maven 定义了以下几种依赖范围,可设置对应jar 包的作用范围(编译环境、测试环境、运行环境),控制依赖在不同构建阶段的可用性:
| Scope | 描述 | 示例 |
|---|---|---|
| compile | 默认范围,在所有阶段都可用,会打包到最终产物中, 编译依赖范围,scope 元素的缺省值。使用此依赖范围的 Maven 依赖,对于三种 classpath 均有效,即该 Maven 依赖在上述三种 classpath 均会被引入。例如,log4j 在编译、测试、运行过程都是必须的。 | Spring Core |
| provided | 表示 JDK 或容器会提供该依赖,编译和测试时可用,但不会打包, 已提供依赖范围。使用此依赖范围的 Maven 依赖,只对编译 classpath 和测试 classpath 有效。例如,servlet-api 依赖对于编译、测试阶段而言是需要的,但是运行阶段,由于外部容器已经提供,故不需要 Maven 重复引入该依赖。 | Servlet API |
| runtime | 编译时不需要,但在运行和测试时需要,会打包到最终产物中, 运行时依赖范围。使用此依赖范围的 Maven 依赖,只对测试 classpath、运行 classpath 有效。例如,JDBC 驱动实现依赖,其在编译时只需 JDK 提供的 JDBC 接口即可,只有测试、运行阶段才需要实现了 JDBC 接口的驱动。 | JDBC 驱动 |
| test | 仅在测试编译和执行阶段可用,不会打包到最终产物中 。使用此依赖范围的 Maven 依赖,只对测试 classpath 有效。例如,Junit 依赖只有在测试阶段才需要。 | JUnit |
| system | 类似于 provided,但需要显式指定本地系统路径, 系统依赖范围,其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖,通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低,一般不推荐使用。 | 本地特殊 JAR |
| import | 仅用于 <dependencyManagement> 部分,从其他 POM 导入依赖管理, 导入依赖范围,该依赖范围只能与 dependencyManagement 元素配合使用,其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中 | BOM 导入 |
3、依赖项下载错误处理
在使用 Maven 构建项目时,可能会发生依赖项下载错误的情况,主要原因有以下几种:
-
下载依赖时出现网络故障或仓库服务器宕机等原因,导致无法连接至 Maven 仓库,从而无法下载依赖。
-
依赖项的版本号或配置文件中的版本号错误,或者依赖项没有正确定义,导致 Maven 下载的依赖项与实际需要的不一致,从而引发错误。
-
本地 Maven 仓库或缓存被污染或损坏,导致 Maven 无法正确地使用现有的依赖项。
解决方案:
-
检查网络连接和 Maven 仓库服务器状态。
-
确保依赖项的版本号与项目对应的版本号匹配,并检查 POM 文件中的依赖项是否正确。
-
清除本地 Maven 仓库缓存(lastUpdated 文件),因为只要存在 lastUpdated 缓存文件,刷新也不会重新下载。本地仓库中,根据依赖的 GAV 属性依次向下查找文件夹,最终删除内部的文件,刷新重新下载即可!
4、依赖传递
Maven 会自动解析和下载依赖的依赖(传递性依赖):
-
如果 A 依赖 B,B 依赖 C,那么 A 会自动依赖 C
-
传递依赖的范围会受到主依赖范围的影响(范围传递规则)
4.1、compile 范围依赖
-
会传递所有 compile 范围的依赖
-
传递的依赖在依赖链中保持 compile 或降级为 runtime
A(compile) -> B(compile) -> C(compile)
结果:A会直接依赖C(compile)
4.2、provided 范围依赖
-
传递的依赖会保持 provided 范围
-
不会传递给 test 或 provided 范围外的依赖
A(provided) -> B(compile) -> C(compile)
结果:A会直接依赖C(provided)
4.3、runtime 范围依赖
-
传递的依赖会保持 runtime 范围
-
不会传递给 test 范围的依赖
A(runtime) -> B(compile) -> C(compile)
结果:A会直接依赖C(runtime)
4.4、test 范围依赖
-
不会传递任何依赖
A(test) -> B(compile) -> C(compile)
结果:A不会依赖C
4.5、特殊传递情况
可选依赖(optional)
-
如果依赖被标记为
<optional>true</optional>,则不会传递
<dependency>
<groupId>com.example</groupId>
<artifactId>optional-lib</artifactId>
<version>1.0</version>
<optional>true</optional>
</dependency>
5、依赖冲突
依赖冲突通常表现为以下两种形式:
-
相同库的不同版本:比如同时存在 log4j 1.2.17 和 2.14.1
-
不同库包含相同类:比如多个库都包含
org.apache.commons.StringUtils类
当出现依赖版本冲突时,Maven 使用以下规则:
-
最近定义优先:在依赖树中,离项目最近的版本会被使用(即最短路径优先)
-
最先声明优先:如果在同一 POM 中声明了相同深度的多个版本,先声明的优先

可以使用 mvn dependency:tree 命令查看依赖树来分析冲突。
可使用exclusion来进行手动排除特定冲突标签
<dependency>
<groupId>groupA</groupId>
<artifactId>artifactA</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>冲突的groupId</groupId>
<artifactId>冲突的artifactId</artifactId>
</exclusion>
</exclusions>
</dependency>
六、Maven工程的继承和聚合关系
1、POM 继承 (Inheritance)
继承是指子模块从父POM继承配置,实现配置复用。
特点:
-
逻辑层面的配置共享
-
通过
<parent>元素定义 -
子POM可以覆盖父POM的配置
-
常用于统一管理依赖版本、插件配置等
<!-- 父工程 -->
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<version>1.0.0</version>
<!-- 由于这是父工程,不需要写Java代码不参与打包,所以设置打包方式为 pom -->
<packaging>pom</packaging>
<!-- 公共依赖管理 -->
<!-- 如果直接使用 dependencies 而不是 dependencyManagement 则默认其中所有依赖子工程无条件继承 -->
<!-- 如果使用 dependencyManagement 则需要子工程手动选择继承 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
<!-- 公共插件配置 -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
在该父工程下创建子工程
<project>
<modelVersion>4.0.0</modelVersion>
<!-- 指定父POM -->
<parent>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<version>1.0.0</version>
<relativePath>../pom.xml</relativePath> <!-- 父POM路径 -->
</parent>
<artifactId>module-a</artifactId>
<!-- 不需要groupId和version,因为子工程的这两个要和父工程的groupId和version保持一致 -->
<dependencies>
<!-- 可以省略version,从dependencyManagement继承 -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
</project>
2、POM 聚合 (Aggregation)
聚合是指通过一个父项目(通常称为"聚合器")来统一构建多个模块。即父工程聚合多个子工程,子工程同步父工程的操作
特点:
-
物理层面的组织方式
-
通过
<modules>元素定义 -
聚合POM本身可以没有代码,只负责组织模块
-
执行聚合POM的命令会作用于所有模块
使用场景:
-
统一构建多个相关项目
-
保持模块间一致的构建顺序
-
简化多模块项目的命令执行
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<version>1.0.0</version>
<!-- 由于这是父工程,不需要写Java代码不参与打包,所以设置打包方式为 pom -->
<packaging>pom</packaging> <!-- 必须为pom -->
<modules>
<module>module-a</module> <!-- 写的是子工程的路径 -->
<module>module-b</module>
<module>module-c</module>
</modules>
</project>
七、Maven私服
私服(Private Repository)是Maven架构中的关键组件,它是架设在局域网的私有仓库服务器,用于代理远程仓库和部署内部构件。
1、私服的作用与价值
-
加速构建:缓存远程仓库内容,减少外网下载
-
离线访问:内部开发不依赖外网连接
-
安全控制:管理内部依赖的访问权限
-
统一管理:集中存储公司内部构件
-
发布控制:规范第三方依赖的引入
-
持续集成:与CI/CD流程深度集成
2、主流私服解决方案
2.1、 Nexus Repository
类型:最流行的企业级方案
特点
-
支持Maven、npm、Docker等多种格式
-
提供OSS(免费)和Pro(商业)版本
-
界面友好,功能全面
-
支持高可用集群部署
2.2、 JFrog Artifactory
类型:功能强大的商业解决方案
特点
-
支持几乎所有包格式
-
高级安全控制和审计功能
-
与CI/CD工具深度集成
-
提供SaaS和自托管版本
2.3、 Apache Archiva
类型:轻量级开源方案
特点
-
配置简单
-
基础功能完备
-
社区支持较少
3、Maven私服优势
-
节省外网带宽
缓存中央仓库构件,消除重复下载,大幅降低出口流量。
-
下载更快更稳
私服部署在局域网,走内网流量,延迟低、不掉线。
-
托管第三方私有构件
无法公开的 JAR(Oracle JDBC、内部 SDK)可手动上传到私服,供全公司使用。
-
提升构建稳定性与可控性
外网中断也能本地构建;同时支持权限、RELEASE/SNAPSHOT 策略等高级管控。
-
减轻中央仓库负荷
缓存后不再向中央仓库发起相同请求,间接为 Maven 生态“减负”。
2066

被折叠的 条评论
为什么被折叠?



