黑马程序员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

学术论文避雷指南:paperxie 降重复 | AIGC 率 如何帮你规避毕业风险

学术论文避雷指南:paperxie 降重复 | AIGC 率 如何帮你规避毕业风险

paperxie-免费查重复率aigc检测/开题报告/毕业论文/智能排版/文献综述/aippt https://www.paperxie.cn/checkhttps://www.paperxie.cn/checkhttps://www.paperxie.cn/check 在学术写作高度依赖 AI 工具的今天,“重复率超标” 和 “AIGC 痕迹被检测” 已经成为当代大学生和科研人员的两大噩梦。无论是知网、维普的查重系统,还是最新升级的 AIGC 检测算法,都在不断收紧学术规范的边界。paperxie 平台推出的降重复 | AIGC 率功能,正以技术迭代应对检测升级,为用户打造一条安全的学术写作 “护城河”。 一、学术写作的隐形陷阱:重复率与 AIGC 检测的双重夹击 随着学术不端检测技术的飞速发展,传统的 “复制粘贴” 式抄袭早已无所遁形,但新的风险又随之而来:

解决anythingllm文件定位问题:从错误分析到Whisper模型路径优化

快速体验 在开始今天关于 解决anythingllm文件定位问题:从错误分析到Whisper模型路径优化 的探讨之前,我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来,但作为开发者,如何将大模型(LLM)真正落地为一个低延迟、可交互的实时系统,而不仅仅是调个 API? 这里有一个非常硬核的动手实验:基于火山引擎豆包大模型,从零搭建一个实时语音通话应用。它不是简单的问答,而是需要你亲手打通 ASR(语音识别)→ LLM(大脑思考)→ TTS(语音合成)的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说,这是个绝佳的练手项目。 从0到1构建生产级别应用,脱离Demo,点击打开 从0打造个人豆包实时通话AI动手实验 解决anythingllm文件定位问题:从错误分析到Whisper模型路径优化 当你在anythingllm项目中看到could not locate file: /static/stt/models/xenova/whisper-tiny/to这样的错误时,

企业级图像AIGC技术观察:Seedream 4.0 模型能力与应用场景分析

企业级图像AIGC技术观察:Seedream 4.0 模型能力与应用场景分析

引言:突破视觉创作的传统限制 在视觉内容的创作领域,长久以来存在着一系列由技术、时间及预算构成的严格限制。这些限制直接影响着创意从概念到最终呈现的全过程。一个富有创造力的设计师,可能会因为无法承担高昂的实地拍摄费用,而不得不放弃一个原本极具潜力的广告方案。一个构思了宏大世界观的故事作者,可能因为不具备操作复杂三维建模软件的专业技能,而使其笔下的角色无法获得具象化的视觉呈现。一家新兴的初创公司,也可能因为传统设计流程的冗长和低效,在快速变化的市场竞争中错失发展机会。 社会和行业在某种程度上已经习惯了这种因工具和流程限制而产生的“创意妥协”。创作者们在面对自己宏大的构想时,常常因为工具的局限性而感到无力。一种普遍的观念是,顶级的、具有专业水准的视觉呈现,是少数拥有充足资源和专业团队的机构或个人的专属领域。 然而,由豆包·图像创作模型Seedream 4.0所引领的技术发展,正在从根本上改变这一现状。它所提供的并非是对现有工具集的微小改进或功能补充,而是一种全新的、高效的创作工作模式。通过这一模式,过去需要专业团队投入数周时间才能完成的复杂视觉项目,现在可以在极短的时间内,在操作者的

Ollama+Llama-3.2-3B实战:零代码搭建文本生成服务

Ollama+Llama-3.2-3B实战:零代码搭建文本生成服务 1. 为什么选Llama-3.2-3B?轻量、多语、开箱即用 你是否试过部署一个大模型,结果卡在CUDA版本不匹配、PyTorch编译失败、依赖冲突报错的第7个环节? 你是否想快速验证一个文案创意、写一封工作邮件、生成产品简介,却不想打开网页、登录账号、等加载、再复制粘贴? 如果你点头了,那Llama-3.2-3B + Ollama 就是为你准备的——它不是“又要折腾环境”的新负担,而是“点一下就能说话”的文本生成服务。 这不是概念演示,也不是实验室玩具。Llama-3.2-3B由Meta发布,是真正经过指令微调(SFT)和人类反馈强化学习(RLHF)优化的30亿参数模型。它不追求参数堆砌,而专注实际可用性:支持中、英、法、西、德等10+语言;对中文理解扎实,