7、编译
此时直接执行 mvn compile 命令出错：【记得去pom.xml文件所在目录运行】
上面的错误信息说明：我们的 Web 工程用到了 HttpServlet 这个类，而 HttpServlet 这个类属于 servlet-api.jar 这个 jar 包。此时我们说，Web 工程需要依赖 servlet-api.jar 包。
8、配置对 servlet-api.jar 包的依赖
对于不知道详细信息的依赖可以到https://mvnrepository.com/网站查询。
- 有很多的时候注意区别：看组织
- 有很多版本的时候一般选下载人最多的
比如，我们找到的 servlet-api 的依赖信息：
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency>
- 这样就可以把上面的信息加入 pom.xml。在 【dependencies 标签里面添加】重新执行 mvn clean compile 命令。【mvn命令可以组合执行】
网络异常，图片无法展示|
9、将 Web 工程打包为 war 包
运行 mvn package 命令，生成 war 包的位置如下图所示：
10、将 war 包部署到 Tomcat 上运行
【最原始的部署方式，能够运行起来就行，了解内容】
将 war 包复制到 Tomcat/webapps 目录下【复制那个解压过的文件夹就可以】
- 复制完后，名称可以随意更改
- 然后运行tomcat
- 在浏览器粘贴自己的端口号加你的项目名称名【即你更改过的那个名称的名字】
- 将 war 包复制到 Tomcat/webapps 目录下，启动tomcat 会自动解压
实验五：WEB工程依赖Java工程
1、概念
- 从来只有 Web 工程依赖 Java 工程，没有反过来 Java 工程依赖 Web 工程。
- 即 war包里面可以有个jar包
2、操作
在 pro02-maven-web 工程的 pom.xml 中，找到 dependencies 标签，在 dependencies 标签中做如下配置：
<!-- 配置对Java工程pro01-maven-java的依赖 --> <!-- 具体的配置方式：在dependency标签内使用坐标实现依赖 --> <dependency> <groupId>com.atguigu.maven</groupId> <artifactId>pro01-maven-java</artifactId> <version>1.0-SNAPSHOT</version> </dependency>
3、在 Web 工程中，编写测试代码
①补充创建目录
pro02-maven-web\src\test\java\com\atguigu\maven
②确认 Web 工程依赖了 junit
<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency>
③创建测试类
把 Java 工程的 CalculatorTest.java 类复制到 pro02-maven-wb\src\test\java\com\atguigu\maven 目录下
4、执行Maven命令
①测试命令
mvn test
说明：测试操作中会提前自动执行编译操作，测试成功就说明编译也是成功的。
②打包命令
mvn package
通过查看 war 包内的结构，我们看到被 Web 工程依赖的 Java 工程确实是会变成 Web 工程的 WEB-INF/lib 目录下的 jar 包。
③查看当前 Web 工程所依赖的 jar 包的列表
mvn dependency:list
[INFO] The following files have been resolved:
[INFO] org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO] junit:junit:jar:4.12:test
说明：javax.servlet:javax.servlet-api:jar:3.1.0:provided 格式显示的是一个 jar 包的坐标信息。格式是：
groupId:artifactId:打包方式:version:依赖的范围
- 这样的格式虽然和我们 XML 配置文件中坐标的格式不同，但是本质上还是坐标信息
- 将来从 Maven 命令的日志或错误信息中看到这样格式的信息，就能够识别出来这是坐标。
- 根据坐标到Maven 仓库找到对应的jar包，用这样的方式解决我们遇到的报错的情况。
④以树形结构查看当前 Web 工程的依赖信息
mvn dependency:tree [INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT [INFO] +- junit:junit:jar:4.12:test [INFO] | - org.hamcrest:hamcrest-core:jar:1.3:test [INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided [INFO] - com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
- 我们在 pom.xml 中并没有依赖 hamcrest-core，但是它却被加入了我们依赖的列表。原因是：junit 依赖了hamcrest-core，然后基于依赖的传递性，hamcrest-core 被传递到我们的工程了。
实验六：测试依赖的范围【重点】
1、依赖范围
- 标签的位置：dependencies/dependency/scope
- scope标签的可选值：compile/test/provided/system/runtime/import
- 不选代表默认值，compile
①compile 和 test 对比
②compile 和 provided 对比
③结论【重点】
- compile：通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。
- test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。
- provided：在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。
- 而这个范围的 jar 包之所以不参与部署、不放进 war 包，就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。
2、测试
①验证 compile 范围对 main 目录有效
main目录下的类：HelloServlet 使用compile范围导入的依赖：pro01-atguigu-maven
验证：使用compile范围导入的依赖对main目录下的类来说是有效的
有效：HelloServlet 能够使用 pro01-atguigu-maven 工程中的 Calculator 类
验证方式：在 HelloServlet 类中导入 Calculator 类，然后编译就说明有效。
