Maven

项目构建过程

1. 清理：将以前编译的旧class字节码文件删除，为下一次编译做准备
2. 编译：将java源程序编译成字节码文件
3. 测试：自动测试，自动调用junit程序
4. 报告：测试程序执行的结果
5. 打包：动态web工程打war包，java工程打jar包；
6. 安装：Maven特定的概念–将打包得到的文件复制到仓库中指定位置
7. 部署：将动态web工程生成的war包复制到servlet容器的值目录下

Maven安装

1. 解压部署Maven核心包，将之放到一个特定目录下
   1. 检查JAVA_HOME环境变量
   2. 配置maven环境变量 MAVEN_HOME(M2_HOME)跟PATH变量
   3. 使用mvn -v检查是否安装成功
2. 修改本地仓库
3. maven目录结构
   hello
   |--------src
   |---------|--------main
   |---------|-----------|-------java
   |---------|-----------|-------resource
   |---------|--------test
   |---------|-----------|------java
   |---------|-----------|-------resource
   |--------pom.xml
4. 常用的maven命令
   a) mvn clean:清理
   b) mvn compile:编译主程序
   c) mvn test-compile：编译测试程序
   d) mvn test ：执行测试
   e) mvn package：打包
   f) mvn install:安装
   g) mvn site：生成站点文件
5. pom
   a) Project Object Model :项目对象模型
6. 坐标（gav）：使用下面三个向量可以在仓库中唯一定位一个Maven工程
   a) groupid：公司或者组织域名倒序+项目名
   b) artifactid：模块名
   c) version：版本
7. maven管理jar包的方式groupId/artifactId/version/artifactId-version.jar
   a) 比如说commons-lang的pom文件是这么定义三个坐标的：
   b) 那么就是repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
   c) 其中如果groupId中有点号".“则替换成”/"
   commons-lang
   commons-lang
   2.1
8. 仓库
   1. 仓库分类
      1. 本地仓库：当前电脑上repository
      2. 远程仓库：
         1. 私服：搭建在局域网上为当前局域网内所有Maven工程服务；
         2. 中央仓库：架设在internet上为全世界所有的Maven工程服务；
         3. 中央仓库镜像：架设在各个大洲为中央仓库分流，减轻中央仓库的压力同时更快的响应用户请求的仓库；
      3. 仓库中保存的内容：Maven工程
         i. Maven自身所需要的插件
         ii. 第三方框架或工具包（第一方：jdk，第二方：我们自己）
         iii. 自己开发的Maven工程
9. 依赖
   1. Maven解析依赖信息时回去本地仓库中寻找被依赖的jar包
      1. 对用我们自己开发的Maven工程，使用install命令安装后可以进入仓库；
10. 依赖的范围
    
    
    1. compile
       1. 主程序编译是否需要：是
       2. 测试程序编译是否需要：是
       3. 是否参与打包：是
    2. test
       1. 主程序编译是否需要：否
       2. 测试程序编译是否需要：是
       3. 是否参与打包：否
    3. provide
       1. 主程序编译是否需要：是
       2. 测试程序编译是否需要：是
       3. 是否参与打包：否（像servlet-api由容器提供）
11. 生命周期
    1. 各个构件执行的顺序：顺序不能打乱，必须按照既定的正确顺序执行
    2. Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来执行的；
    3. maven有三套独立的生命周期
       1. clean lifecycle
          1. pre-clean:执行一些需要在clean之前完成的工作
          2. clean：移除上一次构建的所有文件
          3. post-clean：执行一些在clean之后立刻完成的工作
       2. default lifecycle
          1. validate
          2. generate-sources
          3. process-sources
          4. generate-resources
          5. process-resources ：复制并处理资源文件至目标（target）目录，准备打包（main/resources）
          6. compile：编译项目的源代码（main/java）
          7. process-classed
          8. generate-test-sources
          9. process-test-sources
          10. generate-test-resources
          11. process-test-resources:复制并处理测试资源文件（test/resources）
          12. test-compile：编译测试源代码（test/java）
          13. process-test-classes
          14. test：使用合适的单元测试框架运行测试，测试代码不会被打包
          15. prepare-package
          16. package：接受编译好的代码，打包成可发布的格式例如jar
          17. pre-integration-test
          18. integration-test
          19. post-integration-test
          20. verify
          21. install：将安装包至本地仓库，以让其他项目依赖
       3. site lifecycle
          1. pre-site:执行一些在site之前的工作
          2. site：生成项目的站点文档
          3. post-site：执行一些在site之后需要完成的工作，并且为部署做准备；
          4. site-deploy:将生成的站点文档部署到特定服务器上
    4. maven核心程序为了更好的实现自动化，按照下面描述的特点执行生命周期各个阶段：不论现在要执行生命周期中的哪一个阶段，都是从这个生命周期的最初位置开始执行
       1. 例如执行mvn compile命令maven会执行default lifecycle的1-6个步骤
       2. 执行mvn test会执行1-14个步骤
       3. 执行mvn package会执行1-16个步骤
    5. 插件跟目标
       1. 生命周期的各个阶段仅仅定义了要执行的任务是什么
       2. 各个阶段由插件的命令来执行
          
       3. 例如3中maven-compiler-plugin:3.1:compile表示使用maven-compiler-plugin:这个插件执行compile命令来执行生命周期的compile阶段
       4. maven-compiler-plugin:3.1:testCompile表示使用maven-compiler-plugin这个插件的testCompile命令来执行生命周期的test-compile阶段；
