引言
此文不是純粹介紹maven概念，而是介紹一個具體的maven項目文件規划
這個規划可能適合於研發比較復雜的業務，這些業務有分布式和服務化的需要。
這個規划能夠解決因為分布式和服務化要求而引起的項目繁多，項目混亂的問題。
與此同時這個規划也可以解決了在項目研發中出現的重復“輪子”的問題。這些“輪子”主要來源於兩類：
- 代碼的重復“輪子”，所以要抽取項目，導致項目數量進一步增多。
- 人工構建項目的重復“輪子”，構建的關系越來越復雜，錯誤率也越來越高，所以要通過基於配置和約定的方法來實現自動化構建。
其他的不多贅述，直接上干貨。
實際的規划圖
所有parent的公用職責
- 構建它下面聚合的所有項目。約定是只聚合它子目錄的項目，不能跨目錄去聚合
- 管理它聚合的項目的通用特性，即存在繼承關系。這些通用特性，是從它聚合的項目本身抽取的職責而來。約定這個繼承和聚合使用同一個項目。
- 統一管理它聚合的項目中使用依賴其他項目或者jar的版本。聚合的項目只允許依賴它下層的項目。具體分層，看下文的分層依賴關系
we-parent的職責
職責：一鍵構建所有需要發布的項目。
通用特性：
- 所有項目初始時就帶有這些jar包的依賴，例如：testng(單元測試相關),h2(單元測試相關),easymock(單元測試相關),lombok（根據注釋自動生成setter和getter）
- 所有項目的額外特性，例如：單元測試插件
- 項目發布管理，例如：私一的maven私服配置
we-core-parent的職責
職責：它所聚合的的項目與業務沒有關聯的，只提供基礎能力。簡稱：core項目。例如：數據庫持久能力，redis緩存能力,http封裝能力，通用工具能力等。
通用特性：
- Javadoc插件，用於生成javadoc
we-base-parent的職責
職責：它所聚合的的項目有且只能代表一個真實存在而且能獨立存在的核心實體對應的業務，簡稱：base項目。
概念解釋：
- 真實存在：即可以用一個具體的客觀物體承載的。比如：用戶，課程，試題
- 獨立存在：不依賴於其他的任何業務，放在哪里都可以獨自呈現。比如：試題放在哪里都可以顯示，課程放在任何地方也可以呈現。
- 核心實體：一個業務服務其實通過一個實體就可以來實現了，頂多是字段屬性多一些、實現復雜一些。為了更好的實現，我們可以會把這個實體拆分成很多。但是不管拆分多少個實體，總會有一個是最為重要的，其他的實體如果沒有這個實體就沒有任何意義。比如試題抽象成試題實體和答案實體。如果沒有試題的存在，答案是沒有存在的意義的。所以試題就是核心實體。
通用特性：暫無
we-business-parent的職責
職責：它所聚合的的項目必須是一個提供“共享”業務流程，簡稱：business項目。在這個流程過程中有可能需要引用base服務。它本身沒有一個真實存在而且能獨立存在的核心實體
概念解釋：
共享：在產品規划上，該服務可能會被多個產品使用，即為共享。
通用特性：
- 統一引用數據庫持久能力，即數據庫實現項目。
we-web-parent的職責
職責：它所聚合的的項目可以通過互聯網向用戶提供服務，在產品規划上它自己獨有的不被共享的業務，簡稱：web項目。
通用特性：
- 統一引用http解析能力。對http的解析及渲染。
- 監控相關
分層依賴關系
除了we-parent，每一個parent對應的職責就是一個項目分層。這些項目分層的從上到下的關系如下圖。
如何使用
假設：現在來一個產品稿（prd，原型或者定稿需求）
使用步驟如下：
- 分析一下，這個產品是否要對用戶獨立提供服務，不受其他的產品影響。如果要，則新建web項目。
- 分析一下，這個產品有沒有哪些業務是准備被其他產品使用的，即在其他產品的界面有沒有體現本產品。
- 如果有，分析一下這些公用的業務，有沒有包含一個流程性，即它的業務在組合其他已有base項目。如果有，新建一個business項目
- 分析一下，這個產品有沒有可以獨立存在，不依賴於任何其他服務的業務。如果有，新建一個base項目。
- 當實現這些編碼時，如果有遇到一些與業務無關的，只提供能力的，則新建一個core項目。
總結來說：就是分析的時候根據分層，從上到下。把每一層的職責分析一下，如果有則新建一個。每一個項目，都必須建在對應的parent之下。