使用Gradle構建多模組SpringBoot專案

本專案使用Gradle構建SpringBoot專案，將不同的業務進行不同的模組劃分(不做微服務與分散式架構);
- 編輯器：Intellij IDEA
- 構建工具：Gradle3.5
- SpringBoot版本：1.5.8
- 版本管理：GitHub
- 個人GitHub地址：https://github.com/fanlongfei0212
- 專案Clone地址：https://github.com/fanlongfei0212/demo.git

---

專案構建

• 首先建立一個專案，我們使用IDEA構建一個Gradle Java專案，作為專案的最外層，只做為整個專案的容器，所以最外層專案只構建為普通的Gradle Java專案即可；
  

• 填寫GroupId與ArtifactId；
一般正式專案的GroupId為com.*開頭，因為此專案為個人專案，所以使用pers.*開頭，具體規則大家可以參考命名規範，ArtifactId為專案名稱；
  

• 點選Next，進入Gradle配置頁面；
選擇Use local gradle distribution，配置自己本地的Gradle地址；
點選Next，Project name自動為ArtifactId，Project location為IDEA預設（或你上一次設定）的WorkSpace，分配WorkSpace；
點選Finish，完成Gradle Java專案的建立
  
  
  
  

• 專案已經建立好了，我們開始建立各個模組，在不同專案中，模組劃分的方式也會不同，具體的模組劃分可以按照實際專案的需求進行劃分；
在此Demo中，將模組劃分為：
全域性工具模組：tools-common（專案中所有模組的全域性工具類，基礎模組依賴此模組，下面會講到基礎模組）
檢視模組：views-demo（專案中的檢視模組，比如：APP所需介面、管理後臺所需介面，需要進行資料展示的模組，都會被此模組依賴）
業務模組：service-demo1（將專案中不同業務進行模組化的區分，一般在專案中，業務模組是最多的，而且在某個業務模組中需要其他業務模組作為支撐的可以進行Gradle依賴，但要避免迴圈依賴）
基礎模組：basic-base（專案中所有業務模組的支撐，此模組中提供的基礎服務是所有業務模組中都要用到的，所有業務模組都要依賴此模組，此模組依賴全域性工具模組，這樣，所有的模組都相當於間接依賴了全域性工具模組）

• 1.建立全域性工具模組：
右鍵專案，點選 New -> Moduel，選擇Spring Initializr，點選Next
  
  

• 2.配置模組：
設定Group，最好與專案的GroupId保持一致；
設定Artifact，模組名稱；
設定Type，我們使用的是Gradle進行專案構建，所以選擇Gradle Project；
點選Next
  

• 3.配置SpringBoot，也可以不再此處進行配置，直接在模組中的Gradle檔案中新增依賴也可以起到同樣的作用，最後在同一說明處會有講解，我們先在此處進行配置：
Core：DevTools（專案中一些開發工具，比如熱部署等）、Lombok（消除冗長的Java程式碼，比如get、set、建構函式等，可以直接使用註解）；
Web：Web（Spring的一些Web配置）；
SQL：JPA、MySQL（我使用的是MySQL，大家可以根據實際情況進行資料庫選擇）；
Ops：Actuator（專案監控）；
點選Next，會發現Module name為Artifact，和建立專案時一樣，點選Finish

• 注：大家可以根據自己的專案情況進行SpringBoot的配置，配置好之後再窗體中的右邊Selected Dependencies可以檢視已選的SpringBoot配置
  
  

• 4.設定Use local gradle distribution配置Gradle，選擇本地的Gradle地址，點選OK，完成建立模組；
  
  

• 5.進行Gradle配置，大家可以看到，右邊的的Gradle檢視也多了一個tools-common的模組，但是有一個問題，他和專案模組是平級的，在Gradle專案中，根專案應該在最外層，其他模組都應包含在根專案中，我們設定最外層settings.gradle檔案，把模組include到最外層的專案中，然後重新整理Gradle

