小菜鸟

maven私服

发表于 2021-09-28 更新于 2025-08-01 分类于 maven 阅读次数： Valine：
本文字数： 5.3k 阅读时长 ≈ 5 分钟

Maven 私服：基于 Nexus 的私有仓库搭建与使用指南

在团队开发中，Maven 私服是提升依赖管理效率的核心工具。它不仅能缓存中央仓库的依赖，还能存储团队内部的私有构件（如自研 Jar 包），避免重复下载，加速构建过程。本文将详细介绍如何使用 Nexus 搭建 Maven 私服，以及如何配置项目与私服交互。

什么是 Maven 私服？

Maven 私服是部署在本地网络中的私有仓库管理器，主要作用包括：

缓存公共仓库：代理 Maven 中央仓库、阿里云仓库等，减少外部网络依赖。
存储私有构件：团队内部开发的组件（如工具类 Jar 包）可部署到私服，供其他项目依赖。
版本管控：区分快照版（Snapshot）和发布版（Release）构件，规范版本管理。
权限控制：限制谁能上传 / 下载构件，保障代码安全。

最常用的私服工具是 Nexus Repository Manager，本文以 Nexus 为例讲解。

Nexus 仓库类型与内置仓库

Nexus 提供四种仓库类型，各司其职：

仓库类型	作用	典型场景
`group`（仓库组）	聚合多个仓库，提供统一访问入口	项目通过一个 URL 访问多个仓库（如同时访问中央仓库和私有仓库）
`hosted`（宿主仓库）	存储本地私有构件	部署团队自研的 Release 版或 Snapshot 版构件
`proxy`（代理仓库）	代理远程公共仓库，缓存下载的构件	代理 Maven 中央仓库、阿里云仓库等
`virtual`（虚拟仓库）	兼容 Maven 1 等旧版本仓库（极少使用）	适配 legacy 系统

Nexus 内置仓库（默认）

安装 Nexus 后，默认包含以下常用仓库：

仓库名称	类型	作用
`Maven Central`	proxy	代理 Maven 中央仓库（https://repo1.maven.org/maven2/），仅缓存 Release 版
`Releases`	hosted	存储团队内部的 Release 版构件（稳定版本，不可重复部署）
`Snapshots`	hosted	存储团队内部的 Snapshot 版构件（开发中版本，可重复部署）
`3rd party`	hosted	存储无法从公共仓库获取的第三方构件（如非开源 SDK）
`Public Repositories`	group	聚合所有 Release 策略的仓库（如 `Maven Central`、`Releases`、`3rd party`），提供统一访问 URL

Nexus 安装与初始化

安装 Nexus

下载：从 Nexus 官网下载最新版本（推荐使用 OSS 开源版）。
启动：
- 解压后进入 bin 目录，执行 nexus.exe /run（Windows）或 ./nexus run（Linux/Mac）。
- 访问 http://localhost:8081，默认端口可在 etc/nexus-default.properties 中修改。

首次登录

点击右上角 Sign in，默认用户名 admin。
密码存储在 sonatype-work/nexus3/admin.password 文件中，登录后需修改密码。

配置 Nexus 仓库（关键步骤）

开启远程索引（可选）

索引用于快速搜索仓库中的构件：

阅读全文 »

maven依赖

发表于 2021-09-28 更新于 2025-08-01 分类于 maven 阅读次数： Valine：
本文字数： 4.9k 阅读时长 ≈ 4 分钟

Maven 依赖管理：从基础配置到冲突解决

Maven 的核心功能之一是依赖管理，它通过标准化的方式管理项目所需的 Jar 包，自动处理依赖的下载、传递和版本控制。本文将详细讲解 Maven 依赖的配置、范围、传递性及冲突解决策略。

依赖的基本配置

Maven 依赖通过 pom.xml 中的 <dependencies> 标签管理，每个依赖通过 GAV 坐标 唯一标识：

<dependencies>
  <!-- 单个依赖配置 -->
  <dependency>
    <groupId>组织标识</groupId> <!-- 如 org.springframework.boot -->
    <artifactId>项目标识</artifactId> <!-- 如 spring-boot-starter-web -->
    <version>版本号</version> <!-- 如 2.7.0 -->
    <scope>依赖范围</scope> <!-- 如 compile、test，可选 -->
    <!-- 其他可选配置：exclusions、type 等 -->
  </dependency>
</dependencies>

