文章目录
maven总结
1、 Maven概述
2、相关概念解释：
3、Maven的配置
3.1、配置jdk的环境变量
3.2、 配置Maven的环境变量
3.3、Maven本地仓库配置
4 、操作maven项目（命令行方式）
5、 maven应用详解
5.1、仓库
5.2、POM配置详解
5.3、依赖管理 (dependencies)
5.4、依赖的相关配置
5.5、统一维护版本：方便对项目中使用的jar包版本进行升级
5.6、调整编译级别（就是告诉maven用jdk版本编译）：
5.7、聚合
5.8、继承：
5.9、 配置不同环境
6、Maven属性
6.1、内置属性
6.2、POM属性
6.3、自定义属性
6.4、Settings属性
6.5、Java系统属性
6.6、环境变量属性

maven总结

1、 Maven概述
简而言之：maven是一个项目管理工具，它包含了一个项目对象模型（Project Object Model），一组标准集合，一个项目生命周期（Project Lifecycle），一个依赖管理系统（Dependency Management System），和用来运行定义在生命周期阶段（phase）中插件（plugin）目标（goal）的逻辑。

2、相关概念解释：

POM 项目对象模型：pom.xml是maven工程的核心配置文件，可以通过一小段描述信息来管理项目的构建。
标准集合：在maven中有很多种骨架（模板），通过同一种骨架创建项目的结构都是一样的。
项目生命周期：开发一个项目需要经过编译、测试、打包、安装、部署阶段。
依赖管理系统：开发一个项目需要依赖其它的jar包。
插件：maven本身很小，它的很多功能都是通过插件完成的。


3、Maven的配置

3.1、配置jdk的环境变量
mac下；在系统变量/etc/profile里面添加一下；
export MAVEN_HOME="自己的maven地址"
export PATH=$PATH:$MAVEN_HOME/bin

保存修改终端输入：source /etc/profile


3.2、 配置Maven的环境变量
测试是否配置成功：打开cmd，运行：mvn -v（mvn -version），出现相关信息就说明成功了
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-25T03:49:05+08:00)
Maven home: /Users/air/apache-maven-3.5.3
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
Default locale: zh_CN, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"


3.3、Maven本地仓库配置

本地仓库

本地仓库就是一个目录，这个目录被用来存储我们项目的所有依赖（就是jar包），本地仓库供你电脑上所有项目使用，maven所有的jar包都是从中央仓库下载，中央仓库的地址：http://mvnrepository.com/
本地仓库的位置是通过maven的核心配置文件（settings.xml）来配置的
<localRepository> 自己的地址 </localRepository>


配置maven私服

在setting.xml中配置私服，默认是从中央仓库下的，可以改成自己公司的私服，或者阿里云等等
 <mirror>
      <id>nexus-aliyun</id>
      <mirrorOf>*</mirrorOf>
      <name>Nexus aliyun</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
</mirror>



Maven的Mirror和Repository 的详细讲解

4 、操作maven项目（命令行方式）


想要执行mvn命令，需要进入工程所在目录 （即进入到pom.xml 所在目录），所有的mvn命令都必须针对pom.xml运行

编译命令：mvn compile

作用：在工程目录生成target目录，将源码（\src\main）编译为class文件，存放在target/classes目录，不会对测试代码编译；如果对测试代码编译，需要执行mvn test-compile 在target/test-classes 生成class文件

清除命令：mvn clean

作用：清除编译后的结果，会删除target目录及相关文件。


测试命令：mvn test

作用：运行测试，会先对代码自动编译，生成target目录和测试报告；Maven会自动先编译再自动运行测试。

打包命令：mvn package

作用：Java项目自动打成 jar包；Web项目自动打成war包。
打包后文件名的名字为：工程名字（其实是artifactID）-版本-版本性质.jar，SNAPSHOT表示开发版本。另外：如果打包的时候不想执行测试（跳过测试），可以执行：mvn package -Dmaven.test.skip=true


安装命令：mvn install

作用：将项目打包后，安装到本地仓库中；安装jar包到本地仓库目录是有一定规律的，格式如下：${仓库根目录}/groupId/artifactId/version/xxx.jar

mvn deploy

