2.1 问题的提出

最初接触ODL项目时，笔者曾被它的庞大和繁杂吓到了。有个比喻说，“ODL是一只会跳舞的大象”。一方面是因为ODL包含了大量的功能特性；另一方面是因为最初的ODL版本中的各子项目是由参与创立ODL的各公司独立开发贡献到社区的，根本没有统一的架构设计，也很难做到统一的项目管理，而且一些子项目本身也没有进行很好的设计。比如，ODL最初的版本中，Cisco主导贡献的ODL最核心的框架部分：controller项目里，就有如下典型问题：

❏ 该项目没有统一规划parent，比如mdsal就定义了两个parent：sal-parent和comp-atibility parent，版本号都是1.1-SNAPSHOT，但这两个parent都继承自另一个版本号为1.4.2-SNAPSHOT的parent pom。

❏ 很多模块的版本号缺乏规划，没有从其直接的parent继承，使其定义混乱。比如UserManager的pom中，其parent的版本定义为1.4.2-SNAPSHOT，该模块的版本号却被定义成0.4.2-SNAPSHOT。

❏ 依赖不是从parent pom继承，而是直接罗列在当前的pom中。

其他子项目也有类似的问题主要包括以下几个方面，1）整个ODL项目缺乏统一规划的parent pom，各模块继承层次不清晰，构建依赖混乱，版本编译构建和集成的工作经常出现各种问题，无法稳定；2）各项目和模块的版本号缺乏统一规划，导致ODL的子项目的几百个模块都有不同的版本号，维护与演进非常麻烦和困难；3）发布版本过程中，需要花费大量的人力修复出错的pom文件。

这些问题不仅给项目自身的维护和开发带来了困难，同时给学习和使用ODL的用户也带来了困扰。用户很难梳理清楚各项目和模块的不同版本，特别是ODL最初的几个发布版本。因此，用户在加载和运行初始发布的ODL版本的过程中，要面对非常多的干扰。