黑马程序员java web学习笔记--后端进阶(三)Maven高级

目录

1 分模块设计与开发

2 继承与聚合

2.1 继承(简化依赖配置、统一管理依赖版本)

2.1.1 继承关系

2.1.2 版本锁定 

2.2 聚合 (快速构建项目,在父工程/聚合工程中配置聚合的模块)

maven 中继承与聚合的联系与区别?

3 私服


Maven 是一款构建和管理 Java 项目的工具

1 分模块设计与开发

分模块设计就是将项目按照功能/结构拆分成若干个子模块,方便项目的管理维护、拓展,也方便模块键的相互调用、资源共享。

  1. 策略一:按照功能模块拆分,比如:公共组件、商品模块、搜索模块、购物车模块、订单模块等。
  2. 策略二:按层拆分,比如:公共组件、实体类、控制层、业务层、数据访问层。
  3. 策略三:按照功能模块 + 层拆分。

eg:

注意:分模块开发需要先针对模块功能进行设计,再进行编码。不会先将工程开发完毕,然后进行拆分。

2 继承与聚合

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

若需要修改版本,则需要每一个都去修改,非常的繁琐,Maven的继承用来解决这个问题。

2.1 继承(简化依赖配置、统一管理依赖版本)

2.1.1 继承关系<parent>

创建一个父工程 tlias-parent ,然后让上述的三个模块 tlias-pojo、tlias-utils、tlias-web-management 都来继承这个父工程 。 然后再将各个模块中都共有的依赖,都提取到父工程 tlias-parent中进行配置。

作用:简化依赖配置、统一管理依赖。

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

Maven不支持多继承,一个maven项目只能继承一个父工程,如果tlias-web-management继承了spring-boot-starter-parent,就没法继承我们自己定义的父工程 tlias-parent了。

解决:自己创建的三个模块,都继承 tlias-parent,而 tlias-parent 再继承 spring-boot-starter-parent,就可以了。

Maven打包方式:jar:普通模块打包,springboot项目基本都是jar包(内嵌tomcat运行)。war:普通web程序打包,需要部署在外部的tomcat服务器中运行。pom:父工程或聚合工程,该模块不写代码,仅进行依赖管理。

创建maven模块 tlias-parent ,该工程为父工程,设置打包方式pom(默认jar)。

Maven 的继承关系实现步骤:

在父工程中配置各个工程的共有依赖。

在子工程中配置继承关系。
注意:
①在子工程中,配置了继承关系之后,坐标中的groupId是可以省略的,因为会自动继承父工程的 。
②relativePath指定父工程的pom文件的相对位置(如果不指定,将从本地仓库/远程仓库查找该工程)。其中../ 代表的上一级目录。
③若父子工程都配置了同一个依赖的不同版本,以子工程的为准。

创建父工程,设置打包方式为 pom。并继承 spring-boot-starter-parent。

工程结构说明:

实际项目中,可能还会见到下面的工程结构:tlias-parenttlias-pojotlias-utilstlias-web-management

而在真实的企业开发中,都是先设计好模块之后,再开始创建模块,开发项目。 那此时呢,一般都会先创建父工程 tlias-parent,然后将创建的各个子模块,都放在父工程parent下面。 这样层级结构会更加清晰一些。

2.1.2 版本锁定 <dependencyManagement> <properties>

问题:如果项目拆分的模块比较多,每一次更换版本,我们都得找到这个项目中的每一个模块,一个一个的更改。 很容易就会出现,遗漏掉一个模块,忘记更换版本的情况。那我们又该如何来解决这个问题,如何来统一管理各个依赖的版本呢?

答案:Maven的版本锁定功能。

在maven中,可以在父工程的pom文件中通过 <dependencyManagement> 来统一管理依赖版本。

  • 父工程:在父工程中所配置的 <dependencyManagement> 只能统一管理依赖版本,并不会将这个依赖直接引入进来。 这点和 <dependencies> 是不同的。
<!--统一管理依赖版本--> <dependencyManagement> <dependencies> <!--JWT令牌--> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> </dependencies> </dependencyManagement>
  • 子工程:子工程要使用这个依赖,还是需要引入的,只是此时就无需指定 <version> 版本号了,父工程统一管理。变更依赖版本,只需在父工程中统一变更。
<dependencies> <!--JWT令牌--> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> </dependency> </dependencies>

2.1.3 属性配置

通过自定义属性及属性引用的形式,在父工程中将依赖的版本号进行集中管理维护。

面试题:<dependencyManagement> 与 <dependencies> 的区别是什么?<dependencies> 是直接依赖,在父工程配置了依赖,子工程会直接继承下来。<dependencyManagement> 是统一管理依赖版本,不会直接依赖,还需要在子工程中引入所需依赖(无需指定版本)。

2.2 聚合<modules>(快速构建项目,在父工程/聚合工程中配置聚合的模块)

我们的项目被拆分为多个模块,而模块之间的关系错综复杂。

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的聚合就可以轻松实现项目的一键构建(清理、编译、测试、打包、安装等)。

  • 聚合:将多个模块组织成一个整体,同时进行项目的构建。
  • 聚合工程:一个不具有业务功能的“空”工程(有且仅有一个pom文件) 【PS:一般来说,继承关系中的父工程与聚合关系中的聚合工程是同一个】
  • 作用:快速构建项目(无需根据依赖关系手动构建,直接在聚合工程上构建即可)
<!--聚合哪些模块--> <modules> <module>../tlias-pojo</module> <module>../tlias-utils</module> <module>../tlias-web-management</module> </modules>