作用：用于发布项目


5、 maven应用详解

5.1、仓库
maven中仓库分为两大类共三种：

本地仓库：在maven的核心配置文件settings.xml 中指定，可以将网络上的jar包缓存到本地仓库，也可以使用mvn install命令将自己开发项目也部署到本地仓库。
远程仓库：网络上的仓库（分两种）


中央仓库：当本地项目依赖其它jar包，而该jar包本地仓库没有，maven就会自动到网络上的中央仓库去找
私服：公司内部搭建服务器，可以快速下载jar包，还可以存放公司内部私密的一些项目


5.2、POM配置详解
① ：文件的根节点，固定的。
② ：pom.xml使用的对象模型版本，一般也都是4.0.0版本。
③ ：创建项目的组织或团体的唯一Id，一般是公司域名的倒写。
④ ：艺术品id, 其实就是项目名。
⑤ ：打包类型，一般有jar、war、pom 等。如果是简单java项目，packaging设置成jar；如果是web项目，packaging设置成war；如果是父工程，packaging设置成pom.
⑥ ：产品的版本号。我们把groupId、artifactId以及version结合起来称为项目的坐标，因为这三个组合在一起可以唯一锁定项目在仓库中的位置，一个项目在仓库中的位置格式：仓库/groupId/artifactId/version/项目包(jar、war)，因此，如果要寻找一个项目，先要获得其项目坐标
⑦ ：项目的显示名，常用于 Maven 生成的文档。
⑧ ：项目描述，常用于 Maven 生成的文档。


5.3、依赖管理 (dependencies)
什么是依赖？在项目工程中，需要用到junit这个jar包，我们就说junit是项目工程的一个依赖，在pom.xml中通过节点来专门声明项目的依赖。要导入jar，首先要得到其坐标，有两种方式获取jar包的坐标：

方式一：通过网站搜索jar包的坐标：http://mvnrepository.com/

为什么只导入核心core一个jar，但会导入除了核心以外的jar？原因是：这个core的jar包会依赖其他jar，其本身的项目中的POM会描述其依赖的jar。

方式二：使用maven插件的搜索功能


5.4、依赖的相关配置
完整的dependency 配置如下：

       <dependency>
            <groupId></groupId>
            <artifactId></artifactId>
            <version></version>
            <classifier></classifier>
            <scope></scope>
            <type></type>
            <systemPath></systemPath>
            <optional></optional>
            <exclusions></exclusions>
        </dependency>

主要介绍几个：
① groupId、artifactId、version是依赖的基本坐标，缺一不可。
② scope：配置依赖范围

compile ：编译时有效，测试时有效、运行时也有效（会被打包），大部分的jar包都是这个范围
test： 编译时无效、测试时有效、运行时无效，不会被打包，例如junit包
provided ：编译时有效，测试时有效，运行时无效，不会被打包，例如servlet-api包
runtime： 编译时无效，测试时有效，运行时有效，会被打包，例如：jdbc驱动包
system:一个jar包如果是在本地，不在maven仓库内，那么scope的取值为system.编译时有效，测试时有效，运行时无效，不会被打包。例如：oracle的驱动包，从中央仓库无法下载，需要先下载到本地，再通过本地路径引入；

<dependency>
			<groupId>oracle</groupId>
			<artifactId>ojdbc</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>C:\apache-maven-3.2.3\repository\ojdbc6.jar</systemPath>
</dependency>




// 也可以将jar包上传到本地仓库，通过坐标查找（推荐）
<dependency>
			<groupId>cn.itcast</groupId>
			<artifactId>ojdbc</artifactId>
			<version>0.0.1-SNAPSHOT</version>
			<scope>runtime</scope>
</dependency>


③ exclusions：排除传递依赖，即某些依赖的jar包不想导入进来。主要用来解决版本冲突问题。
什么是传递性依赖？
如果A依赖D，D依赖X，那X就是A的传递依赖。传递性依赖也称之为间接依赖。
问题：如果两个jar，同时依赖与另外一个jar的不同版本，就可能导致jar冲突问题。这就是传递依赖的jar版本冲突问题。
maven是如何选择版本的呢？（maven的依赖调节策略）
① A->B->C->D->X（1.6）
② A->B->X（2.0）
调解原则：
1、第一原则：路径近者优先原则，上面的情况，会优先选择②X2.0传递给A最近
2、第二原则：第一声明者优先原则：当路径相等的情况下，谁先声明（谁在上面），就用谁的版本
传递性依赖指定某个版本：
如果采用maven自带的调节原则，得到的jar包版本不是我们想要的，就需要采用如下办法来解决

