《Maven实战》 阅读笔记

无Maven不项目，这是我的口号，但是一直没有系统的去看书，前段时间把《Maven实战》过了一遍做了些笔记，方便后面查阅

---

每个项目都有自己的坐标

• groupId
• artifactId
• version
• packaging
• classifier
  

• install 安装在本地
• deploy 打包发布到远端

依赖范围

范围类型有: 编译、测试、运行 三种classpath

• compile，默认值，对编译、测试、运行三种classpath都有效；
• test: 测试依赖范围，只对测试classpath有效，在编译主代码或者裕兴项目的使用是则无法使用此类依赖。
• provided: 已提供依赖范围 只在编译和测试classpath有效，运行时无效。
• runtime: 运行时依赖范围，对测试和运行classpath有效，编译无效；
• system: 系统依赖范围,
  

(如第三方给的jar包，且仓库中心又没有，可以使用system范围，如)

<dependency>
    <groupId>org.jsoup</groupId>
    <artifactId>jsoup</artifactId>
    <version>1.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/src/lib/jsoup-proxy.jar</systemPath>
</dependency>

• import（Maven 2.0.0及以上）：导入依赖范围。不会对三种classpath产生实际的影响；(不够严谨，类似complie还是什么？)
  

传递性依赖

依赖调解

两个依赖关系
A->B->C->X(1.0)
A->D->X(2.0)
两个依赖都间接来到X，
maven引用原则(依赖调解(Dependency Mediation))

• 第一原则：路径最紧者优先 即 x(2.0)会被使用

A->B->Y(1,0)
A->C->Y(2,0)

• 第二原则： 在满足第一原则的前提下第一声明者优先(就近原则) 即 Y(2,0)会被使用

可选依赖

仓库的布局

生命周期

• clean:清理项目
  
• default: 构建项目
  
• site: 建立项目站点
  

继承

正确的设置relativePath很重要

可继承的pom元素

依赖范围 import的用法

插件跟依赖一样可以使用*Management来管理

反应堆

对于裁剪功能，需要用的时候可以查阅文档

测试

跳过测试
mvn package -DskipsTests

注意：上述几种命令行动态指定测试类的方法都应该只是临时使用，如果长时间只运行项目的某几个测试，那么测试就会慢慢失去其本来的意义。

加入测试

也可以使用excludes排除一些测试

WEB应用

版本号定义约定

Maven属性

内置属性:

${basedir} 标识项目根目录即包含pom.xml 文件的目录；
${version}标识项目版本；

POM属性:

• ${project.artifactId} 对应了元素的值
• ${project.build.sourceDirectory} 项目的主源码目录 默认src/main/java/
• ${project.build.testSourceDirectory} 项目的测试源码目录，默认为src/test/java
• ${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}

自定义属性

可以通过<properties><xxx>val</xxx></properties>

Setting属性

Java属性变量

环境变量属性

最佳实践

• artifactId 使用实际项目名称作为artifactId的前缀
• 优化依赖： 使用 dependency:list 或 dependency:tree 来查看依赖关系
• mvn clean install 在执行真正的项目构建之前清理项目是一个很好的实践