台州建设工程信息网站,佛山网站建设推荐,杭州市住房和城乡建设厅网站,合肥seoMaven分模块-继承-聚合-私服的高级用法 JavaWeb知识#xff0c;介绍Maven的高级用法#xff01;#xff01;#xff01; 文章目录 Maven分模块-继承-聚合-私服的高级用法1. 分模块设计与开发1.1 介绍1.2 实践1.2.1 分析1.2.2 实现 1.3 总结 2. 继承与聚合2.1 继承2.1.1 继承…Maven分模块-继承-聚合-私服的高级用法 JavaWeb知识介绍Maven的高级用法 文章目录 Maven分模块-继承-聚合-私服的高级用法1. 分模块设计与开发1.1 介绍1.2 实践1.2.1 分析1.2.2 实现 1.3 总结 2. 继承与聚合2.1 继承2.1.1 继承关系2.1.1.1 思路分析2.1.1.2 实现 2.1.2 版本锁定2.1.2.1 场景2.1.2.2 介绍2.1.2.3 实现2.1.2.4 属性配置 2.2 聚合2.2.1 介绍2.2.2 实现 2.3 继承与聚合对比 3. 私服3.1 场景3.2 介绍3.3 资源上传与下载3.3.1 步骤分析3.3.2 具体操作 Maven 是一款构建和管理 Java 项目的工具在需要开发一些中大型的项目此时仅凭前面所学习的 Maven 的基础知识就比较难以应对了。还需要学习 Maven 提供的一些高级的功能这些功能在构建和管理 Java 项目的时候用的也是非常多的。
Maven高级内容包括:
分模块设计与开发继承与聚合私服
1. 分模块设计与开发
1.1 介绍
所谓分模块设计顾名思义指的就是我们在设计一个 Java 项目的时候将一个 Java 项目拆分成多个模块进行开发。
1). 未分模块设计的问题 如果项目不分模块也就意味着所有的业务代码是不是都写在这一个 Java 项目当中。随着这个项目的业务扩张项目当中的业务功能可能会越来越多。
假如我们开发的是一个大型的电商项目里面可能就包括了商品模块的功能、搜索模块的功能、购物车模块、订单模块、用户中心等等。这些所有的业务代码我们都在一个 Java 项目当中编写。
此时大家可以试想一下假如我们开发的是一个大型的电商网站这个项目组至少几十号甚至几百号开发人员这些开发人员全部操作这一个 Java 项目。此时大家就会发现我们项目管理和维护起来将会非常的困难。而且大家再来看假如在我们的项目当中我们自己定义了一些通用的工具类以及通用的组件而公司还有其他的项目组其他项目组也想使用我们所封装的这些组件和工具类其实是非常不方便的。因为 Java 项目当中包含了当前项目的所有业务代码所以就造成了这里面所封装的一些组件会难以复用。
总结起来主要两点问题不方便项目的维护和管理、项目中的通用组件难以复用。
2). 分模块设计
分模块设计我们在进行项目设计阶段就可以将一个大的项目拆分成若干个模块每一个模块都是独立的。 比如我们可以将商品的相关功能放在商品模块当中搜索的相关业务功能我都封装在搜索模块当中还有像购物车模块、订单模块。而为了组件的复用我们也可以将项目当中的实体类、工具类以及我们定义的通用的组件都单独的抽取到一个模块当中。
如果当前这个模块比如订单模块需要用到这些实体类以及工具类或者这些通用组件此时直接在订单模块当中引入工具类的坐标就可以了。这样我们就将一个项目拆分成了若干个模块儿这就是分模块儿设计。
分模块儿设计之后大家再来看。我们在进行项目管理的时候我就可以几个人一组几个人来负责订单模块儿另外几个人来负责购物车模块儿这样更加便于项目的管理以及项目的后期维护。
而且分模块设计之后如果我们需要用到另外一个模块的功能我们直接依赖模块就可以了。比如商品模块、搜索模块、购物车订单模块都需要依赖于通用组件当中封装的一些工具类我只需要引入通用组件的坐标就可以了。
分模块设计就是将项目按照功能/结构拆分成若干个子模块方便项目的管理维护、拓展也方便模块键的相互调用、资源共享。
1.2 实践
1.2.1 分析 方案一直接依赖我们当前项目 tlias-web-management 但是存在两大缺点 这个项目当中包含所有的业务功能代码而想共享的资源仅仅是pojo下的实体类以及 utils 下的工具类。如果全部都依赖进来项目在启动时将会把所有的类都加载进来会影响性能。如果直接把这个项目都依赖进来了那也就意味着我们所有的业务代码都对外公开了这个是非常不安全的。 方案二分模块设计 将pojo包下的实体类抽取到一个maven模块中 tlias-pojo将utils包下的工具类抽取到一个maven模块中 tlias-utils其他的业务代码放在tlias-web-management这个模块中在该模块中需要用到实体类pojo、工具类utils直接引入对应的依赖即可。 注意分模块开发需要先针对模块功能进行设计再进行编码。不会先将工程开发完毕然后进行拆分。 PS当前我们是为了演示分模块开发所以是基于我们前面开发的案例项目进行拆分的实际中都是分模块设计然后再开发的。 1.2.2 实现
思路我们分析完毕接下来我们就根据我们分析的思路按照如下模块进行拆分
1. 创建maven模块 tlias-pojo存放实体类
A. 创建一个正常的Maven模块模块名tlias-pojo B. 然后在tlias-pojo中创建一个包 com.itheima.pojo (和原来案例项目中的pojo包名一致) C. 将原来案例项目 tlias-web-management 中的pojo包下的实体类复制到tlias-pojo模块中 D. 在 tlias-pojo 模块的pom.xml文件中引入依赖
dependenciesdependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdversion1.18.24/version/dependency
/dependenciesE. 删除原有案例项目tlias-web-management的pojo包【直接删除不要犹豫我们已经将该模块拆分出去了】然后在pom.xml中引入 tlias-pojo的依赖
dependencygroupIdcom.itheima/groupIdartifactIdtlias-pojo/artifactIdversion1.0-SNAPSHOT/version
/dependency2. 创建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令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactIdversion0.9.1/version/dependency!--阿里云OSS--dependencygroupIdcom.aliyun.oss/groupIdartifactIdaliyun-sdk-oss/artifactIdversion3.15.1/version/dependencydependencygroupIdjavax.xml.bind/groupIdartifactIdjaxb-api/artifactIdversion2.3.1/version/dependencydependencygroupIdjavax.activation/groupIdartifactIdactivation/artifactIdversion1.1.1/version/dependency!-- no more than 2.3.3--dependencygroupIdorg.glassfish.jaxb/groupIdartifactIdjaxb-runtime/artifactIdversion2.3.3/version/dependency!--WEB开发--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactIdversion2.7.5/version/dependencydependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdversion1.18.24/version/dependency
/dependenciesE. 删除原有案例项目tlias-web-management的utils包【直接删除不要犹豫我们已经将该模块拆分出去了】然后在pom.xml中引入 tlias-utils的依赖
dependencygroupIdcom.itheima/groupIdartifactIdtlias-utils/artifactIdversion1.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中的继承相似子工程可以继承父工程中的配置信息常见于依赖关系的继承。 作用简化依赖配置、统一管理依赖 实现 parentgroupId.../groupIdartifactId.../artifactIdversion.../versionrelativePath..../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了。
那我们怎么来解决这个问题呢
那此时大家可以想一下Java虽然不支持多继承但是可以支持多重继承比如A 继承 B B 继承C。 那在Maven中也是支持多重继承的所以呢我们就可以让 我们自己创建的三个模块都继承tlias-parent而tlias-parent 再继承 spring-boot-starter-parent就可以了。 具体结构如下 2.1.1.2 实现
1). 创建maven模块 tlias-parent 该工程为父工程设置打包方式pom(默认jar)。 工程结构如下 父工程tlias-parent的pom.xml文件配置如下
parentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion2.7.5/versionrelativePath/ !-- lookup parent from repository --
/parentgroupIdcom.itheima/groupId
artifactIdtlias-parent/artifactId
version1.0-SNAPSHOT/version
packagingpom/packagingMaven打包方式 jar普通模块打包springboot项目基本都是jar包内嵌tomcat运行war普通web程序打包需要部署在外部的tomcat服务器中运行pom父工程或聚合工程该模块不写代码仅进行依赖管理 2). 在子工程的pom.xml文件中配置继承关系。
parentgroupIdcom.itheima/groupIdartifactIdtlias-parent/artifactIdversion1.0-SNAPSHOT/versionrelativePath../tlias-parent/pom.xml/relativePath
/parentartifactIdtlias-utils/artifactId
version1.0-SNAPSHOT/version这里是以 tlias-utils 为例指定了其父工程。其他的模块都是相同的配置方式。 注意 在子工程中配置了继承关系之后坐标中的groupId是可以省略的因为会自动继承父工程的 。relativePath指定父工程的pom文件的相对位置如果不指定将从本地仓库/远程仓库查找该工程。 …/ 代表的上一级目录 3). 在父工程中配置各个工程共有的依赖子工程会自动继承父工程的依赖。
dependenciesdependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdversion1.18.24/version/dependency
/dependencies此时我们已经将各个子工程中共有的依赖lombok都定义在了父工程中子工程中的这一项依赖就可以直接删除了。删除之后我们会看到父工程中配置的依赖 lombok子工程直接继承下来了。 工程结构说明 我们当前的项目结构为 因为我们是项目开发完毕之后给大家基于现有项目拆分的各个模块tlias-web-management已经存在了然后再创建各个模块与父工程所以父工程与模块之间是平级的。 而实际项目中可能还会见到下面的工程结构 而在真实的企业开发中都是先设计好模块之后再开始创建模块开发项目。 那此时呢一般都会先创建父工程 tlias-parent然后将创建的各个子模块都放在父工程parent下面。 这样层级结构会更加清晰一些。 PS上面两种工程结构都是可以正常使用的没有一点问题。 只不过第二种结构看起来父子工程结构更加清晰、更加直观。 2.1.2 版本锁定
2.1.2.1 场景
如果项目中各个模块中都公共的这部分依赖我们可以直接定义在父工程中从而简化子工程的配置。 然而在项目开发中还有一部分依赖并不是各个模块都共有的可能只是其中的一小部分模块中使用到了这个依赖。
比如在tlias-web-management、tlias-web-system、tlias-web-report这三个子工程中都使用到了jwt的依赖。 但是 tlias-pojo、tlias-utils中并不需要这个依赖那此时这个依赖我们不会直接配置在父工程 tlias-parent中而是哪个模块需要就在哪个模块中配置。
而由于是一个项目中的多个模块那多个模块中我们要使用的同一个依赖的版本要一致这样便于项目依赖的统一管理。比如这个jwt依赖我们都使用的是 0.9.1 这个版本。 那假如说我们项目要升级要使用到jwt最新版本 0.9.2 中的一个新功能那此时需要将依赖的版本升级到0.9.2那此时该怎么做呢
第一步去找当前项目中所有的模块的pom.xml配置文件看哪些模块用到了jwt的依赖。
第二步找到这个依赖之后将其版本version更换为 0.9.2。
问题如果项目拆分的模块比较多每一次更换版本我们都得找到这个项目中的每一个模块一个一个的更改。 很容易就会出现遗漏掉一个模块忘记更换版本的情况。
那我们又该如何来解决这个问题如何来统一管理各个依赖的版本呢
答案Maven的版本锁定功能。
2.1.2.2 介绍
在maven中可以在父工程的pom文件中通过 dependencyManagement 来统一管理依赖版本。
父工程
!--统一管理依赖版本--
dependencyManagementdependencies!--JWT令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactIdversion0.9.1/version/dependency/dependencies
/dependencyManagement子工程
dependencies!--JWT令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactId/dependency
/dependencies注意 在父工程中所配置的 dependencyManagement 只能统一管理依赖版本并不会将这个依赖直接引入进来。 这点和 dependencies 是不同的。 子工程要使用这个依赖还是需要引入的只是此时就无需指定 version 版本号了父工程统一管理。变更依赖版本只需在父工程中统一变更。 2.1.2.3 实现
接下来我们就可以将tlias-utils模块中单独配置的依赖将其版本统一交给 tlias-parent 进行统一管理。
具体步骤如下
1). tlias-parent 中的配置
!--统一管理依赖版本--
dependencyManagementdependencies!--JWT令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactIdversion0.9.1/version/dependency!--阿里云OSS--dependencygroupIdcom.aliyun.oss/groupIdartifactIdaliyun-sdk-oss/artifactIdversion3.15.1/version/dependencydependencygroupIdjavax.xml.bind/groupIdartifactIdjaxb-api/artifactIdversion2.3.1/version/dependencydependencygroupIdjavax.activation/groupIdartifactIdactivation/artifactIdversion1.1.1/version/dependency!-- no more than 2.3.3--dependencygroupIdorg.glassfish.jaxb/groupIdartifactIdjaxb-runtime/artifactIdversion2.3.3/version/dependency/dependencies
/dependencyManagement2). tlias-utils中的pom.xml配置
如果依赖的版本已经在父工程进行了统一管理所以在子工程中就无需再配置依赖的版本了。
dependencies!--JWT令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactId/dependency!--阿里云OSS--dependencygroupIdcom.aliyun.oss/groupIdartifactIdaliyun-sdk-oss/artifactId/dependencydependencygroupIdjavax.xml.bind/groupIdartifactIdjaxb-api/artifactId/dependencydependencygroupIdjavax.activation/groupIdartifactIdactivation/artifactId/dependency!-- no more than 2.3.3--dependencygroupIdorg.glassfish.jaxb/groupIdartifactIdjaxb-runtime/artifactId/dependency!--WEB开发--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency
/dependencies我们之所以在springboot项目中很多时候引入依赖坐标都不需要指定依赖的版本 version 是因为在父工程 spring-boot-starter-parent中已经通过 dependencyManagement对依赖的版本进行了统一的管理维护。 2.1.2.4 属性配置
我们也可以通过自定义属性及属性引用的形式在父工程中将依赖的版本号进行集中管理维护。 具体语法为
1). 自定义属性
propertieslombok.version1.18.24/lombok.version
/properties2). 引用属性
dependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdversion${lombok.version}/version
/dependency接下来我们就可以在父工程中将所有的版本号都集中管理维护起来。
propertiesmaven.compiler.source11/maven.compiler.sourcemaven.compiler.target11/maven.compiler.targetlombok.version1.18.24/lombok.versionjjwt.version0.9.1/jjwt.versionaliyun.oss.version3.15.1/aliyun.oss.versionjaxb.version2.3.1/jaxb.versionactivation.version1.1.1/activation.versionjaxb.runtime.version2.3.3/jaxb.runtime.version
/propertiesdependenciesdependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactIdversion${lombok.version}/version/dependency
/dependencies!--统一管理依赖版本--
dependencyManagementdependencies!--JWT令牌--dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt/artifactIdversion${jjwt.version}/version/dependency!--阿里云OSS--dependencygroupIdcom.aliyun.oss/groupIdartifactIdaliyun-sdk-oss/artifactIdversion${aliyun.oss.version}/version/dependencydependencygroupIdjavax.xml.bind/groupIdartifactIdjaxb-api/artifactIdversion${jaxb.version}/version/dependencydependencygroupIdjavax.activation/groupIdartifactIdactivation/artifactIdversion${activation.version}/version/dependency!-- no more than 2.3.3--dependencygroupIdorg.glassfish.jaxb/groupIdartifactIdjaxb-runtime/artifactIdversion${jaxb.runtime.version}/version/dependency/dependencies
/dependencyManagement版本集中管理之后我们要想修改依赖的版本就只需要在父工程中自定义属性的位置修改对应的属性值即可。 面试题dependencyManagement 与 dependencies 的区别是什么? dependencies 是直接依赖在父工程配置了依赖子工程会直接继承下来。dependencyManagement 是统一管理依赖版本不会直接依赖还需要在子工程中引入所需依赖(无需指定版本) 2.2 聚合
分模块设计与开发之后啊我们的项目被拆分为多个模块而模块之间的关系可能错综复杂。 那就比如我们当前的案例项目结构如下相对还是比较简单的 此时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中添加如下配置来指定当前聚合工程需要聚合的模块
!--聚合其他模块--
modulesmodule../tlias-pojo/modulemodule../tlias-utils/modulemodule../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的配置文件中配置访问私服的用户名、密码。
第二步配置在maven的配置文件中配置连接私服的地址(url地址)。
第三步配置在项目的pom.xml文件中配置上传资源的位置(url地址)。
配置好了上述三步之后要上传资源到私服仓库就执行执行maven生命周期deploy。 私服仓库说明 RELEASE存储自己开发的RELEASE发布版本的资源。SNAPSHOT存储自己开发的SNAPSHOT发布版本的资源。Central存储的是从中央仓库下载下来的依赖。 项目版本说明 RELEASE(发布版本)功能趋于稳定、当前更新停止可以用于发行的版本存储在私服中的RELEASE仓库中。SNAPSHOT(快照版本)功能不稳定、尚处于开发中的版本即快照版本存储在私服的SNAPSHOT仓库中。 3.3.2 具体操作
为了模拟企业开发这里我准备好了一台服务器192.168.150.101私服已经搭建好了我们可以访问私服测试http://192.168.150.101:8081 【 无法访问 】
私服准备好了之后我们要做如下几步配置
1.设置私服的访问用户名/密码在自己maven安装目录下的conf/settings.xml中的servers中配置
serveridmaven-releases/idusernameadmin/usernamepasswordadmin/password
/serverserveridmaven-snapshots/idusernameadmin/usernamepasswordadmin/password
/server2.设置私服依赖下载的仓库组地址在自己maven安装目录下的conf/settings.xml中的mirrors、profiles中配置
mirroridmaven-public/idmirrorOf*/mirrorOfurlhttp://192.168.150.101:8081/repository/maven-public//url
/mirrorprofileidallow-snapshots/idactivationactiveByDefaulttrue/activeByDefault/activationrepositoriesrepositoryidmaven-public/idurlhttp://192.168.150.101:8081/repository/maven-public//urlreleasesenabledtrue/enabled/releasessnapshotsenabledtrue/enabled/snapshots/repository/repositories
/profile3.IDEA的maven工程的pom文件中配置上传发布地址(直接在tlias-parent中配置发布地址)
distributionManagement!-- release版本的发布地址 --repositoryidmaven-releases/idurlhttp://192.168.150.101:8081/repository/maven-releases//url/repository!-- snapshot版本的发布地址 --snapshotRepositoryidmaven-snapshots/idurlhttp://192.168.150.101:8081/repository/maven-snapshots//url/snapshotRepository
/distributionManagement配置完成之后我们就可以在tlias-parent中执行deploy生命周期将项目发布到私服仓库中。 通过日志我们可以看到这几个模块打的jar包确实已经上传到了私服仓库中由于当前我们的项目是SNAPSHOT版本所以jar包是上传到了snapshot仓库中。
那接下来我们再来打开私服来看一下 我们看到我们项目中的这几个模块在私服中都有了。 那接下来当其他项目组的开发人员在项目中就可以直接通过依赖的坐标就可以完成引入对应的依赖此时本地仓库没有就会自动从私服仓库中下载。