大家會發現有的時候可能會出現兩個根，其實只有一個，在Mac下初步判定是IDEA的相容或顯示問題，大家刪除最下面的那個就可以了（選中第二個根，點選Gradle檢視上的‘-’即可），正常刪除的時候Gradle會出現刪除提示，但是刪除錯誤顯示的時候你會發現，沒有提示，這是正常的，因為具有真實存在的根
  
  

• 6.所有的模組進行統一步驟的建立
  

• 7.進行所有模組的Gradle配置，配置各個模組之間的依賴，將根Gradle的sourceCompatibility設定為1.8（我的JDK使用的是1.8），然後重新整理Gradle，刪除多餘的根（如果出現的話）
  
  
  
  

• 8.整理專案中檔案
將無用的檔案進行刪除；
刪除所有模組中的gradlew檔案
刪除所有模組中的gradlew.bat檔案
刪除所有模組中的gradle資料夾
刪除所有模組中的.gitignore檔案，在專案最外層配置.gitignore檔案，做為整個專案的git提交忽略配置
  
  

• 9.配置SpringBoot的application.properties檔案：
將所有模組application.properties進行重新命名修改，在多模組專案中，檢視模組作為最外層的執行模組，也就是說views-demo這個模組最後會被build成jar包（或者war包）執行在伺服器上，作為最外層容器，當容器進行載入的時候會載入所有的application.properties檔案，因為每個模組都可能會有針對本模組配置，我們要保證所有的模組配置都要被SpringBoot載入，瞭解過SpringBoot的童鞋們都知道，SpringBoot的大部分配置項都可以在application.properties中進行直接配置，但是在views-demo載入所有模組的application.properties檔案的時候，由於名稱一致，這時就會出現覆蓋載入的問題，導致一部分的配置無法載入到，這時，就需要我們修改各個模組的application.properties檔案的名稱，保證所有模組application.properties中的配置項都可以被SpringBoot載入；
這樣確實可以解決覆蓋載入的問題，但是會衍生出一個新的問題，就是SpringBoot預設只會去載入名稱為application.properties中的配置項，為了解決這個問題，我們可以使用@Profile註解去配置SpringBoot的載入環境，在每個模組中都去做一個配置Bean，然後將所有修改過的資原始檔都配置到views-demo中的application.properties檔案中，使我們修改過名稱的application.properties檔案都被SpringBoot載入；
  basic-base模組
  
  
  service-demo1模組
  
  
  tools-common模組
  
  
  views-demo模組
  
  
  在views-demo模組中統一載入修改過的資原始檔
  
  

• 10.配置資料來源：
在所有配置都完成之後，我們似乎可以執行專案了，但是其實還是最後一個地方需要進行配置，那就是配置資料來源，不知道大家是否再記得，我們在配置SpringBoot的時候勾選了SQL塊中的Jpa和MySQL，如果不進行資料來源配置的話執行就會丟擲：Cannot determine embedded database driver class for database type NONE異常；

配置資料來源以及其他基礎配置，配置完成之後我們執行views-demo專案，並進行build（打包：jar或war，我只做生成jar檔案測試，平時伺服器上也是部署jar檔案）測試，如果專案無法build的話，說明程式還是存在問題的；

啟動測試



build測試是否可以生成jar檔案，在build的時候可能會出現一個異常，是因為各個模組中存在與main同級的test的問題，將test刪除即可


刪除各個模組中的test後進行build，build成功後，在views-demo模組的build->libs中會生成views-demo-0.0.1-SNAPSHOT.jar，我們將jar包直接在liunx環境下進行啟動，看是否可以成功執行；


執行WorkSpace中的views-demo-0.0.1-SNAPSHOT.jar
  
  
  

出現問題以及其他說明

