maven web项目部署后访问时显示localhost拒绝_Maven--笔记

一、maven概述

1.为何使用Maven?

解决jar包获取难、每个项目独立一份、包依赖问题和jar包的冲突问题

首先要了解依赖的概念：就像我们写java代码一样，类与类之间有各种联系，同样的jar包也不是孤立存在的，同样需要其他jar包的支持才能用，否则不能正常工作，这就是jar包之间的依赖关系，所有如果要用到一个jar包时，就要把他依赖的所有jar包都导入，怎么确定一个jar包都是有哪些依赖呢？这是一个很难解决的问题，而Maven就很好的帮我们解决了这个问题。

2.Maven是什么？

Maven是一款自动化构建工具，专注于服务Java平台的项目的构建和依赖管理

Maven有本地仓库和中央镜像仓库，本地库里面就是你本机里面的jar包，中央镜像仓库里面几乎是所有的能用到的jar包，有专人管理；使用了Maven后，Maven就可以代替我们自动将当前jar包所依赖的其他所有jar包全部导入进来，它会先去你本地仓库找，如果没找到则去中央镜像仓库下载到你本地仓库里面。

3.什么是jar包之间的冲突，如何处理？

jar包冲突就是当有依赖关系的几个jar包中，都依赖了相同的jar包但是jar包的版本不一样，此时就造成了jar包冲突。

解决jar包冲突的两大原则：最短路径者优先和先声明者优先

例图：

4.如何构建一个项目？

构建的概念：构建并不是创建，是将我们编写的java代码、配置文件、jsp页面和图片等一些静态资源作为原材料，经过一定的步骤去生成一个可以运行的项目的过程

构建的步骤：

（1）清理：删除以前的编译结果，为重新编译做好准备。

（2）编译：将Java源程序编译为字节码文件。

（3）测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。

（4）报告：在每一次测试后以标准的格式记录和展示测试结果。

（5）打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。

（6）安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库中。

（7）部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。

二、Maven的核心概念

Maven的核心概念包括：POM、约定的目录结构、坐标、依赖、仓库、声明周期、插件和目标、继承、聚合。下面开始逐一说

1.POM

Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。

2.约定的目录结构

首先要明白一个观点：约定>配置>编码

意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。

3.坐标

Maven中的坐标

Maven通过三个向量来确定一个Maven工程

（1）groupId：公司或组织的域名倒序+当前项目名称

（2）artifactId：当前项目的模块名称

（3）version：当前模块的版本

 <dependencies>
     <!--坐标-->
     <dependency>
         <groupId>maven</groupId>
         <artifactId>Hello</artifactId>
         <version>1.0-SNAPSHOT</version>
     </dependency>
     
     <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>4.0</version>
         <scope>test</scope>
     </dependency>
 </dependencies>
 ​

4.依赖管理

概念：当Ajar包中需要用到Bjar包中的类时，就是A对B有依赖

依赖关系的导入：使用dependency标签指定目标jar包的坐标

例：

直接依赖和间接依赖：如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。

依赖的范围：

1）compile（默认就是这个范围）

（1）main目录下的Java代码可以访问这个范围的依赖

（2）test目录下的Java代码可以访问这个范围的依赖

（3）部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下

例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。

2）test

（1）main目录下的Java代码不能访问这个范围的依赖

（2）test目录下的Java代码可以访问这个范围的依赖

（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：对junit的依赖。仅仅是测试程序部分需要。

3）provided

（1）main目录下的Java代码可以访问这个范围的依赖

（2）test目录下的Java代码可以访问这个范围的依赖

（3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。

4）其他（了解）：

• runtime：只对测试和运行有效，编译无效，如JDBC驱动的实现
• system：对编译、测试有效，但是需要通过配置systemPath来显示指定依赖文件的路径
• import：将目标pom文件中dependencyManagement的配置导入合并到当前pom的dependencyManagement中

 <dependency>
     <groupId>javax.sql</groupId>
     <artifactId>jdbc-stext</artifactId>
     <version>2.0</version>
     <scope>system</scope>
     <systemPath>${java.home}/lib/rt.jar</systemPath> 
 </dependency>

