Maven介绍
Maven是Apache的一个开源项目,主要服务于基于Java平台的项目构建,依赖管理和项目信息管理。
Maven可以让团队能够更科学的构建项目,我们可以用配置文件的方式,对项目的名称、描述、项目版本号、项目依赖等信息进行描述,这使得我们项目结构更加清晰,从而能快速上手项目。
由于项目可能需要第三方库,所以Maven提出了Maven仓库的概念。把需要的依赖都放在仓库中,当项目需要时,就可以去Maven仓库中去获取;同时,其他项目组也需要同样的第三方库时,也可以直接去Maven获取。这样,大家都可以直接通过Maven获取依赖,而不需要单独去找资源了。
Maven的四大特性
依赖管理系统
Maven为Java引入了一个新的依赖管理系统jar包管理,jar升级时修改配置文件即可。Java中,一个依赖的唯一标识(Coordination,也称坐标)由以下三个部分组成:
- groupId:定义当前Maven项目隶属的实际项目-公司名称。
- artifactId:该元素定义实际项目中的一个Maven模块-项目名。推荐的做法是使用时机项目名称作为artifactId的前缀。
- version:该元素定义Maven项目当前所处的版本。
一个典型依赖引用:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>6.1.0-M2</version>
</dependency>
多模块构建
在Maven中需要定义一个parent POM作为一组module的聚合POM。在该POM中可以使用标签来定义一组子模块。pare POM不会有什么实际构建产出。而pare POM中的build配置以及依赖配置都会自动继承给子module。
一致的项目结构
Maven设置的理念是——Conversion over configuration (约定大于配置),其定制了一套项目目录结构作为标准的Java项目结构,解决了不同ide带来的文件目录不一致问题。
一致的构建模型和插件机制
Maven 使用
Maven的目录结构
pom.xml的举例:
(大概了解一下它是什么样子就可以了)
- modelVersion指明当前Pom模型的版本,对于Maven3来说,它只能是4.0.0。指定了当前Maven模型的版本号;
- groupId 定义了项目所属组,这个组往往和项目所在的组织和公司存在关联,例如:com.baidu;
- articactId 定义了当前Maven项目在组的唯一的ID;
- version X.X.X-里程碑,第一个X 大版本,有重大变革;第二个X 小版本,修复bug,增加功能;第三个X 更新;
- 里程碑版本:SNAPSHOT(快照,开发版);alpha(内部测试);beta(公开测试);Release | RC(发布版);GA(正常版)
Maven相关配置
找到Maven的配置文件:
在settings中修改以下配置:
修改下载的依赖所存放的位置:
修改镜像,加快下载速度:
maven下载依赖:mvn compile
Maven命令
Maven的命令格式: mvn [plugin-name]:[goal-name]
命令代表的含义:执行plugin-name插件的goal-name目标。
命令 | 描述 |
---|---|
mvn -version | 显示版本信息 |
mvn clean | 清理项目生产的临时文件,一般是模块下的target目录 |
mvn compile | 编译源代码,一般编译模块下的src/main/java目录 |
mvn package | 项目打包工具,会在模块下的target目录生成jar或war等文件 |
mvn test | 测试命令,或执行src/test/java/下junit的测试用例 |
mvn install | 将打包的jar/war文件复制到你的本地仓库中,供其他模块使用 |
mvn deploy | 将打包的文件发布到远程参考,提供其他人员进行下载依赖 |
mvn site | 生成项目相关信息的网站 |
mvn eclipse:eclipse | 将项目转化为Eclipse项目 |
mvn dependency:tree | 打印出项目的整个依赖树 |
mvn archetype:generate | 创建Maven的普通java项目 |
mvn tomcat7:run | 在tomcat容器中运行web应用 |
mvn jetty:run | 调用Jetty插件的Run目标在Jetty Servlet容器中启动web应用 |
Tips: 运行maven命令的时候,要先定位到maven项目的目录,也就是项目pom.xml文件所在的目录。否则,必须以通过参数来指定项目的目录。
Maven命令的参数
1)-D传入属性参数
例如:mvn package -Dmaven.test.skip=true ,以-D开头,将maven.test.skip的值设置为true,就是告诉maven打包的时候跳过单元测试。同理, mvn deploy -Dmaven.test.skip=true 代表部署项目跳过单元测试。
2)-P使用指定的Profile配置
一般情况下,项目开发需要多个环境,包括开发、测试、预发、正式这4个环境,在pom.xml的配置(部分)如下:
profiles定义了各个环境的变量id,filters中定义了变量配置文件的地址,其中地址中的环境变量就是上面profile中定义的值,resources中定义哪些目录下的文件会被配置文件中定义的变量替换。
通过maven可以实现按不同环境进行打包部署,例如:mvn package -Pdev -Dmaven.test.skip=true 表示打包本地环境,并跳过单元测试。
在IDEA中集成Maven环境
局部设置: 通过File的setting进行:
全局设置: 通过File–>New Project Setup–> Setting for new projects,修改Maven home path为自己解压后的maven路径(bin的上一级目录)和User setting file为对应的文件所在地址。
编译项目
添加打包命令:
可以在此处进行命令切换:
Maven仓库的基本概念
对Maven来说,仓库只分为:本地仓库和远程仓库。
当Maven根据坐标寻找构件的时候,它首先会查看本地仓库,如果本地仓库存在,则直接使用;如果本地没有,Maven就会去远程仓库查找,发现需要的构件之后,下载到本地仓库再使用。如果本地仓库和远程仓库都没有,Maven就会报错。
远程仓库分为三种:中央仓库、私服和其他公共库。
- 中央仓库是默认配置,Maven下载jar包的地方。
- 私服是另一种特殊的远程仓库,为了节省带宽和时间,在局域网内架设一个私有的仓库服务器,用其代理所有外部的远程仓库。内部的项目还能部署到私服上供其他项目使用。当Maven需要下载构件时,它会先去私服中找,如果私服中没有,则从外部远程仓库下载,并缓存在私服上,再为Maven提供服务。
- 其他公共库,例如阿里云仓库,如:
Maven环境下构件多模块项目
使用Maven提供的多模块构建的特征性完成Maven环境下多个模块的项目的管理与构建:
- 模块 maven_parent——基模块,就是场所的parent(pom)
- 模块 maven_dao——数据库的访问层,例如jdbc操作(jar)
- 模块 maven_service——项目的业务逻辑层(jar)
- 模块 maven_controller——用来接收请求,响应数据(war)
(先简单了解一下就行,后面学习框架的时候就会理解了)
Maven的打包操作
对于Maven项目,我们可以通过用pom.xml配置的方式来实现打包时的环境选择。
1)建立对应的目录结构
使用idea创建项目时,目录结构可能会缺失,需要我们手动添加对应的目录:
2)添加Profile配置
3)设置资源文件配置
把以下的代码放在build标签对中,其中env指的是profile中<env><\env>标签中的值,具体是哪一个模块下的值,是由打包时的命令决定的。
4)执行打包操作
package -Pdev表示在打包时会去找id为dev的profile。
执行后得到的打包文件最终在src/target。
Maven依赖的基本概念
依赖的基本配置
根元素project下的dependencies可以包含多个dependence元素,以声明多个依赖,每个依赖都应该包含以下元素:
- groupId, artifactId, Version:依赖的基本坐标,对于任何一个依赖来说,基本坐标是最重要的,Maven根据坐标才能找到需要的依赖;
- Type:依赖的类型,大部分情况下不需要声明,默认为jar。
- Scope:依赖范围(compile, test, provided, runtime, system)。
- Optional:表级依赖是否可选。
- Exclusive:用来排除传递性依赖。
依赖范围
- compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。典型的例子是spring-core,在编译、测试和运行的时候都需要使用该依赖。
- test:测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit,它只有在编译测试代码及运行测试的时候才需要。
- provided:已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试class-path有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于Tomcat等容器已经提供,就不需要Maven重复地引入一遍。
- runtime:运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行class-path有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
- system:系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构建。一般不使用。
- 依赖范围由弱到强是:test->runtime->provided->compile。
传递性依赖
传递性依赖机制让我们在使用某个jar的时候不需要考虑它依赖了什么,也不需要但因引入多余的依赖。Maven会解析各个直接依赖的POM,将哪些必要的间接依赖,以传递性依赖的形式引入到当前项目中。
注意:传递性依赖有可能产生冲突,如:
如果A下同时存在两个不同version的C,会发生冲突,此时应该选择同时满足条件的版本。