day29

一、今天的学习内容
maven项目的目录结构：

maven项目名
----src----main----java----java项目
----test----java----测试项目
----pom.xml(maven 项目的核心）

细说pom.xml:

以上是最基本的pom文档

往文档中添加依赖：
添加Junit为例

细说依赖的范围：
就是用来控制依赖与这三种classpath（编译classpath，测试classpath，运行classpath）的关系

compile：编译依赖范围，对于编译、运行、测试三种classpath都有效

test：测试依赖范围，只对测试classpath有效。上面就是test，也就是说测试代码中的import Junit代码是没有问题的，而在主代码中使用import Junit是会造成编译错误。

provided：已提供依赖范围，对于编译测试的class path有效
runtime：运行时依赖范围。对于测试和运行的classpath

system:系统依赖范围。和provided范围完全一样，但是使用时必须通过systemPath元素显式的指定依赖文件的路径。

还有其他的依赖配置：
type：依赖的类型，对应于项目坐标定义的packaging

optional：标记依赖是否可选
excusions：用来排除出传递性依赖

传递性依赖：

在以上这种情况，如果是手工的话。一种办法是下载依赖b所有的包以及所有它依赖的包，但是这样就太不必要了。另一种方法是：只下载依赖a的包，在使用的时候，再通过出错信息，以及相关文档，加入需要的依赖，不过太麻烦了吧

这样maven就提供了传递性依赖。

传递性依赖范围

但这样就永远不会出现问题吗？？
如果是下面的情况怎么办？

maven第一原则：路径近优先
第二原则：在长度相同，第一声明者有限。（在POM中依赖声明的顺序决定了谁会被解析使用。）

但是这就完美了吗？？too young too naive

使用<optional>元素表示mysql-connector.java和postsql这两个依赖是可选依赖，他们只会对当前项目b产生影响，当其他项目依赖于b的时候，这两个依赖不会被传递。

但有时我们又不想传递依赖，怎么办呢？用<exclusions>元素！这叫排除依赖。

人类越来越会偷懒，想想我们在java中，如果经常出现一个常量的时候，我们应该加上final关键字，如 pubic final double PI;在maven中同样，如Spring Framework来说，定义了这样一个版本之后，在升级Spring之后就只需要修改一处。很方便。

二、明天要学习的内容
务必完成maven！！！然后进攻下一本书。

三、问题
通过查本地仓库可以看到junit里的这个文件，其实就相当于pom，所以每个依赖其实都算一个maven项目，而自己的maven项目也可以install自己的本地仓库中？

文件内容

四、收获

还是得买书看啊，真的真的，，，，很系统 ，不然脑袋里的东西永远成不了体系，我可能有强迫症，，，