Maven是专门用于管理和构建Java项目的工具,它的主要功能有:
标准化的项目结构:
项目结构我们都知道,每一个开发工具(IDE)都有自己不同的项目结构,它们互相之间不通用。我再eclipse中创建的目录,无法在idea中进行使用,这就造成了很大的不方便,如下图:前两个是以后开发经常使用的开发工具
而Maven提供了一套标准化的项目结构,所有的IDE使用Maven构建的项目完全一样,所以IDE创建的Maven项目可以通用。(eclipse的项目可以直接在myecilipse上使用)
如下图右边就是Maven构建的项目结构。
标准化的构建流程:
如上图所示我们开发了一套系统,代码需要进行编译、测试、打包(java打jar包)、发布,这些操作如果需要反复进行就显得特别麻烦,而Maven提供了一套简单的命令来完成项目构建。
下图操作, run Maven下选中compile为编译,选中package为打包(jar包)
maven最主要体现在两个词上:项目的管理和项目的构建。
如上图所示就是Maven的模型,而我们先看紫色框框起来的部分,他就是用来完成 标准化构建流程
。如我们需要编译,Maven提供了一个编译插件供我们使用,我们需要打包,Maven就提供了一个打包插件提供我们使用等。
上图中紫色框起来的部分,项目对象模型就是将我们自己抽象成一个对象模型,有自己专属的坐标,如下图所示是一个Maven项目:
依赖管理模型则是使用坐标来描述当前项目依赖哪儿些第三方jar包,如下图所示
上述Maven模型图中还有一部分是仓库。如何理解仓库呢?
大家想想这样的场景,我们创建Maven项目,在项目中使用坐标来指定项目的依赖,那么依赖的jar包到底存储在什么地方呢?其实依赖jar包是存储在我们的本地仓库中。而项目运行时从本地仓库中拿需要的依赖jar包。
仓库分类:
本地仓库:自己计算机上的一个目录
中央仓库:由Maven团队维护的全球唯一的仓库
远程仓库(私服):一般由公司团队搭建的私有仓库
今天我们只学习远程仓库的使用,并不会搭建。
当项目中使用坐标引入对应依赖jar包后,首先会查找本地仓库中是否有对应的jar包:
如果有,则在项目直接引用;
如果没有,则去中央仓库中下载对应的jar包到本地仓库。
如果还可以搭建远程仓库,将来jar包的查找顺序则变为:
本地仓库 --> 远程仓库–> 中央仓库
maven给我们整个开发团队找出了一种能够**更加科学的去管理我们项目的思想。**maven通过使用配置文件的方式使得项目在管理和交接的过程中成本变得非常低。maven提出了一种叫做maven仓库的概念,使得我们可以将第三方和我们需要引用的项目都放置在maven仓库当中。如果其他人或项目组也需要使用,就可以直接通过maven进行配置就行。这样就可以将人员成本、沟通成本等等都进行降低。
如果还不理解我们举个例子:加入我们现在想做一份菜:糖醋排骨。如果我们想要做这道菜,那么我们首先要先去菜市场买排骨、糖、醋、…,而且在做的时候还要注意使用糖醋的用量等等。那么如果有一个超市,该超市有卖糖醋排骨的料理包,这是不是就能很大的节省我们做饭和买菜的时间开销。其实maven就是这个卖料理包的超市,当人卖的不是料理包,而是一系列的jar包。这样我们在写代码的时候就不需要去其他网站上下载一大堆的jar包。
不知道大家有没有意识到,构建(build)是每一个程序员都在做的工作。仔细观察我们会发现,除了编写代码,我们每天都有相当一部分时间花在了编译,运行单元测试,生成文档、打包和部署等繁琐和不起眼的工作上,这就是构建。如果我们现在还是手工的做这些事情,那么时间成本就太高了,于是有人用软件的方法让这一系列工作完全自动化。是软件构建完全像流水线一样,只需要一条简单的命令,所有繁琐的步骤就能很快的自动完成。
Ant构建
最早的构建工具,基于IDE,大概是2000年有的,当时最流行的java构建工具,不过他的xml脚本编写风格让xml文件特别大。对工程构建过程中的过程控制的特别好。
Maven [ java ]
Maven是一个项目管理和整合工具。Maven为开发者提供了一整套完整的生命周期框架。开发团队几乎不用花多长时间就能够自动完成工程的基础构建配置。他填补了Ant的缺点,Maven第一次支持了从网上下载的功能,仍然采用xml作为配置文件格式Maven专注的是项目依赖,使用java编写。
Gradle
属于结合以上两个的优势,他继承了Ant的灵活和Maven的生命周期管理,他最终被google作为了Android御用管理工具。他最大的区别是不用XML作为配置文件格式,采用了DSL格式,使得脚本更加简洁。
目前市面上Ant比较老,所以一般是一些比较传统的软件企业公司使用,Maven使用java编写,是当下大多数互联网公司使用的一种构建工具,中文文档也比较齐全,gradle是用groovy编写,目前比较新的构建工具一些初创互联网公司会使用,以后会有很大的使用空间。
市面上有很多构建工具,而Maven依旧还是主流构建工具,如下图是常用构建工具的使用占比
Maven为java世界引入了一个新的依赖管理系统jar包管理 jar包升级时修改配置文件即可。在java世界中,可以用gropId、artifactId、version组成Coordination(坐标)唯一标识一个依赖。
任何基于maven构建的项目自身也必须定义这三个属性。
<dependency>
<groupId>org.mybatisgroupId>
<artifactId>mybatisartifactId>
<version>3.4.5version>
dependency>
坐标属性的理解
Maven坐标为各个组件引入了新秩序,任何一个组件都必须明确定义自己的坐标。
groupId
定义当前Maven项目隶属的实际项目-公司名称。(jar包所在仓库路径)由于maven中模块的概念,因此一个项目实际往往会被分成多个模块。比如Spring是一个实际的项目,其对应的Maven模块会有很多,比如Spring-croe,spring-webmvc等。
artifactid
该元素定义实际项目中的Maven模块-项目名称,推荐的做法是使用实际项目名称作为atrifactid的前缀。比如:Spring-bean,Spring-webmvc等。
version
该元素定义Maven项目当前所处的版本。
采用依赖管理的好处是能够大大减少我们对jar包下载和管理的难度。比如项目当中如果有100个jar包,难道我们需要从网上下载这100个jar包吗?显然如果利用maven提供给我们的坐标,就可以很快完成项目的构建。
我们在写项目的时候往往需要将 dao service controller 层分离讲一个项目分解为多个模块已经是一种通用的方式。
我们当初在eclipse上边写的项目如果导入到idea上边,那么就会出现很多奇奇怪怪的问题,同理,将idea上边的项目导入到eclipse当中也是一样。究其原因是因为我们在这两个编译器上的项目的目录结构是不一致的。而maven在设计之初的理念就是Conversion over configuration (约定大于配置)。其制定了一套项目目录结构作为标准的java项目结构,解决不同的ida带来文件目录不一致的问题。
这一个项目当中我们往往会引入很多插件,比如tomcat服务器或者jetty(嵌入式服务器),为了实现项目组内插件的统一,maven提供了一套机制来包证这要机制的施行。
<plugins>
<plugin>
<groupId>org.eclipse.jettygroupId>
<artifactId>jetty-maven-pluginartifactId>
<version>9.2.8.v20150217version>
<configuration>
<httpConnector>
<port>80port>
httpConnector>
<stopKey>shutdownstopKey>
<stopPort>9966stopPort>
configuration>
plugin>
plugins>
下载apache-maven-3.6.1.rar的包,如下为官网下载地址
https://maven.apache.org/download.cgi
解压 apache-maven-3.6.1.rar 既安装完成
建议解压缩到没有中文、特殊字符的路径下。
解压缩后的目录结构如下:
settings.xml
配置文件后期需要修改。配置环境变量 MAVEN_HOME 为安装路径的bin目录
此电脑
右键 --> 高级系统设置
--> 高级
--> 环境变量
在系统变量处新建一个变量 MAVEN_HOME
在 Path
中进行配置
打开命令提示符进行验证,出现如图所示表示安装成功
配置本地仓库
修改 conf/settings.xml 中的 为一个指定目录作为本地仓库,用来存储jar包。
配置阿里云私服
中央仓库在国外,所以下载jar包速度可能比较慢,而阿里公司提供了一个远程仓库,里面基本也都有开源项目的jar包。
修改 conf/settings.xml 中的 标签,为其添加如下子标签:
<mirror>
<id>alimavenid>
<name>aliyun mavenname>
<url>http://maven.aliyun.com/nexus/content/groups/public/url>
<mirrorOf>centralmirrorOf>
mirror>
compile :编译
clean:清理
test:测试
package:打包
install:安装
命令演示:
使用Maven构建的项目,项目结构如下:
而我们使用上面命令需要在磁盘上进入到项目的 pom.xml
目录下,打开命令提示符
编译命令演示:
compile :编译
执行上述命令可以看到:
target
目录同时在项目下会出现一个 target
目录,编译后的字节码文件就放在该目录下
清理命令演示:
mvn clean
执行上述命令可以看到
target
目录打包命令演示:
mvn package
执行上述命令可以看到:
terget
目录下有一个jar包(将当前项目打成的jar包)测试命令演示:
mvn test
该命令会执行所有的测试代码。执行上述命令效果如下
安装命令演示:
mvn install
该命令会将当前项目打成jar包,并安装到本地仓库。执行完上述命令后到本地仓库查看结果如下:
Maven 构建项目生命周期描述的是一次构建过程经历经历了多少个事件
Maven 对项目构建的生命周期划分为3套:
同一套生命周期内,执行后边的命令,前面的所有命令会自动执行。例如默认(default)生命周期如下:
当我们执行 install
(安装)命令时,它会先执行 compile
命令,再执行 test
命令,再执行 package
命令,最后执行 install
命令。
当我们执行 package
(打包)命令时,它会先执行 compile
命令,再执行 test
命令,最后执行 package
命令。
默认的生命周期也有对应的很多命令,其他的一般都不会使用,我们只关注常用的:
我们需要先在IDEA中配置Maven环境:
什么是坐标?
Maven 坐标主要组成
如下图就是使用坐标表示一个项目:
注意:
- 上面所说的资源可以是插件、依赖、当前项目。
- 我们的项目如果被其他的项目依赖时,也是需要坐标来引入的。
普通maven结构选择quickstart,web项目选择webapp
填写模块名称,坐标信息,点击finish,创建完成
通过骨架(archetype)创建的maven项目,可能会没有resources目录
<properties>
<project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
<maven.compiler.source>1.8maven.compiler.source>
<maven.compiler.target>1.8maven.compiler.target>
properties>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.12version>
<scope>testscope>
dependency>
dependencies>
<pluginManagement>
.....
pluginManagement>
在build标签中添加plugins标签(二选一即可)
<plugin>
<groupId>org.eclipse.jettygroupId>
<artifactId>jetty-maven-pluginartifactId>
<version>9.2.11.v20150529version>
<configuration>
<scanIntervalSeconds>10scanIntervalSeconds>
<webApp>
<contextPath>/testcontextPath>
webApp>
<httpConnector>
<port>9090port>
httpConnector>
configuration>
plugin>
2.Tomcat插件
<plugin>
<groupId>org.apache.tomcat.mavengroupId>
<artifactId>tomcat7-maven-pluginartifactId>
<version>2.2version>
<configuration>
<port>80port>
<path>/mavenWebpath>
configuration>
plugin>
配置 Maven-Helper 插件
安装完该插件后可以通过 选中项目右键进行相关命令操作,如下图所示:
使用maven提供的多模块构建的特征完成maven环境下多模块的项目的管理和构建
这里以四个模块为例来搭建项目,以达到通俗易懂的初衷
模块 maven_parent -- 基模块,也就是常说的parent (pom)
模块 maven_dao -- 数据库访问层,例如jdbc操作(jar)
模块 maven_service -- 项目的业务逻辑层(jar)
模块 maven_controller -- 用来接收请求,相应数据(war),前后端交互,servlet会在这层次
父项目不选择骨架,直接创建即可
选择项目mavenTest,右键New,选择Module
创建maven_service模块的步骤与maven_dao模块一致
创建 maven_service 模块的步骤与maven_dao模块基本一致,只需要将第一步选择Maven模板设置为Web项目即可。(模板类型:maven-archetype-webapp)
注意:别忘了修改如下信息
如我们所知的一样,dao层是面向数据库的(数据持久层)(如mybtis框架会在这层),service层是业务处理(服务(业务逻辑层)层——比如增删改查的函数会在这层)controller层是辅助前后端交互的(请求处理层Web层)(比如servlet就在这层)
这样我们不难得出,我们想要从前端到数据库,在返回前端应该是这样的过程
所以,controller层需要调用service的方法,把前端的数据给service层做业务逻辑的处理,service层要调用dao层的方法来和数据库进行交互。即service层要添加dao层的依赖,controller层需要添加service的依赖
1.新建文件并添加方法
package com.qcby;
public class UserDao {
public static void testDao(){
System.out.println("我是Dao层");
}
}
1.添加maven_dao的依赖
<dependency>
<groupId>com.qcbygroupId>
<artifactId>maven-daoartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
2.在项目中添加UserService类,并添加方法
package com.qcby;
public class UserService {
public static void testService(){
System.out.println("我是Service层");
//调用dao层
UserDao.testDao();
}
}
1.添加maven_service模块的依赖
<dependency>
<groupId>com.qcbygroupId>
<artifactId>maven-serviceartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
2.添加对servlet的依赖
<dependency>
<groupId>javax.servletgroupId>
<artifactId>javax.servlet-apiartifactId>
<version>3.1.0version>
<scope>providedscope>
dependency>
3.新建java类,继承HttpServlet,重写service方法
import com.qcby.UserService;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@WebServlet("/userServlet")
public class UserServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
System.out.println(request.getParameter("name"));
System.out.println("我是Controller层");
//调用service层
UserService.testService();
}
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
this.doGet(request, response);
}
}
4.添加Tomcat插件
<plugin>
<groupId>org.apache.tomcat.mavengroupId>
<artifactId>tomcat7-maven-pluginartifactId>
<version>2.2version>
<configuration>
<port>8080port>
<path>/mavenWebpath>
configuration>
plugin>
5.启动
启动顺序:
父类:mavenTest----->install
子类:dao------------>install
子类:service------->install
子类:controller------>install
最后:启动tomcat
最后访问:
http://localhost/mavenWeb/user
也可以通过Maven-Helper插件启动,访问的连接和Tomcat坐标依赖是一样的
对于企业级项目,无论是进行本地测试,还是测试环境测试以及最终的项目上线,都会涉及项目的打包操作。对于每个环境下的项目打包,对应的项目所需要的配置资源都会有所区别,实现打包的方式有很多种,可以通过ant,或者通过idea 自带的打包功能实现项目打包,但当项目很大并且需要的外界配置很多时,此时打包的配置就会异常复杂,对于maven 项目,我们可以用过 pom.xml 配置的方式来实现打包时的环境选择,相比较其他形式打包工具,通过maven 只需要通过简单的配置,就可以轻松完成不同环境下项目的整体打包。
使用idea创建项目,目录结构可能会缺失,需要通过手动添加对应的目录结构
清空和修改pom文件
选择项目的 main 文件夹,右键选择New,选择Directory
<profiles>
<profile>
<id>devid>
<properties>
<env>devenv>
properties>
<activation>
<activeByDefault>trueactiveByDefault>
activation>
profile>
<profile>
<id>testid>
<properties>
<env>testenv>
properties>
profile>
<profile>
<id>productid>
<properties>
<env>productenv>
properties>
profile>
profiles>
<resources>
<resource>
<directory>src/main/resources/${env}directory>
resource>
<resource>
<directory>src/main/javadirectory>
<includes>
<include>**/*.xmlinclude>
<include>**/*.propertiesinclude>
<include>**/*.tldinclude>
includes>
<filtering>falsefiltering>
resource>
resources>
根元素project下的dependencies可以包含多个 dependence元素,以声明多个依赖。每个依赖都应
该包含以下元素:
Maven根据坐标才能找到需要的依赖。
2. Type: 依赖的类型,大部分情况下不需要声明。 **默认值为jar,web所在的项目要打成war包**
compile: 编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。
test: 测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子就是JUnit,它只有在编译测试代码及运行测试的时候才需要。
provided: 已提供依赖范围。 使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运行时无效。典型的例子是servlet-api,编译和测试项目的时候需要该依赖,但在运行项目的时候,由于容器已经提供,就不需要Maven重复地引入一遍(如:servlet-api)。
runtime: 运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行classpath有效,但在编译主代码时无效。典型的例子是JDBC驱动实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system: 系统依赖范围。该依赖与三种classpath的关系,和provided依赖范围完全一致。但是,使用system范围依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的,而且往往与本机系统绑定,可能造成构建的不可移植,因此应该谨慎使用。
Optional:标记依赖是否可选
Exclusions: 用来排除传递性依赖。
8.2 传递性依赖
传递依赖机制, 让我们在使用某个jar的时候就不用去考虑它依赖了什么。也不用担心引入多余的依
赖。 Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前项
目中。
注意: 传递依赖有可能产生冲突!!
冲突场景:
如果A下同时存在两个不同version的C,冲突!!(选取同时适合A、B的版本)
<dependencies>
<dependency>
<groupId>AgroupId>
<artifactId>AartifactId>
<version>xxxversion>
<exclusions>
<exclusion>
<groupId>CgroupId>
<artifactId>CartifactId>
exclusion>
exclusions>
dependency>
<dependency>
<groupId>BgroupId>
<artifactId>BartifactId>
dependency>
dependencies>
<exclusions>
<exclusion>
<groupId>CgroupId>
<artifactId>CartifactId>
exclusion>
exclusions>