方案一：解决间接依赖，最好的方式就是直接依赖 ，因为直接依赖优先间接依赖
方案二： 锁定版本；对应父的pom文件的代码，使用了对依赖的版本进行锁定

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
                <version>4.3.13.RELEASE</version>
            </dependency>
        </dependencies>
    </dependencyManagement>




方案三：exclusions排除依赖

<dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.0.6.RELEASE</version>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework</groupId>
                    <artifactId>spring-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>


5.5、统一维护版本：方便对项目中使用的jar包版本进行升级

第一步 ：在父类pom.xml中使用属性定义jar包的版本

<!-- 集中定义依赖版本号 -->
    <properties>
        <junit.version>4.12</junit.version>
    </properties>




第二步 ：在依赖的中使用${}引入前面定义好的版本

<dependencyManagement>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
  </dependency>
</dependencyManagement>


5.6、调整编译级别（就是告诉maven用jdk版本编译）：
方式一：全局设置：首先我们要在settings.xml文件中找到标签，然后在此标签内部粘贴如下配置：
<profile>
    <id>jdk-1.8</id>
    <activation>
        <jdk>1.8</jdk>
    </activation>
    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
    </properties>
</profile>


方式二：单个项目单独设置：如果需要在某个项目中指定编译级别，可以在项目的pom.xml文件中配置，如下：
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
    </plugins>
</build>


5.7、聚合


在父级项目中，通过modules标签将项目的所有子项目引用进来，在build父级项目时，会根据子模块的相互依赖关系整理一个build顺序，然后依次build。所有的父级项目的packaging都为pom，packaging默认是jar类型，如果不作配置，maven会将该项目打成jar包。
 <groupId>com.sto.report</groupId>
 <artifactId>sto-terminal-report</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>pom</packaging>
 
 <modules>
     <!-- project -->
     <module>sto-terminal-report-admin</module>
     <module>sto-terminal-report-api</module>
     <module>sto-terminal-report-job</module>
 </modules>


5.8、继承：
一个maven工程继承父工程后，就可以重用父工程的一些配置，在实际开发中，公司都会有一个现成的父工程，来管理我们可能用到的依赖的版本。
 <parent>
   <groupId>com.sto.report</groupId>
   <artifactId>sto-terminal-report</artifactId>
   <version>0.0.1-SNAPSHOT</version>
</parent>


5.9、 配置不同环境
<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <profileActive>dev</profileActive>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <profile>
        <id>pro</id>
        <properties>
            <profileActive>pro</profileActive>
        </properties>
    </profile>
</profiles>