GAV 坐标：groupId（组织）、artifactId（项目）、version（版本）三者组合唯一确定一个依赖，Maven 通过坐标从仓库下载 Jar 包。
版本规范：通常包含主版本（如 2）、次版本（如 7）、修订号（如 0），快照版以 -SNAPSHOT 结尾（如 2.7.0-SNAPSHOT）。

依赖范围（scope）

依赖范围控制依赖在 Maven 生命周期各阶段 的可见性（如编译、测试、运行），以及是否传递给下游项目。Maven 提供 6 种依赖范围：

范围	主程序编译	测试编译	主程序运行	测试运行	打包（如 Jar）	依赖传递性	典型场景
`compile`	✅	✅	✅	✅	✅	可传递	核心依赖（如 Spring 核心包）
`test`	❌	✅	❌	✅	❌	不可传递	测试框架（如 JUnit、Mockito）
`provided`	✅	✅	❌	✅	❌	不可传递	容器提供的依赖（如 Servlet API）
`runtime`	❌	✅	✅	✅	✅	可传递	运行时依赖（如 JDBC 驱动）
`system`	✅	✅	❌	✅	❌	不可传递	本地 Jar 包（需指定路径）
`import`	-	-	-	-	-	特殊处理	导入依赖管理配置（仅用于 `dependencyManagement`）

关键范围解析：

compile（默认）：
- 全程有效，是最常用的依赖范围。
- 例如：spring-core 需在编译、测试、运行阶段都存在。
test：
- 仅用于测试相关的代码（src/test/java）。
- 例如：junit-jupiter-api 仅在执行 mvn test 时需要。
provided：
- 编译和测试时需要，但运行时由容器（如 Tomcat）提供，避免打包冲突。
- 例如：javax.servlet-api 在 Tomcat 中已存在，无需打入项目 Jar/War。
runtime：
- 编译时不需要（代码不直接依赖其 API），但运行时必须存在。
- 例如：mysql-connector-java（JDBC 驱动，代码通过 JDBC 接口调用，编译时无需具体驱动）。

system：

与provided类似，但依赖不从 Maven 仓库下载，需通过systemPath指定本地路径：

<dependency>
  <groupId>com.example</groupId>
  <artifactId>local-sdk</artifactId>
  <version>1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/lib/local-sdk.jar</systemPath> <!-- 相对项目根目录的路径 -->
</dependency>

注意：不推荐使用，会导致项目移植性变差（需手动同步本地 Jar 包）。

import：
- 仅用于dependencyManagement中，导入其他 POM 的依赖管理配置：

阅读全文 »

maven常用命令

发表于 2021-09-28 更新于 2025-08-01 分类于 maven 阅读次数： Valine：
本文字数： 3.3k 阅读时长 ≈ 3 分钟

Maven 常用命令全解析：从基础到进阶操作

Maven 命令是项目构建和管理的核心工具，掌握常用命令能显著提升开发效率。本文将按功能分类梳理 Maven 命令，涵盖基础构建、依赖管理、项目创建、测试与发布等场景，并解释其底层原理和适用场景。

基础构建命令

这类命令对应 Maven 生命周期的核心阶段，用于完成项目的编译、测试、打包等基础操作。

命令	功能描述	底层原理
`mvn -v`	查看 Maven 版本及环境信息（如 Java 版本、安装路径）	输出 `maven-home`、`java-home` 等配置，验证 Maven 环境是否正确。
`mvn clean`	清理项目（删除 `target` 目录，即编译、打包生成的文件）	触发 `Clean` 生命周期的 `pre-clean` 和 `clean` 阶段，调用 `maven-clean-plugin:clean` 目标。
`mvn compile`	编译主程序源码（输出到 `target/classes`）	触发 `Default` 生命周期的 `compile` 阶段，调用 `maven-compiler-plugin:compile` 目标。
`mvn test-compile`	编译测试源码（输出到 `target/test-classes`）	触发 `test-compile` 阶段，调用 `maven-compiler-plugin:testCompile` 目标。
`mvn test`	执行单元测试（运行 `src/test/java` 中的测试用例）	触发 `test` 阶段，调用 `maven-surefire-plugin:test` 目标，默认生成测试报告到 `target/surefire-reports`。
`mvn package`	打包项目（如 Jar、War，输出到 `target` 目录）	触发 `package` 阶段，根据项目类型（`pom.xml` 中 `<packaging>`）调用对应插件（如 `maven-jar-plugin:jar`）。
`mvn install`	将包安装到本地仓库（供本地其他项目依赖）	触发 `install` 阶段，调用 `maven-install-plugin:install` 目标，将包复制到本地仓库（默认 `~/.m2/repository`）。
`mvn deploy`	将包部署到远程仓库（供团队共享）	触发 `deploy` 阶段，调用 `maven-deploy-plugin:deploy` 目标，需在 `pom.xml` 中配置 `<distributionManagement>` 远程仓库地址。

