01

it2022-05-05  107

目前技术中存在问题(为什么使用Maven): 一个项目就是一个工程: 缺陷:如果项目太过庞大,就不适合使用package来划分层次,最好是一个模块就是一个工程,利于分工协作。解决:Maven可以将一个项目拆分成多个工程。项目中所需要的jar包必须手动“复制”“粘贴”到WEB-INF/lib中: 缺陷:同样的jar包出现在不同的工程中,造成磁盘存储空间的浪费,同时造成工程臃肿。决:借助Maven可以将jar包保存在仓库中,然后在项目中添加一个“引用”文件接口即可。jar包需要提前下载好,或者别人事先准备好: 缺陷:不同的官网提供jar包下载的方式不同,通过非官网下载则可能导致jar包不规范(收费、版本)。解决:所有的jar包都在Mven的中央仓库中存储,可以使用规范的方式下载所需要的jar包。jar包需要手动添加依赖包 缺陷:jar包之间具有依赖性,如commons-filedupload.jar包依赖于commons-io.jar包,在使用这些jar包时,必须要                            掌握其中的依赖关系。解决:使用maven,会自动将依赖包导入到项目中。Maven是什么: ①.Maven是一款只针对Java平台的自动化构建工具 发展历程:Make→Ant→Maven→Gradle ②. 构建 概念:以“Java源文件”“框架配置文件”“jsp”“html”“图片”等资源文件为“原材料”,去“生产”一个可以            运行的项目的过程。编译:Java源文件→编译→Class字节码文件→交给JVM去执行       。部署:一个动态web项目最终运行的并不是项目本身,而是这个项目“编译的结果”。构建:构建并不等于创建,构建就是以我们编写的Java文件、框架配置文件、国际化等资源文件、图片和jsp页面等             静态资源作为“原材料”,生产出一个可运行的项目的过程。③.构建过程中的各个环节: 清理:将以前编译得到的旧的class字节码文件删除编译:将Java文件编译为class字节码文件测试:自动测试,自动调用JUnit程序报告:将测试的结果打印出来打包:动态Web工程打包为war,Java工程打包为jar安装:Maven特定概念--将打包得到的文件复制到“仓库”指定位置部署:将动态web工程打包而成的war包复制到servlet容器的指定目录下。               Maven环境配置: Java环境变量配置解压缩Maven压缩文件,并创建一个新的目录进行存放配置Maven环境: 配置MAVEN_HOMT或M2_HOME:配置Maven的path环境:验证Maven安装是否成功:mvn -v,显示当前版本信息后则安装成功Maven的核心概念: 约定的目录结构POM坐标依赖仓库生命周期/插件/目标继承聚合 .第一个Maven工程: 创建约定的目录结构: 根目录:工程名src目录:源码POM.xml文件:Maven工程的核心配置文件main目录:存放主程序        test目录:存放测试程序java目录:存放Java源文件resources目录:存放框架或者其他工具的配置文件 为什么要遵守约定的目录结构? 为了自动化构建常用命令: 注意:执行与构建过程相关的maven命令,必须进入pom.xml所在目录。与构建过程相关:编译、测试、打包......常用命令: mvn clean:清理mvn compile:编译主程序mvn test-compile:编译测试程序mvn test:执行测试mvn package:打包    mvn install:安装mvn site:生成站点关于Maven联网问题: Maven的核心程序中仅仅定义了抽象的生命周期,但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序当我们使用的Maven命令需要用到一些别的插件时,Maven核心程序会先到电脑本地的仓库中寻找本地仓库的默认位置为(c:\users\Administor\.m2\repository)    Maven如果在本地仓库无法找到需要的插件,会自动连接外网在中央仓库中下载如果无法联网,则构建会失败修改默认本地仓库位置,可以让Maven核心程序到事先准备好的目录下寻找插件 Maven解压目录\conf\setting.xml在setting.xml中找到ocalRepository标签将<localRepository>/path/to/local/repo</localRepository>将标签中间的路径修改为早已准备好的maven仓库目录<localRepository>D:\Work\Environment\Maven\local</localRepository>POM文件 全拼:Project Object Model 项目对象模型 Dom :Document Object Model 文档对象模型pom.xml文件是Maven的核心配置文件,与构建过程相关的一切设置都这pom.xml中进行坐标: 数学中的坐标: 在平面中,使用x、y两个向量,可以在平面中确定唯一的一个点在空间中,使用x、y、z三个向量可以在空间中确定唯一的一个点    在Maven中使用以下三个向量来确定唯一的Maven工程 groupId:公司/组织域名倒序+项目名 <groupId>pw.fengya.maven</groupId>artifactId:模块名 <artifactId>Hello</artifactId>version:版本 <version>1.0.0</version>坐标与仓库中的路径的对应关系        仓库 仓库分类: 本地仓库:在当前电脑上部署的Maven仓库目录,只为当前电脑的Maven工程服务远程仓库: 私服(Nexus):架设在局域网环境下,为当前局域网环境下的Maven工程服务中央仓库:架设在Internet上,为全世界的Maven工程服务中央仓库镜像:为了分担中央仓库的流量压力,提升用户访问速度仓库中保存内容(Maven工程): Maven自身所需要的插件第三方框架或工具所需jar包自己开发的Maven工程依赖 Maven解析依赖信息时会到本地仓库中寻找被依赖的jar包 对于我们自己开发的Maven工程,使用mvn install命令后就可以进入仓库依赖的取值: compile范围依赖 对主程序是否有效:有效对测试程序是否有效有效是否参与打包:参与test 对主程序是否有效:无效对测试程序是否有效:有效是否参与打包:不参与eg:junit.jarprovided:                  对主程序是否有效:有效对测试程序是否有效:有效是否参与打包:不参与是否参与部署:不参与eg:servlet-api.jarMaven生命周期: 各个构建环节执行的顺序:不能打乱顺序,必须按照既定的正确顺序来执行Maven的核心程序中定义了抽象的生命周期,生命周期各个阶段的具体任务由插件来完成Maven核心程序为了更好的实行自动化构建,按照这些特点来执行生命周期中的各个阶段:不论现在要执行生命周期中的哪一个阶段,都是从这个生命周期的最初开始执行。在Eclipse中使用Maven插件 Maven插件:Eclipse内置Maven插件设置: 在installation中添加自己本地的Maven仓库目录在user setting中设置conf/setting.xml的位置创建Maven工程: 创建Java工程,选择打包方式为jar创建web工程,选择打包方式为war,并选中项目,选择properties,选择Project Facets,去掉Dynmic  web Module,点击Apply,重新勾选,并勾选在src/main/webapp目录下创建web.xml        jsp页面抛空指针异常,则可能是依赖范围问题,将socpe属性值改为provided依赖[高级]: 依赖的传递性: 好处:可以传递的依赖不必再每个模块都进行声明,在“最下面”的工程中依赖一次即可注意:只有compile范围的依赖可以进行传递依赖的排除: 在某个项目中确实需要依赖某jar包,而其传递的依赖中可能有jar包并不稳定,所以需要排除排除设置: <exclusions> <exclusion> <groupId></groupId> <artifactId></artifactId> </exclusion> </exclusions> 依赖的原则: 作用:解决模块jar包之间的冲突性问题情景设定1:声明路径不同时,路径较短者优先情景设定2:声明路径相同时,先声明者优先 此处路径相同指的是dependency标签的先后顺序依赖版本管理: 情景设定:加入当前项目使用的spring版本为4.0.0,假如后期需要修改版本号为4.0.2时,不可能依靠手动修改 解决方案:在properties标签中使用自定自定义标签统一声明版本号         <properties> <自定义标签名>版本号</自定义标签名> </properties> 在需要同一版本的位置,使用${自定义标签名}声明引用的版本号使用properties标签和自定义标签的方式并不是只适合于版本号的设定,也可以用于其他地方,类似于Java中的常量继承: 现状: JavaProject01依赖的Junit版本:4.0JavaProject02依赖的Junit版本:4.0JavaProject03依赖的Junit版本:4.9缺陷:由于test范围的依赖不能传递,所以必然会导致各模块版本不一致            需求:统一管理各个模块对于Junit的版本管理解决思路:将Junit统一提取到“父”工程中,在子工程中声明Junit依赖时不指定版本,以父工程统一设定为准,也利于修改。操作步骤: 创建一个Maven工程为父工程,注意:打包方式为pom                    在子工程中声明对父工程的引用将子工程中与父工程冲突的部分删掉在父工程中统一对Junit的依赖在子工程中删除对于Junit依赖的版本号         配置完成后,需要先安装父工程再安装子工程 聚合: 作用:一键自动安装各个模块工程配置方式:在一个“总的聚合工程”中配置参与聚合的各个模块 使用方式:在聚合工程中run as 选择Maven install  

转载于:https://www.cnblogs.com/lxc-2017/p/8530464.html


最新回复(0)