此时,maven面板也会发生改变,只剩下tlias-parent这个父工程。

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

maven 中继承与聚合的联系与区别?

联系:继承与聚合都属于设计型模块,打包方式都为 pom,常将两种关系制作到同一个 pom 文件中。

区别:继承用于简化依赖配置、统一管理依赖版本,是在子工程中配置继承关系。聚合用于快速构建项目,是在父工程(聚合工程)中配置聚合的模块。

3 私服

私服:是一种特殊的远程仓库,它是架设在局域网内的仓库服务,用来代理位于外部的中央仓库,用于解决团队内部的资源共享与资源同步问题。

依赖查找顺序:本地仓库~私服仓库~中央仓库

注意事项:私服在企业项目开发中,一个项目/公司,只需要一台即可(无需我们自己搭建,会使用即可)。

私服仓库说明:

  • RELEASE:存储自己开发的RELEASE发布版本的资源。
  • SNAPSHOT:存储自己开发的SNAPSHOT发布版本的资源。
  • Central:存储的是从中央仓库下载下来的依赖。

项目版本说明:

  • RELEASE(发布版本):功能趋于稳定、当前更新停止,可以用于发行的版本,存储在私服中的RELEASE仓库中。
  • SNAPSHOT(快照版本):功能不稳定、尚处于开发中的版本,即快照版本,存储在私服的SNAPSHOT仓库中。

https://heuqqdmbyk.feishu.cn/wiki/BPzFwIajLi8GXyk3JXmcLRYVn5c

Read more

【低代码+AI编程】GitHub Copilot各个模型区别,实现高效编程

【低代码+AI编程】GitHub Copilot各个模型区别,实现高效编程

Copilot AI模型对比说明 模型分类 🏆 高级模型 (需额外付费) 模型名称相对成本特点说明Claude Haiku 4.50.33x性价比最高,速度快,成本低Claude Sonnet 3.51.0x平衡性能与成本的主力模型Claude Sonnet 41.0x升级版本,能力更强Claude Sonnet 4.51.0x最新版本,综合表现优秀GPT-51.0x最强大旗舰,复杂推理能力顶尖Gemini 2.5 Pro1.0x超长上下文,适合处理大量文本 📊 标准模型 (包含在基础套餐内) 模型名称成本特点说明GPT-4.1免费GPT-4优化版本GPT-4o免费多模态专家,视觉语音交互强GPT-5 mini免费GPT-5轻量版,速度快Grok Code Fast 1免费编程专用,代码生成优化 选择指南 根据需求推荐: 🚀 日常使用 * 推荐:GPT-4o 或 GPT-5

AIGC时代——语义化AI驱动器:提示词的未来图景与技术深潜

AIGC时代——语义化AI驱动器:提示词的未来图景与技术深潜

文章目录 * 一、技术范式重构:从指令集到语义认知网络 * 1.1 多模态语义解析器的进化路径 * 1.2 提示词工程的认知分层 * 二、交互革命:从提示词到意图理解 * 2.1 自然语言交互的认知进化 * 2.2 专业领域的认知增强 * 三、未来技术图谱:2025-2030演进路线 * 3.1 2025年关键突破 * 3.2 2027年技术里程碑 * 3.3 2030年技术愿景 * 四、伦理与治理:构建可信语义化AI * 4.1 动态伦理约束框架 * 4.2 提示词审计系统 * 五、开发者能力升级路线图 * 5.1 核心技能矩阵 * 5.2 典型学习路径 * 结语 * 《驱动AI:

别把 F1 开成老头乐:GitHub Copilot 深度调教与 7 个“上下文工程”秘籍

别把 F1 开成老头乐:GitHub Copilot 深度调教与 7 个“上下文工程”秘籍

别把 F1 开成老头乐:GitHub Copilot 深度调教与 7 个“上下文工程”秘籍 前言 很多开发者抱怨 Copilot 生成的代码是“垃圾”或“幻觉”。真相是:Copilot 是一辆 F1 赛车,而大多数人只把它当成了自动挡的老年代步车。 本指南将揭示 Copilot 不为人知的底层机制,教你通过“上下文工程” (Context Engineering),让 AI 写出精准、规范的生产级代码。 核心心智模型:Copilot 是怎么“思考”的? 在学习技巧前,你需要理解 Copilot 的大脑构造。它不是在瞎猜,它是在根据你喂给它的“上下文(Context)”计算概率。 Copilot 的上下文由三层组成:

麦肯锡:2025智能体、机器人与人类—AI时代的技能伙伴关系研究报告

麦肯锡:2025智能体、机器人与人类—AI时代的技能伙伴关系研究报告

* 报告名称:2025智能体、机器人与人类:AI时代的技能伙伴关系研究报告(文末附下载) * 出 品 方:麦肯锡 人工智能正把“工作”重新定义为“人—智能体—机器人”的协作。现有技术已可理论上自动化美国57%的工时,但普及速度受成本、政策、组织惯性的制约。到2030年,若企业围绕“人+代理+机器人”重新设计工作流程而非零散自动化任务,美国可释放约2.9万亿美元价值。技能需求正在剧变:AI相关技能两年增长7倍,数字与信息处理技能最易被自动化,而护理、教练等以人为本的技能最稳定。工作不会消失,但任务组合、技能应用方式将深刻重组。 第一章 未来的劳动力 一、AI正在突破“只能做预设动作”的旧边界。传统机器按规则运行,新一代智能体和机器人通过海量数据学习,可理解自然语言、适应环境。技术潜力上,美国现有工时57%可被现有AI+