12. eclipse使用maven
    1. maven插件：eclipse内置
    2. maven插件的设置：
       1. installations：执行maven核心程序的位置，不建议使用自带maven程序，使用本地解压maven程序
       2. user settings：指定conf/setting.xml的位置，进而指定本地仓库位置
    3. 基本操作
       1. 创建maven版的java工程
       2. maven中jdk版本配置
          1. 全局配置
       3. 创建maven版的web程序
       4. 如何执行maven命令
13. 依赖【高级】
    1. 依赖的传递性
       
       1. 好处：可以传递的依赖不必每个工程中都重复引入，只需要在最底层的工程中依赖即可
       2. 非compile范围的依赖不能传递，因为不能传递，所以如果各个工程中都需要，需要重复引入；
    2. 依赖的排除
       1. 依赖排除的设置方式：在需要排除依赖的项目的pom文件中找到依赖项目，然后在依赖的项目工程中加入排除标识
       2. 
       3. 如2中MakeFriends项目会依赖HelloFriend项目，但是HelloFriend项目依赖spring-core，spring-core又会依赖common-logging，这样在MakeFriends中就会依赖两个，可以像2中增加commons-logging的排除
    3. 依赖的原则
       1. 作用：解决模块工程之间的jar包冲突；
       2. 原则1：如果依赖中有相同文件的不同版本，maven以最近的版本作为依赖；
       3. 原则2：如果依赖中有相同文件不同版本并且路径一样，则先声明的版本优先；
    4. 统一管理依赖的版本
       1. 原来依赖每个jar包版本都是4.0.0，如果需要统一升级为4.1.1，手动升级不可靠
       2. 建议配置方式：
          1. 使用properties标签内使用自定义标签统一声明版本号
          2. 在需要统一版本的位置使用${自定义标签名}引用声明版本号
             
             
          3. 自定义标签并不是只能做版本号声明，其他任意需要都可以使用，相当于一个全局变量，例如上图utf-8编码
14. 继承
    1. 现状
       1. Hello依赖的junit：4.0
       2. HelloFriend依赖的junit：4.0
       3. MakeFiend依赖的junit：4.9
    2. 需求：需要统一管理各个模块的junit版本，因为junit是test范围的依赖，由于不能传递，所以每个工程的版本都不一致；
    3. 解决思路：将junit依赖版本统一提取到父工程中，在子工程中声明junit依赖时不指定版本，以父工程中统一设定的为准，同时也便于修改；
    4. 操作步骤
       1. 创建一个Maven工程作为父工程，注意打包方式为pom
       2. 在子工程中声明对父工程的引用
       3. 将子工程的坐标中与父工程坐标中重复的内容删除，重复部分工具也会提示
       4. 在父工程中统一junit的依赖
       5. 在子工程中删除junit依赖的版本号部分
       6. 注意：配置继承之后，执行安装命令时，需要先安装父工程
15. 聚合
    1. 作用：一键安装各个模块功能
    2. 配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块
    3. 注意：这里配置的聚合跟配置的子工程路径顺序没关；例如一个Parent工程下有3个子工程a,b,c，但是b依赖a，c依赖b，这样安装的时候依旧会先安装Parent再a再b再c，并不会因为先配置c，在配置b而导致先安装c导致找不到b依赖报错；
16. 依赖信息可以上http://mvnrepository.com/上面去搜索

maven构建web工程

https://www.cnblogs.com/candle806/p/3439469.html

然后需要调整发布路径，主要是要让编译的class跟lib都发布的正确的目录下；
其中deployment这个里面是将项目的java编译成class并放到deploy path下面去部署；
java build path中output是自动编译输出的路径，可以是target中class路径也可以是跟deploy路径一致