聚合
当有多个项目需要打包进仓库时（其实就是当前项目依赖很多项目，所以当前项目执行前，需要把这些依赖的项目全部install进本地仓库），一个一个执行install太麻烦，maven有一个方法可以多个项目一起install到本地仓库。就是聚合。
例如：
有A，B，C三个项目需要install，新建一个用来聚合的项目aggreation（要保证aggreation和那三个项目是同一个GroupID。这句话的意思是如果这多个项目不是同一个GroupID，就不能用聚合了？）。
然后修改aggreation项目的pom文件：
1. 打包方式由jar修改为pom：
<packaging>pom</packaging>
2. 添加<modules> </modules>标签
<modules> <module>../A</module> <module>../B</module> <module>../C</module> </modules>
ps:
这个 ../ 指什么？指maven的根目录？
应该是当前项目pom的上一级目录，其实就是所有项目存放的那个文件夹（也就是maven项目的根目录），然后就通过/A /B /C 代表当前项目和这三个项目的相对路径
然后对aggreation项目执行install命令，则项目A，B，C就都打包到本地仓库了。
执行aggreation项目如test，A，B，C项目也都会执行。即便ABC之间有依赖关系，如B依赖A，不用把A先执行安装，B同样会被执行。这是聚合的优势。
配置完聚合项目，只需要操作聚合项目，里面的项目都会被操作。不管这些项目之间是否有依赖。
继承
当很多项目都有相同的依赖时，每个项目的pom都要修改，很麻烦。可以像继承那样处理，把这个依赖抽象成一个父类。
同上面聚合一样，新建一个项目parent专门用来处理 继承。
把共有的依赖放到这个新建项目parent的pom里的<dependencyManagement>（这部分是不在项目里运行的）里面。
<dependencyManagement> <dependencies> <dependency> 共同依赖的jar的坐标 </dependency> </dependencies> </dependencyManagement>
然后修改打包方式为pom：
<packaging>pom</packaging>
也可以在新建项目时选择pom打包
然后还需要去其他项目的pom里修改，添加<parent>标签继承上面那个专门的项目，既然每一个项目还是需要修改pom，还不如直接写依赖，何必搞这个继承。感觉没用。并没有省事，也可能是那个教程里讲的不详细
应该说，比较简单是是如果依赖很多，每一个子项目的pom都要写很多依赖时，这时只写一个<parent>标签，比较简单。而且格式上更好？
类似代码开头写常量变量那样，需要修改变量值，只在开头修改一次就可以，如果需要修改依赖，只需要去父工程里修改？
其实就是把公用的东西提取到一块，结构更清晰，修改更方便。
ps:
看到另一个教程里讲，继承还有另一个用法：
A依赖B，B依赖C，B对C的依赖是compile，则A 默认是传递依赖C。如果不想看B和C是不是compile，那只要A是继承B，就自然接受B的所有依赖关系。
注意父工程B的打包方式要是pom。（Java工程是jar，web项目是war）
继承的写法：
1. 建立父工程
父工程只用来写一些依赖关系的，结构很简单，注意打包方式和，依赖的格式。
2. 子项目
（1）子项目的pom里添加<parent>标签，写入父工程坐标：
（2）然后还要写入从当前项目pom到父工程的pom文件地址的相对路径：
..是从当前项目的pom向上一级，退到存放所有项目的文件夹，然后B是父工程的文件夹，然后是父工程的pom
这是相对路径，这样写完，打包安装部署时，可不一定连着父工程一块打包啊？还是说，子项目编译打包后的文件，已经包含从父工程里继承过来的东西了？部署后这个相对路径已经用不到了？
我记得哪里看到说项目里的路径都要写相对路径？
（3）在子类中要声明引用父类中的那些依赖jar，因为如果父类的依赖jar太多，子类未必要全部引用。
声明方式：
在子类的依赖标签中写要使用父类依赖中的哪些jar的信息：
使用父类依赖中的junit
只是相对于直接写依赖，写的信息只有g，a，没有版本和范围了（也可以写）。但是如果ga两个都写了，干脆直接写成依赖不好了？还搞一个父类继承这么麻烦？只能说，最大的好处就是版本的管理了，只需要去父类里修改，统一管理依赖的版本。