scope
1.compile：默认值 他表示被依赖项目需要参与当前项目的编译，还有后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去
2.test：依赖项目仅仅参与测试相关的工作，包括测试代码的编译和执行，不会被打包，例如：junit
3.runtime：表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与compile相比，跳过了编译而已。例如JDBC驱动，适用运行和测试阶段
4.provided：打包的时候可以不用包进去，别的设施会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是打包阶段做了exclude操作
5.system：从参与度来说，和provided相同，不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径
filtering
主要用来替换项目中的资源文件（*.xml、*.properties）当中的${...}，比如${db.url}，那么如果配置了db.url=aaa的话，在项目编译的时候，就会自动的把${db.url}替换为aaa
profile
允许在项目文件（pom.xml）里面定义若干个profile段，然后在编译时选择其中的一个用于覆盖项目文件原先的定义
parent&dependency&dependencyManagement
下面做一个测试，A项目作为一个公共项目，被B项目和C项目所依赖，B以parent的方式，C以dependency的形式。在A项目创建一个类，添加一个方法，然后分别在项目B、C中写测试方法，调用A项目类中的方法。
-----------|项目A中引入了一个commons-lang3的方法，开发中常用到里面的StringUtils判断字符串的方法，以此为其中一个测试点
-----------|最后可以发现在B中，通过<parent>引用的项目A，可以使用A项目中<dependency>中依赖的StringUtils的方法，但是不能调用A项目中自己定义的类和方法，C项目中通过<dependency>依赖的A,两者却都可以调用。
1.在同一个pom文件下，如果<dependencies>和<dependencyManagement>中都对该jar做了依赖，以<dependencies>的为准，优先级高于<dependencyManagement>。若前者没有对其依赖，而后者对其有依赖，则以后者为准。<dependencyManagement>里只是声明依赖，并不实现引入.
2.在不同的pom文件中，存在父子相互依赖关系的，父项目的pom中<dependencyManagement>中对该jar做了依赖，而子项目中<dependencies>又依赖了该jar，如果子项目中没有指定<version>和<scope>，则继承父项目中该jar的<version>和<scope>。如果子项目中指定了<version>和<scope>，以子项目的为准。
3.pom文件中，jar的版本判断有2种途径
-----------|1，第一种就是最常见的depenency中写version
-----------|2，如果不是第一种，那么maven会到自己的pom文件或者父pom中找有没有对该artifactid和groupid进行版本申明的，如果有就拿那个版本号，没有就报错
-----------|3，如果两种都写错，那么第一种覆盖第二种