各个依赖范围的作用可以概括为下表：

依赖的传递性：只有依赖范围是compile时才具有依赖的传递性

依赖的原则：最短路径者优先和先声明者优先

依赖的排除：当自身与所依赖的jar包都依赖的相同的jar包但是版本不同，可以通过依赖排除间接依赖

 <dependency>
     <groupId>maven</groupId>
     <artifactId>OurFriends</artifactId>
     <version>1.0-SNAPSHOT</version>
 ​
     <!--依赖排除-->
     <exclusions>
         <exclusion>
             <groupId>commons-logging</groupId>
             <artifactId>commons-logging</artifactId>
         </exclusion>
     </exclusions>
 </dependency>
 ​
 <dependency>
     <groupId>commons-logging</groupId>
     <artifactId>commons-logging</artifactId>
     <version>1.1.2</version>
 </dependency>
 ​

5.统一管理jar包版本：

当使用同一jar包中的不同的子jar时，可以对jar包版本做统一配置，这样在后期改动时比较方便

例如

 <!--统一管理当前模块的jar包的版本-->
 <properties>
     <spring.version>4.0.0.RELEASE</spring.version>
 </properties>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-context</artifactId>
     <version>${spring.version}</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-webmvc</artifactId>
     <version>${spring.version}</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-jdbc</artifactId>
     <version>${spring.version}</version>
 </dependency>
 <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-orm</artifactId>
     <version>${spring.version}</version>
 </dependency>
 ​

6.仓库

• 本地仓库：为当前本机电脑上的所有Maven工程服务。
• 远程仓库：
  • 中央仓库：架设在Internet上，为全世界所有Maven工程服务。
  • 中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。
  • 私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。

7.生命周期

Maven有三套相互独立的生命周期，分别是：

Ø Clean Lifecycle在进行真正的构建之前进行一些清理工作。

Ø Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。

Ø Site Lifecycle生成项目报告，站点，发布站点。

运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven为什么能够自动执行构建过程的各个环节的原因。此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要。

8.插件与目标

（1）Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。

（2）每个插件都能实现多个功能，每个功能就是一个插件目标。

（3）Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

例如：compile就是插件maven-compiler-plugin的一个功能；pre-clean是插件maven-clean-plugin的一个目标。

9.继承

使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。

父工程：

 <groupId>com.atguigu.maven</groupId>
 <artifactId>Parent</artifactId>
 <packaging>pom</packaging>
 <version>1.0-SNAPSHOT</version>
 <!--父工程的打包方式为pom，只需要保留pom.xml文件即可-->
 ​
 <!--依赖管理-->
 <dependencyManagement>
     <dependencies>
         <dependency>
             <groupId>junit</groupId>
             <artifactId>junit</artifactId>
             <version>4.0</version>
             <scope>test</scope>
         </dependency>
     </dependencies>
 </dependencyManagement>
 ​

子工程：

 <!--继承-->
 <parent>
     <groupId>com.atguigu.maven</groupId>
     <artifactId>Parent</artifactId>
     <version>1.0-SNAPSHOT</version>
 <!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
 <relativePath>../Parent/pom.xml</relativePath>
 </parent>
 <!--如果子工程的groupId和version如果和父工程重复则可以删除-->
 ​
 <!--在子项目中重新指定需要的依赖，删除范围和版本号-->
 <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
 </dependency>
 ​

10.聚合

使用了聚合之后就可以批量进行Maven工程的安装、清理工作。

Maven可以根据各个模块的继承和依赖关系自动选择安装的顺序，在总的聚合工程中使用modules/module标签组合，指定模块工程的相对路径即可

 <!--聚合-->
 <modules>
     <module>../MakeFriend</module>
     <module>../OurFriends</module>
     <module>../HelloFriend</module>
     <module>../Hello</module>
 </modules>
 ​