常用组合命令

# 清理并打包（跳过测试，适合快速构建）
mvn clean package -DskipTests

# 清理、编译、测试并安装到本地仓库
mvn clean install

# 部署到远程仓库（通常用于发布正式版本）
mvn clean deploy -Pprod  # -Pprod 激活生产环境 profile

阅读全文 »

maven生命周期

发表于 2021-09-28 更新于 2025-08-01 分类于 maven 阅读次数： Valine：
本文字数： 4.2k 阅读时长 ≈ 4 分钟

Maven 生命周期详解：从清理到部署的完整流程

Maven 的生命周期是其核心概念之一它定义了项目构建的标准化流程，从代码清理、编译、测试到打包、部署，每个环节都有明确的阶段和职责。理解生命周期有助于开发者掌握 Maven 构建的执行逻辑，高效管理项目流程。本文将系统解析 Maven 的三套套生命周期及其运作机制。

生命周期的本质

Maven 生命周期是一系列有序的阶段（Phase） 的集合，每个阶段代表构建过程中的一个特定步骤（如编译、测试）。其核心特点包括：

抽象定义：生命周期仅定义 “做什么”（如 compile 表示编译源码），不关心 “怎么做”。
插件实现：具体操作由插件的目标（Goal）完成，例如 compile 阶段由 maven-compiler-plugin:compile 目标执行。
顺序执行：执行某个阶段时，Maven 会自动执行该阶段之前的所有阶段。例如执行 mvn package 会先执行 validate、compile、test 等前置阶段。

三套核心生命周期

Maven 包含Clean、Default、Site 三套相互独立的生命周期，每套生命周期专注于不同的构建目标。

Clean 生命周期：清理项目

作用：删除上一次构建生成的文件（如 target 目录），为新构建做准备。

包含三个阶段，执行顺序如下：

阶段	含义	绑定的插件目标
`pre-clean`	清理前的准备工作（如备份文件）	无默认插件
`clean`	删除构建目录（默认 `target`）	`maven-clean-plugin:clean`
`post-clean`	清理后的收尾工作（如删除备份）	无默认插件

阅读全文 »

Hystrix线程隔离导致的问题

发表于 2021-09-28 更新于 2025-08-20 分类于微服务阅读次数： Valine：
本文字数： 4.2k 阅读时长 ≈ 4 分钟

Hystrix 线程隔离：线程池位置与跨线程上下文传递解析

Hystrix 的线程隔离是通过在调用方服务中维护独立线程池实现的，其核心目的是将不同依赖服务的调用隔离开，避免单个依赖的故障耗尽调用方的线程资源。同时，线程隔离会引入跨线程问题（如ThreadLocal上下文丢失），需通过自定义并发策略解决。

Hystrix 线程池的存在位置

Hystrix 的线程池存在于调用方服务（消费端） 中，由调用方为每个依赖的服务（或服务分组）维护一个独立的线程池。

例如：服务 A 调用服务 B 和服务 C，服务 A 会为服务 B 创建线程池 B，为服务 C 创建线程池 C。当服务 B 响应超时或故障时，线程池 B 的线程可能被耗尽，但线程池 C 仍能正常处理对服务 C 的调用，从而实现 “故障隔离”。

为什么线程池在调用方？

线程隔离的核心是保护调用方的资源不被依赖服务耗尽，因此线程池必须由调用方控制和维护；
若线程池在服务提供方，调用方仍可能因等待响应而耗尽自身线程，无法实现隔离目的。

跨线程上下文丢失问题：ThreadLocal 的 “陷阱”

问题场景

Web 应用中，RequestContextHolder通过ThreadLocal存储请求上下文（如用户登录信息、请求头），但 Hystrix 命令在独立线程池的线程中执行，与 Tomcat 的工作线程（主线程）属于不同线程，导致RequestContextHolder.getRequestAttributes()返回null。

阅读全文 »