Maven依赖范围
基于之前我们创建的Maven Web项目,添加Web开发中常用的依赖。
1、mysql驱动
2、servlet
3、jsp
4、jstl
5、gson等
目录结构如下:
Student类代码如下:
package com.maven.entity;
/**
* 学生实体类
*/
public class Student {
private Integer id;
private String name;
private String gender;
private double score;
public Student(){}
public Student(Integer id, String name, String gender, double score) {
this.id = id;
this.name = name;
this.gender = gender;
this.score = score;
}
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getGender() {
return gender;
}
public void setGender(String gender) {
this.gender = gender;
}
public double getScore() {
return score;
}
public void setScore(double score) {
this.score = score;
}
@Override
public String toString() {
return "Student{" +
"id=" + id +
", name='" + name + '\'' +
", gender='" + gender + '\'' +
", score=" + score +
'}';
}
}
GsonServlet类代码如下:
package com.maven.servlet;
import com.google.gson.Gson;
import com.maven.entity.Student;
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;
import java.util.ArrayList;
import java.util.List;
/**
* 测试Gson的Servlet
*/
@WebServlet("/gsonServlet")
public class GsonServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
//创建Gson对象(如果没有引入gson的jar包或依赖,肯定会报错)
Gson gson = new Gson();
//创建集合来存储学生对象
List<Student> studentList = new ArrayList<>();
studentList.add(new Student(101,"Tom","boy",89));
studentList.add(new Student(102,"Jerry","boy",56.2));
studentList.add(new Student(103,"HanMeiMei","girl",44));
studentList.add(new Student(104,"LiLei","boy",100));
//把studentList转换为json字符串响应出去
String json = gson.toJson(studentList);
resp.getWriter().write(json);
}
}
StudentTest类代码如下:
package com.maven.entity;
import org.junit.Test;
/**
* 学生类单元测试
*/
public class StudentTest {
@Test
public void test1() {
Student student = new Student(101, "张三", "男", 12);
System.out.println(student);
}
}
pom.xml文件依赖如下:
<dependencies>
<!-- 引入junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<!-- 引入mysql驱动 -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.49</version>
</dependency>
<!-- 引入jsp -->
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<!-- 引入servlet -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<!-- 引入jstl -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
<!-- 引入gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
</dependencies>
实体类、servlet、测试类代码都没什么要解释的,但是我们在引入依赖的时候会发现,有的依赖有scope标签,有的没有。
<scope>标签就是控制 dependency 元素的使用范围。通俗的讲,就是控制 Jar 包在哪些范围被加载和使用。
依赖范围概述
三种classpath的理解:
1、编译classpath:对应target目录下的classes目录,仅存放src/main目录下编译之后的内容。
src/main/java:编译之后生成的字节码文件放到classes目录(带包结构)。
src/main/resources:不会进行编译,直接放到classes目录。
2、测试classpath:对应target目录下的test-classes目录,仅存放src/test目录下编译之后的内容。
src/test/java:编译之后生成的字节码文件放到test-classes目录(带包结构)。
src/test/resources:不会进行编译,直接放到test-classes目录。
3、运行classpath:项目运行时的字节码文件存放目录。例如Web项目/WEB-INF/classes目录。
注意:
1、resources目录下面不能创建包,只能创建文件夹,如果我们创建文件夹com.maven.servlet,只是创建了一个文件夹叫com.maven.servlet。
2、resources目录下面可以定义和main目录下面相同的目录结构。
3、resources目录下面不能定义和main目录下面相同的文件。
4、resources目录下面的Java源代码不会被编译,也不推荐把Java源代码放到resources目录。
Maven项目不同的阶段引入到classpath中的依赖是不同的。
编译时,Maven会将与编译相关的依赖引入classpath中。
测试时,Maven会将测试相关的的依赖引入到classpath中。
运行时,Maven会将与运行相关的依赖引入classpath中。
而依赖范围就是用来控制依赖在编译classpath,测试classpath,运行classpath这三种classpath的使用。
依赖范围的取值
Maven的生命周期存在编译、测试、运行这些过程,那么显然有些依赖只用于测试,比如junit;有些依赖编译用不到,只有运行的时候才能用到,比如mysql的驱动包在编译期就用不到(编译期用的是JDBC接口),而是在运行时用到的;还有些依赖,编译期要用到,而运行期不需要提供,因为有些容器已经提供了,比如servlet-api在tomcat中已经提供了,我们只需要的是编译期提供而已。总结说来,在POM 4中,<dependency>中还引入了<scope>,它主要管理依赖的部署。大致有compile、provided、runtime、test、system等几个。
compile:编译依赖范围。
test:测试依赖范围。
provided:已提供依赖范围。
runtime:运行时依赖范围。(接口与实现分离)
system:系统依赖范围。非本地仓库引入、存在系统的某个路径下的jar。(一般不使用)
import:导入依赖范围。使用dependencyManagement时候,可以导入依赖配置。(后期讲解)
依赖范围 | 编译classpath有效 | 测试classpath有效 | 运行classpath有效 | 例子 |
---|---|---|---|---|
compile | Y | Y | Y | spring-croe |
test | N | Y | N | junit |
provided | Y | Y | N | servlet-api |
runtime | N | Y | Y | jdbc |
compile(默认)
含义:compile 是默认值,如果没有指定 scope 值,该元素的默认值为 compile。被依赖项目需要参与到当前项目的编译,测试,打包,运行等阶段。打包的时候通常会包含被依赖项目。
演示:gson的scope值就是默认的compile,如果改为test,那么在编译期就找不到gson了,报错。
provided
含义:被依赖项目理论上可以参与编译、测试、运行等阶段,相当于compile,但是再打包阶段做了exclude的动作。
适用场景:例如,如果我们在开发一个web 应用,在编译时我们需要依赖 servlet-api.jar,但是在运行时我们不需要该 jar 包,因为这个 jar 包已由应用服务器提供,此时我们需要使用 provided 进行范围修饰。
演示:把gson的scope值改为provided,编译和测试都没有问题,但是运行时报错,因为应用服务器没有提供gson的jar包。
runtime
含义:表示被依赖项目无需参与项目的编译,但是会参与到项目的测试和运行。与compile相比,被依赖项目无需参与项目的编译。
适用场景:例如,在编译的时候我们不需要 JDBC API 的 jar 包,而在运行的时候我们才需要 JDBC 驱动包。
test
含义:表示被依赖项目仅仅参与测试相关的工作,包括测试代码的编译,执行。
适用场景:例如,Junit 测试。
演示:在src/main/java中无法使用单元测试。
system
含义:system 元素与 provided 元素类似,但是被依赖项不会从 maven 仓库中查找,而是从本地系统中获取,systemPath 元素用于制定本地系统中 jar 文件的路径。例如:
<dependency>
<groupId>org.open</groupId>
<artifactId>open-core</artifactId>
<version>1.5</version>
<scope>system</scope>
<systemPath>${basedir}/WebContent/WEB-INF/lib/open-core.jar</systemPath>
</dependency>
import(了解)
它只使用在<dependencyManagement>中,表示从其它的pom中导入dependency的配置,例如(B项目导入A项目中的包配置):
想必大家在做SpringBoot应用的时候,都会有如下代码:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
</parent>
继承一个父模块,然后再引入相应的依赖。
假如说,我不想继承,或者我想继承多个,怎么做?我们知道Maven的继承和Java的继承一样,是无法实现多重继承的,如果10个、20个甚至更多模块继承自同一个模块,那么按照我们之前的做法,这个父模块的dependencyManagement会包含大量的依赖。如果你想把这些依赖分类以更清晰的管理,那就不可能了,import scope依赖能解决这个问题。你可以把dependencyManagement放到单独的专门用来管理依赖的pom中,然后在需要使用依赖的模块中通过import scope依赖,就可以引入dependencyManagement。例如可以写这样一个用于依赖管理的pom:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.sample</groupId>
<artifactId>base-parent1</artifactId>
<packaging>pom</packaging>
<version>1.0.0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactid>junit</artifactId>
<version>4.8.2</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactid>log4j</artifactId>
<version>1.2.16</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
然后我就可以通过非继承的方式来引入这段依赖管理配置:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.test.sample</groupId>
<artifactid>base-parent1</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependency>
<groupId>junit</groupId>
<artifactid>junit</artifactId>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactid>log4j</artifactId>
</dependency>
注意:import scope只能用在dependencyManagement里面;
这样,父模块的pom就会非常干净,由专门的packaging为pom来管理依赖,也契合的面向对象设计中的单一职责原则。此外,我们还能够创建多个这样的依赖管理pom,以更细化的方式管理依赖。这种做法与面向对象设计中使用组合而非继承也有点相似的味道。
那么,如何用这个方法来解决SpringBoot的那个继承问题呢?
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>1.3.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
这样配置的话,自己的项目里面就不需要继承SpringBoot的module了,而可以继承自己项目的module了。