專案結構：
basic-base（基礎模組）：所有業務模組都需要用到的業務邏輯service；
tools-common（全域性工具模組）：所有模組需要的工具類，說到這，大家可能會有一個疑問，在上面的截圖中，大家會發現在每個模組的入口處有一個包，包結構為：
pers.fly.common
- - - - - - - -|config
- - - - - - - -|tools
在專案的結構中已經存在了一個common的工具模組，為什麼每個包下還會存在tools這種工具包。又一次，我的一個朋友曾經和我說，在專案中你會發現有的工具類只有本專案才會用到，那為什麼不在每個模組中建立一個只放置本模組的工具類的包呢，然後把所有模組都會用到的工具類放到全域性公共區域；這樣的規劃的話顯然是更合理的；
service-demo1（業務模組）：此專案只為演示使用Gradle構建SpringBoot多模組專案，在實際專案開發中，會存在多個業務模組，所有業務模組都已service-開頭，所以此專案中只有一個業務模組，並且以demo1命名，在實際專案中最好不要出現數字，相關規則大家檢視Java的命名規範，結合實際情況；
views-demo（檢視模組）：存放對外提供的介面，Controller介面的放置位置，針對具體的業務場景或者不同的終端；比如，這個檢視模組只放置**的業務模組的介面，或者只放置對APP端提供的介面，或者只放置對PC端提供的介面，或者只放置對微信端的介面等等；在實際專案中，檢視層模組也可能存在多個；

@Profile的使用：
學習過SpringBoot的童鞋肯定知道@Profile，在這我要說明一點，我在學習SpringBoot中的時候，網上的一些資料和書本中都有講解過@Profile的作用，大部分的資料和書籍說@Profile是為了方便區分專案環境而進行的配置，在實際專案中，專案環境會分為開發環境、測試環境、生產環境（標準的專案環境應該還會存在預釋出環境），在這些環境中某些配置是不一樣的，比如資料庫的連結地址，連線池的配置或者等等其他的一些配置，然後使用@Profile是為了區分這些環境去配置一些不同的application.properties資原始檔配置；我個人認為@Profile既然可以去做到將不同的環境區分，並且可以指定某個或同時指定多個環境的配置，那為什麼只能作為專案環境的區分，如果要區分專案環境的話，有很多方法，比如在使用Git作為版本管理的時候，我們可以使用分支來作為區分，而且SpringBoot的配置檔案的載入順序是從與專案平級的配置檔案開始載入，然後在載入專案中的配置檔案，在載入模組中的配置檔案，它的優先順序是從外到內的（配置檔案中，如果存在Java類配置的話Java類的優先順序是高於application.properties的優先順序的），在上不同的環境時我們可以在伺服器上和jar包放置不同環境的application.properties檔案也可以做到專案環境的區分；我還查閱了官方文件，官方文件是這樣描述的：

大概意思就是可以使用命名約定（application-{**}.properties）去載入、定義應用程式，官方文件確實也使用了development、production去做一些例子，但個人認為@Profile不應該僅僅只是為了區分專案環境，最重要的是它可以靈活的去定義一些配置；

配置完資料來源之後還是會丟擲Cannot determine embedded database driver class for database type NONE異常問題：
在使用Gradle構建SpringBoot專案的時候，出現過這樣的問題，在載入多個模組的時候，明明配置了好了資料來源也指定了資料庫的型別，但還是會丟擲，並且在Run/Debug Configurations中確實是以Application方式啟動並且也指定了Working directory的專案地址，但是還是不行，後來發現將.idea刪除，重新使專案配置載入，然後這個問題就解決了，具體為什麼我也不是特別明白，可能是idea的快取？或者是Mac下idea的不相容？我用的是Mac，不知道Windows下有沒有同樣的問題；

關於build失敗的問題：
在進行build的時候會出現一個異常，在上面的截圖中build測試的時候也說了這個問題，丟擲的異常資訊顯示是關於測試檔案的載入問題，具體為什麼會出現這樣的問題，詳細原因目前為止還沒有找到，當前的解決方法就是刪除test模組，刪除之後確實可以進行build，但是終歸不是長久之計，一個完整的專案怎麼能沒有測試呢，這個問題接下來還是要處理一下；

說明：以上均為個人見解，如果有不對的地方或者各位童鞋有不同的見解以及意見，歡迎留言指正~~