<build>
    <finalName>${project.artifactId}</finalName>
    <resources>

        <resource>
            <directory>src/main/resources</directory>
            <filtering>false</filtering>
            <excludes>
                <exclude>config/**</exclude>
            </excludes>
        </resource>

        <resource>
            <directory>src/main/resources/config/${profileActive}</directory>
            <filtering>true</filtering>
            <includes>
                <include>application-${profileActive}.yml</include>
                <include>application-${profileActive}.properties</include>
            </includes>
        </resource>

    </resources>
</build>



include与exclude

Maven resource 中的与用于包含或排除某一文件目录下的文件是否是工程资源的。
若与划定的范围存在冲突，则以配置为准。
多数情况下，使用和是为了配合实现替换文件中的变量的需要。
如上事例：
其中第一段配置声明：在src/main/resources目录下，仅application–${profileActive}.yml和application-${profileActive}.properties两个文件是资源文件，然后，这两个文件需要被过滤。而第二段配置声明：同样在src/main/resources目录下，除config/**目录下外的其他文件也是资源文件，但是它们不会被过滤。



filtering



maven 通过过滤器来修改部署时的不同配置。



如果配置了多个 filter，并且两个 filter 中有相同的 key，则后面的 value 为最终取值。

  
    src/main/filters/production.properties
    src/main/filters/test.properties
  
	





切换启动不同的环境

// 如果不指定环境，默认是activeByDefault=true的环境，当前是指开发环境
mvn package



// 打包指定的环境通过-P 参数，注意p是大写的
mvn package -P 


6、Maven属性
Maven总共有6类属性，内置属性、POM属性、自定义属性、Settings属性、java系统属性和环境变量属性；


6.1、内置属性
两个常用内置属性 ${basedir} 表示项目跟目录，即包含pom.xml文件的目录；${version} 表示项目版本


6.2、POM属性
用户可以使用该类属性引用POM文件中对应元素的值。如${project.artifactId}就对应了 元素的值，常用的POM属性包括：

${project.build.sourceDirectory}:项目的主源码目录，默认为src/main/java/
${project.build.testSourceDirectory}:项目的测试源码目录，默认为src/test/java/
${project.build.directory} ： 项目构建输出目录，默认为target/
${project.outputDirectory} : 项目主代码编译输出目录，默认为target/classes/
${project.testOutputDirectory}：项目测试主代码输出目录，默认为target/testclasses/
${project.groupId}：项目的groupId
${project.artifactId}：项目的artifactId
${project.version}：项目的version,与${version} 等价
${project.build.finalName}：项目打包输出文件的名称，默认为${project.artifactId}-${project.version}



6.3、自定义属性
随便写


6.4、Settings属性
与POM属性同理，用户使用以settings. 开头的属性引用settings.xml文件中的XML元素的值。


6.5、Java系统属性
所有java系统属性都可以用Maven属性引用，如${user.home}指向了用户目录。


6.6、环境变量属性
所有环境变量属性都可以使用以env. 开头的Maven属性引用，如${env.JAVA_HOME}指代了JAVA_HOME环境变量的的值。

将项目分为了子父子模块项目后，遇到了不少问题，还是原来单模块管理简单，但是为了项目将来能够随引用的脚手架升级而升级，还是将项目改为父子模块结构，并且尽量不修改引用脚手架的结构，将自己的应用都添加到两个新模块中。再改造后，遇到最莫名其妙的一个问题就是间接依赖引用的一个包自动降级，导致系统出问题，研究了好久才搞明白怎么回事，没有找到根本的解决方法，通过复杂的排除临时解决了问题，特此记录一下。
一、问题介绍
修改后的模块Root是根模块，组织其它模块，A、B、C是原有的模块，自己新加了两个模块一个是基础内容模块Q、一个是WEB及功能模块T，A模块是APP所在组件，A依赖B、C、Q和T。
在T模块中，有讯飞语音组件，该组件需要需要okhttp组件，如下所示，该组件又依赖了okio和lotlin-stdlib两个组件，在查询这三个组件内容和原来的单模块组件下，kotlin-stdlib都是1.3.70版本，但是转换为多模块无论如何修改，kotlin-stdlib都是1.2.71版本，不会更新。程序在运行时，会先找到1.2.71的包，由于1.2.71版本缺省copyInto方法，会报下面错误。
NoSuchMethodError: kotlin.collections.ArraysKt.copyInto
二、问题原因分析
通过与原来的单模块反复对比，也试过各种版本调整，问题仍不能解决，kotlin-stdlib效有效版本总是1.2.71.
打开模块T的pom文件，查看结构，检查冲突会出现以下内容，明确出冲突：
打、开项目文件树的A模块的iml文件发现有stdlib1.2.71内容，通过关系查询，发现是A依赖T，通过T模块引用而来，但是版本总是1.2.71，通过okhttp 4.7.2文件对应，应该是1.3.71才对，但是idea不知为何，引进的总是1.2.71,导致系统问题。
查看，项目External Libraries，如下图，是旧版本。
三、解决方法
发现这个问题原因后，先做了以下几面尝试，
1、排除kotlin-stdlib不引用
NoClassDefFoundError: kotlin/jvm/internal/Intrinsics，
也就是kotlin-stdlib是必须引用的
2、在T模块将，在引用okhttp3时，将kotlin-stdlib排除，单独直接引用正确的版如下所示，注意kotlin-stdlib引用要放到前面。用此方法后，在T模块查看maven依赖关系时，没有冲突。
     kotlin-stdlib     org.jetbrains.kotlin1.3.70com.squareup.okhttp3    okhttp    4.7.2            kotlin-stdlib            org.jetbrains.kotlin
这个方法在T模块有冲突，但是编译后仍不能使用，再回到A模块查看，发现A模块存在冲突，查捍IML文件和External Libraries时，发现kotlin-stdlib有1.2.71和1.3.70两行，都是继续T模块过来的，发现1.2.71总是会通过T模块隐性继承过秋，不知道是什么因原，可能是为了排除警告一个获信息，在T模块加过下面依赖，下面依赖会间接依赖kotlin-stdlib的1.2.71版本，删除后仍然不误，在A模块总是两行，系统使用时仍只会使用1.2.71版本。
com.fasterxml.jackson.module jackson-module-kotlin 2.11.0
3、尝试直接修改A.iml文件，删除1.2.71，只保留1.3.70，External Libraries只有1.3.70一行，编译项目，系统功能能够使用。
4、分析主要的依赖路径问题，路径短的优先，于是将下面依赖放到A模块，并且在依赖T模块前引用，此时发现A.iml和External Libraries只有1.3.70一行,虽然在A模块冲突检查有信息，但是功能不受影响，先继续使用。
     kotlin-stdlib     org.jetbrains.kotlin1.3.70
四、小结
通过这个问题解决，对Maven模块依赖传递进行了核查和研究，Maven模块的依赖的确挺复杂，在idea下还可能有莫名其妙的问题，在使用时还是需要多加关注。

自2019年起，Oracle Java 8将不再获得免费的安全更新，现在是时候迁移到JDK 11了。
如果你想迁移到Java 11，但你的Maven项目仍然在Java 8上？你可能并不关心Java 9中引入的新模块系统(Jigsaw)，只希望你的应用程序在最新的JDK版本上运行？那么本指南适合你，它包括我在将产品迁移到Java 11时学到的所有内容。
清理你的pom.xml文件＃
在考虑升级Java版本之前，你应该做的第一件事就是清理pom.xml文件。
如果你的项目是一个多模块Maven项目，则需要建立一个父POM文件，其中有dependencyManagement pluginManagement选项，所有插件和依赖项都在这个文件中定义了，并且不会分布在多个POM文件中，这使得管理版本变得更加容易。
为了将项目迁移到最新的Java版本11，强烈建议尽可能多地更新插件和依赖项到最新的稳定版本，如果使用旧版本，许多插件(如编译器插件，surefire或failsafe)与Java 9不兼容，此外，许多库在不迁移到最新版本的情况下也不兼容。
确保你在主POM中配置了版本插件：
org.codehaus.mojo
versions-maven-plugin
2.5
false
此插件有助于查找模块的最新插件或依赖版本，打开终端并执行此命令以查找你必须更新的插件版本：
mvn versions:display-plugin-updates
你将看到项目中使用的插件列表，其中包含更新的版本，将所有这些插件更新到最新的稳定版本，更新插件版本后，请确保你的项目仍然可以编译并正常运行。
你可以从项目根目录中使用mvn -N ...，能在多模块项目的情况下检查你的父POM。
配置Java 11的插件
Java 11最重要的插件是编译器插件，surefire(用于单元测试)和failsafe (用于集成测试)。
为了编译Java 11项目，请将release配置添加到编译器插件中，这是一个新的编译器参数，用于替换source和target版本参数：
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
11
另外，不要忘记将IDE项目SDK设置为相同的JDK版本。在Intellij IDEA中，转到模块设置 - >项目 - > SDK。
对于surefire和failsafe插件，我们添加了一个额外的参数，--illegal-access=permit以允许第三方库的所有反射访问：
org.apache.maven.plugins
maven-surefire-plugin
2.22.0
--illegal-access=permit
org.apache.maven.plugins
maven-failsafe-plugin
2.22.0
--illegal-access=permit
只有在依赖项大量使用反射时才需要这样做，如果你不确定是否需要这个，如果你的测试遇到麻烦，可以添加配置argLine选项。
在不添加这个选项情况下，当库包试图通过setAccessible(true)非法访问类时，你会看到下面的警告：
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
请记住，你需要在启动应用程序时传递参数--illegal-access=permit。
更新依赖项＃
如前所述，你可以做的最好的事情是将所有依赖项迁移到最新的稳定版本，以确保Java 11的一切正常。虽然许多较旧的依赖项可能正常工作但有一些依赖项，其中版本更新是必需的，例如各种不同的字节码增强工具：libaries javassist，cglib，asm或byte-buddy等。这些库通常作为依赖传递，因此请确保至少这些库是最新的。
org.javassist
javassist
3.23.1-GA
cglib
cglib-nodep
3.2.7
下面命令有助于从模块中查找过时的依赖项版本：
mvn versions:display-dependency-updates
升级尽可能多的库到最新的稳定版本。如果由于项目中的兼容性问题导致你无法更新某些依赖项，但还是不要保留原样，改写它，有可能它在Java 11中运行良好。
现在是第一次使用JDK 11编译项目的好时机：
mvn clean test-compile compile
提示：你可以通过使用并行构建来加速多模块Maven项目，例如mvn -T 4 compile，这个命令可以在4个CPU内核上并行编译所有模块。
你可能会面临不同的编译器错误，例如ClassNotFoundException，每个项目都不同，所以我无法为你面临的每个问题提供解决方案。
本文的下面部分描述了升级JDK 11时必须解决的问题。
添加缺少的模块＃
随着Java 9中Java模块系统(Jigsaw)的引入，Java标准库已被分成单独的模块，虽然大多数类没有任何变化，但有些类则会，你必须明确定义应用程序需要访问的其他模块，或者只需从Maven中央存储库添加这些模块即可。
java --list-modules这个命令能列出了所有可用的模块。
将我们的Web项目迁移到Java 11时，我们必须添加jaxb和javax.annotations，防止出现ClassNotFoundException，下面是我们已将以下库作为其他Maven依赖项添加到我们的POM中：
javax.annotation
javax.annotation-api
1.3.2
javax.xml.bind
jaxb-api
2.4.0-b180725.0427
org.glassfish.jaxb
jaxb-runtime
2.4.0-b180725.0644
我们可以利用Java的–add-modulesJava参数向项目添加额外的JDK模块，注意不是通过Maven添加这些库的。
修复sun.*和com.sun.*等包的导入问题
虽然JDK的一些类已经转移到其他Java模块，但其他类就不能再用了，比如来自sun.*包的类以及来自的一些类com.sun.*，如果你的代码有链接到这些包中的类而导致编译器错误，则必须从代码中删除这些导入。
以下是我们在项目中需要解决的一些问题：
1. sun.misc.BASE64Encoder：这可以简单地替换为java.util.Base64.getEncoder()，这是自Java 8以来就可用的。
2. sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl：这个类在我们的代码库中被意外使用，可以简单地用接口类型替换java.lang.reflect.ParameterizedType。
3. sun.reflect.annotation.AnnotationParser：我们使用此类以编程方式创建注释实例，该类不再可访问，但可以用AnnotationFactoryHibernate Validator 替换。
4. com.sun.org.apache.xml.internal.utils.DefaultErrorHandler：我们已经用接口的自定义实现替换了这个类。
货币格式＃
我们遇到了一个奇怪的案例，Locale.GERMANY其中包含语言环境的数字格式，例如，它让我们的一系列测试失败并出现了一个相当奇怪的断言错误：
java.lang.AssertionError:
Expected: is "9,80 €"
but: was "9,80 €"
底层代码是使用NumberFormat.getCurrencyInstance(Locale.GERMANY)将数字格式化为德国货币格式，那么到底发生了什么？
Java的数字格式已被修改为使用非中断空格而不是数字和货币符号之间的正常空格。这种变化非常有意义，因为它可以防止在数字和货币符号之间的插入各种格式的换行符，更改测试中的字符串以使用不间断空格(在Mac OSX键盘上使用OPTION SPACE)修复了此问题。
Servlet容器＃
使用Apache Tomcat运行Web应用程序时，至少需要Apache Tomcat 7.0.85或更高版本，否则Tomcat将无法在Java 9及更高版本上启动，你将看到以下错误：
/path/to/apache-tomcat-7.0.64/bin/catalina.sh run
-Djava.endorsed.dirs=/path/to/apache-tomcat-7.0.64/endorsed is not supported. Endorsed standards and standalone APIs
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
in modular form will be supported via the concept of upgradeable modules.
Disconnected from server
另外，不要忘记最终添加启动参数--illegal-access=permit到你的servlet容器中。

2.目前的技术在开发中存在的问题

①一个项目就是一个工程

如果项目非常庞大,就不适合继续使用package来划分模块。最好是每一个模块对应一个工程,利于分工协作。借助于Maven就可以将一个项目拆分成多个工程。

②项目中需要的jar包必须手动“复制”、“粘贴” 到WEB-INF/lib目录下带来的问题是:同样的jar包文件重复出现在不同的项目工程中, 一方 面浪费存储空间,另外也让工程比较臃肿。

③jar包需要别人替我们准备好,或到官网下载

不同技术的官网提供jar包下载的形式是五花八门的。

有些技术的官网就是通过Maven或SVN等专门的工具来提供下载的。

如果是以不规范的方式下载的jar包,那么其中的内容很可能也是不规范的。

借助于Maven可以以一种规范的方式下载jar包。因为所有知名框架或第三方工具的jar包以及按照统一的规范存放在了Maven的中央仓库中。以规范的方式下载的jar包.内容也是可靠的。

Tips:“统一的规范”不仅是对IT开发领域非常重要,对于整个人类社会都是非常重要的。

④一个jar包依赖的其他jar包需要自己手动加入到项目中

FileUpload组件→I0组件。 commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar.

如果所有jar包之间的依赖关系都需要程序员自己非常清楚的了解,那么就会极大的增加学习成本。

Maven会自动将被依赖的jar包导入进来。

3.Maven是什么[What]

①Maven是一款服务于Java平台的自动化构建工具。

②构建

[1]概念:以"Java源文件"、”框架配置文件” 、"JSP" 、“HTML"、 “图片” 等资源为“原材料”,去“生产”一个可以运行的项目的过程。

■编译

■部署

■搭建

[2]编译: Java源文件[User.java]→+编译→Class字节码文件[User.class]→+交给JVM去执行

[3]部署:一个BS项目最终运行的并不是动态Web工程本身,而是这个动态Web工程“编译的结果”

生的鸡→处理→+熟的鸡

动态Web工程→编译、部署→ +编译结果

Tips :运行时环境


其实是一组jar包的引用,并没有把jar包本身复制到工程中所以并不是目录。



③构建过程中的各个环节

[1]清理:将以前编译得到的旧的class字节码文件删除，为下一次编译做准备

[2]编译:将Java源程序编程成class字节码文件

[3]测试:自动测试，自动调用junit程序

[4]报告:测试程序执行的结果

[5]打包:动态Web工程打war包. Java工程打jar包

[6]安装: Maven特定的概念一将打 J包得到的文件复制到"仓库”中的指定位置

[7]部署:将动态Web工程生成的war包复制到Servlet容器的指定目录下,使其可以运行

④自动化构建

4.安装Maven核心程序

①检查JAVA HOME环境变量

C:\Windows\System32> echo %JAVA_ HOME%

D:\DeviInstallNjdk1.7.0_ 07

②解压Maven核心程序的压缩包,放在一个非中文无空格路径下

D:\DevInstallapache-maven-3.2.2

③配置Maven相关的环境变量


④验证:运行mvn -v命令查看

5.Maven的核心概念

①约定的目录结构

②POM

③坐标

④依赖.

⑤仓库.

⑥生命周期/插件/目标

⑦继承

⑧聚合

6.第一个Maven工程

①创建约定的目录结构

[1]根目录:工程名

[2]src目录:源码

[3]pom.xml文件: Maven工程的核心配置文件

[4]main目录:存放主程序

[5]test目录:存放测试程序

[6]java目录:存放Java源文件

[7]resources目录:存放框架或其他工具的配置文件

②为什么要遵守约定的目录结构呢?

Maven要负责我们这个项目的自动化构建.以编译为例. Maven要想自动进行编译.那么它必须知道

Java源文件保存在哪里。

如果我们自己自定义的东西想要让框架或工具知道.有两种办法

■以配置的方式明确告诉框架



遵守框架内部已经存在的约定
约定>配置>编码
7.常用Maven命令
①注意:执行与构建过程相关的Maven命令,必须进入pom.xml所在的目录。

与构建过程相关:编译、测试、打包、....

②常用命令

[1]mvn clean :清理

[2]mvn compile :编译主程序

[3]mvn test-compile :编译测试程序

[4]mvn test :执行测试

[5]mvn package :打包

[6]mvn install :安装。

[7]mvn site :生成站点
8.关于联网问题

①Maven的核心程序中仅仅定义了抽象的生命周期.但是具体的工作必须由特定的插件来完成。而插件本身

并不包含在Maven的核心程序中。

②当我们执行的Maven命令需要用到某些插件时, Maven核心程序会首先到本地仓库中查找。

③本地仓库的默认位置: [系统中当前用户的家目录]\.m2Vrepository


④Maven核心程序如果在本地仓库中找不到需要的插件,那么它会自动连接外网,到中央仓库下载。

⑤如果此时无法连接外网,则构建失败。

⑥修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件

[1]找到Maven解压目录\conf\settings.xml

[2]在settings.xml文件中找到localRepository标签

[3]将<localRepository> /path/to/local/repo< /localRepository>从注释中取出

[4]将标签体内容修改为已经准备好的Maven仓库目录


9.POM

①含义: Project Object Model项目对象模型

DOM Document Object Model文档对象模型

②pom.xml对于Maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。重要程度相当于web.xml对于动态Web工程
10.坐标

Maven的坐标

使用下面三个向量在仓库中唯一定位一个Maven工程

[1]groupid :公司或组织域名倒序+项目名

<groupid> com.atguigu.maven</groupid>

[2]artifactid :模块名

< artifactid> Hello</artifactid>

[3]version:版本

<version> 1.0.0</version>

Maven工程的坐标与仓库中路径的对应关系


11.仓库

①仓库的分类

[1]本地仓库:当前电脑上部署的仓库目录,为当前电脑上所有Maven工程服务

[2]远程仓库

(1)私服:搭建在局域网环境中.为局域网范围内的所有Maven工程服务

(2)中央仓库:架设在Internet上,为全世界所有Maven工程服务

(3)中央仓库镜像:为了分担中央仓库的流量,提升用户访问速度

②仓库中保存的内容: Maven工程

[1]Maven自身所需要的插件

[2]第三方框架或工具的jar包

[3]我们自己开发的Maven工程

12.依赖

①Maven解析依赖信息时会到本地仓库中查找被依赖的jar包。

对于我们自己开发的Maven工程,使用mvn install命令安装后就可以进入仓库。

②依赖的范围


[1]compile范围依赖

■对主程序是否有效:有效

■对测试程序是否有效:有效

■是否参与打包:参与

■是否参与部署:参与

■典型例子: spring-core

[2]test范围依赖

■对主程序是否有效:无效

■对测试程序是否有效:有效

■是否参与打包:不参与

■是否参与部署:不参与

■典型例子: junit

[3]provided范围依赖

■对主程序是否有效:有效

■对测试程序是否有效:有效

■是否参与打包:不参与

■是否参与部署:不参与

■典型例子: servlet-apijar

 



13.生命周期

①各个构建环节执行的顺序:不能打乱顺序,必须按照既定的正确顺序来执行。

②Maven的核心程序中定义了抽象的生命周期.生命周期中各个阶段的具体任务是由插件来完成的。

③Maven核心程序为了更好的实现自动化构建,按照这一的特点执行生命周期中的各个阶段:不论现在要执

行生命周期中的哪一个阶段,都是从这个生命周期最初的位置开始执行。

④插件和目标

[1]生命周期的各个阶段仅仅定义了要执行的任务是什么。

[2]各个阶段和插件的目标是对应的。

[3]相似的目标由特定的插件来完成。