git clone http://github.com/grails/grails-core.git
21 貢獻 Grails
版本 6.2.0
21 貢獻 Grails
Grails 是個擁有活躍社群的開放原始碼專案,我們高度依賴社群來協助改善 Grails。因此,人們可以透過各種方式來貢獻 Grails。其中一種方式是撰寫有用的外掛程式並公開提供。在本章中,我們將探討其他選項。
21.1 在 Github 的問題追蹤器中回報問題
Grails 使用 Github 來追蹤核心架構中的問題。類似地,它的文件也有獨立的追蹤器。如果您發現錯誤或希望看到加入特定功能,這些都是開始的地方。您需要建立一個(免費的)github 帳戶才能提交問題或在其中任一個追蹤器中針對現有的問題發表意見。
提交問題時,請提供盡可能多的資訊,如果是錯誤,請務必說明您正在使用的 Groovy、Grails 和各種外掛程式的版本。其他環境詳細資料,例如作業系統版本、JDK、Gradle 等,也應包含在內。此外,如果您上傳一個可重製的範例應用程式到 github 儲存庫並在問題中提供連結,問題更有可能獲得處理。
檢閱問題
github 中有一些舊問題,其中一些可能不再有效。核心團隊無法單獨追蹤這些問題,因此您可以做出的非常簡單的貢獻就是偶爾驗證一或兩個問題。
哪些問題需要驗證?前往問題追蹤器將顯示尚未解決的所有問題。
驗證完問題後,只要加上簡短的註解說明你的發現即可。務必提及你的環境詳細資料和 Grails 版本。
21.2 從原始碼建置並執行測試
如果你有興趣為 Grails 的任何部分提供修正和功能,你必須學習如何取得專案的原始碼、建置它並使用你自己的應用程式測試它。在開始之前,請確認你已具備
-
JDK (11 或更高版本)
-
git 客戶端
安裝完所有必要套件後,下一步是下載 Grails 原始碼,它由 "grails" GitHub 使用者 擁有的多個儲存庫在 GitHub 上代管。這只要複製你感興趣的儲存庫即可。例如,取得核心架構執行
這會在你的目前工作目錄中建立一個包含所有專案原始檔的「grails-core」目錄。下一步是從原始碼取得 Grails 安裝。
建立 Grails 安裝
如果你查看專案結構,你會發現它看起來不太像標準的 GRAILS_HOME
安裝。但將它變成標準安裝非常簡單。只要從專案的根目錄執行這個指令
./gradlew install
這會擷取 Grails 所需的所有標準相依性,然後建置一個 GRAILS_HOME
安裝。請注意,這個目標會略過大量的 Grails 測試類別,這可能會花費一些時間才能完成。
上述指令執行完畢後,只要將 GRAILS_HOME
環境變數設定為簽出目錄,並將「bin」目錄加入你的路徑。下次你輸入 grails
指令執行時,你就會使用你剛建置的版本。
如果你使用 SDKMAN,也可以透過下列方式使用這個本機安裝
sdk install grails dev /path/to/grails-core
你還需要將你的本機安裝發布到你的本機 maven。
./gradlew pTML
現在你會在你的本機中有一個開發版本,你可以用它來測試你的功能。
執行測試套件
你只要執行以下指令即可執行完整的測試套件
./gradlew test
這些將會花費一段時間(15-30 分鐘),因此考慮使用命令列執行個別測試。例如,若要執行測試規範 BinaryPluginSpec
,只要執行下列命令即可
./gradlew :grails-core:test --tests *.BinaryPluginSpec
請注意,您需要指定測試案例所在的子專案,因為頂層「測試」目標無法運作…。
在 IntelliJ IDEA 中開發
您需要執行下列 gradle 任務
./gradlew idea
然後開啟在 IDEA 中產生的專案檔案。很簡單!
在 STS / Eclipse 中開發
您需要執行下列 gradle 任務
./gradlew cleanEclipse eclipse
在將專案匯入 STS 之前,請執行下列動作
-
編輯 grails-scripts/.classpath 並移除行「<classpathentry kind="src" path="../scripts"/>」。
使用「匯入→一般→現有專案至工作區」將所有專案匯入 STS。將會出現一些建置錯誤。若要修正這些錯誤,請執行下列動作
-
將 $GRAILS_HOME/lib/org.springsource.springloaded/springloaded-core/jars 中的 springloaded-core JAR 檔案新增至 grails-core 的類別路徑。
-
從 grails-plugin-testing 的來源路徑中移除「src/test/groovy」GRECLIPSE-1067
-
將 $GRAILS_HOME/lib/javax.servlet.jsp/jsp-api/jars 中的 jsp-api JAR 檔案新增至 grails-web 的類別路徑
-
修正 grails-scripts 的來源路徑。新增連結來源資料夾,連結至「../scripts」。如果您在 grails-scripts 中取得建置錯誤,請在該目錄中執行「../gradlew cleanEclipse eclipse」並再次編輯 .classpath 檔案(移除行「<classpathentry kind="src" path="../scripts"/>」)。如果您無法新增連結資料夾,請移除 grails-scripts 下可能存在的空「scripts」目錄。
-
對整個工作區執行乾淨建置。
-
若要使用 Eclipse GIT scm 團隊提供者:在導覽中選取所有專案(「伺服器」除外),然後按一下滑鼠右鍵 → 團隊 → 分享專案(不是「分享專案」)。選擇「Git」。然後勾選「使用或在專案父資料夾中建立存放庫」,然後按一下「完成」。
-
從 郵件清單執行緒 取得建議的程式碼樣式設定(最終樣式尚未決定,目前為 profile.xml)。在「視窗→偏好設定→Java→程式碼樣式→格式化程式→匯入」中將程式碼樣式 xml 檔案匯入 STS。Grails 程式碼使用空白而非標籤鍵來縮排。
偵錯 Grails 或 Grails 應用程式
若要啟用偵錯,請執行
./gradlew bootRun --debug-jvm
預設情況下,Grails 會分叉一個 JVM 來執行應用程式。-debug-jvm
參數會導致偵錯器與分叉的 JVM 關聯。
21.3 將修正提交至 Grails Core
如果您想要將修正提交至專案,您只需要在 GitHub 上分叉存放庫,而不是直接複製。然後您將會將變更提交至您的分叉,並傳送拉取要求,供核心團隊成員審查。
分叉和拉取要求
以下是確保您的拉取請求能快速處理並提供我們所需資訊的一些準則。它們也會讓您的生活更輕鬆!
確保您的分岔已更新
對過時的來源進行變更並非好主意。其他人可能已經進行變更。
git pull upstream master
為您的變更建立一個本機分岔
如果您建立一個本機分岔來進行變更,您的生活會大大簡化。例如,一旦您分岔一個儲存庫並在本地複製分岔,執行
git checkout -b issue_123
這將建立一個新的本機分岔,稱為「issue_123」,基於「master」分岔。當然,您可以將分岔命名為您喜歡的任何名稱,但一個好主意是參考與變更相關的 GitHub 問題編號。每個拉取請求都應該有自己的分岔。
為非平凡的變更建立 GitHub 問題
對於任何非平凡的變更,如果尚未存在,請在 GitHub 上提出問題。這有助於我們追蹤哪些變更會進入每個新版本的 Grails。
在提交訊息中包含 GitHub 問題 ID
這可能看起來並不特別重要,但在提交訊息中有一個 GitHub 問題 ID 表示我們可以在稍後找出進行變更的原因。在與該問題相關的任何和所有提交中包含 ID。如果提交與問題無關,則無需包含問題 ID。
再次確保您的分岔已更新並重新設定基底
由於核心開發人員必須將您的提交合併到主儲存庫中,因此在您發送拉取請求之前,如果您的 GitHub 分岔是最新的,這將使生活更輕鬆。
假設您已將主儲存庫設定為稱為「upstream」的遠端,並且您想要提交拉取請求。此外,您所有的變更目前都在本機「issue_123」分岔上,但不在「master」上。第一步包括從您上次擷取和合併以來已新增到主儲存庫的任何變更
git checkout master
git pull upstream master
這應該可以順利完成,不會有任何問題或衝突。接下來,針對現在最新的 master 重新設定您本機分岔的基底
git checkout issue_123
git rebase master
這樣做會重新排列提交,讓您的所有變更都出現在 master 中最近的一個變更之後。想想將一些卡片新增到牌組頂端,而不是將它們洗入牌組中。
將您的分支推送到 GitHub 並發送 Pull Request
最後,您必須將變更推送到 GitHub 上的分支,否則核心開發人員將無法接收它們
git push origin issue_123
您不應將分支合併到分支的 master。如果未接受 Pull Request,則您的 master 將永遠與上游不同步。 |
您現在可以從 GitHub 使用者介面發送 pull request。
說明您的 pull request 的用途
pull request 可以包含任意數量的提交,且可能與任意數量的問題相關。在 pull request 訊息中,請指定請求相關的所有問題的 ID。此外,請簡要說明您已完成的工作,例如:「我重構了資料繫結器,並新增了對自訂數字編輯器的支援。修正 #xxxx」。
21.4 提交修補程式至 Grails 文件
貢獻簡單變更
使用者指南使用 Asciidoctor 撰寫。貢獻修正最簡單的方式,就是按一下文件各章節右側的「改善此文件」連結。
這會連結到 Github 編輯畫面,您可以在其中進行變更、預覽變更並建立 pull request。
建立指南
如果您想要進行重大變更,例如變更目錄結構等,我們建議您建立使用者指南。為此,只需從 github 簽出原始碼
$ git clone https://github.com/grails/grails-doc/
$ cd grails-doc
原始碼檔案可以在 src/en/guide
目錄中找到。目錄 (TOC) 定義在 src/en/guide/toc.yml
檔案中。
每個 YAML 鍵都指向 Asciidoc 範本。例如,考慮下列 YAML
introduction:
title: Introduction
whatsNew:
title: What's new in Grails 3.2?
...
introduction
鍵指向 src/en/guide/introduction.adoc
。title
鍵定義 TOC 中顯示的標題。由於 whatsNew
鍵巢狀在 introduction
鍵下方,因此它指向 src/en/guide/introduction/whatsNew.adoc
,而後者巢狀在稱為 introduction
的目錄中。
基本上,您可以使用 toc.yml
檔案和目錄結構來調整使用者指南的結構。
若要產生文件,請執行 publishGuide
工作
$ ./gradlew publishGuide -x apiDocs
在以上的範例中,我們跳過 apiDocs 任務以加快指南的建置,否則所有 Groovydoc 文件也會被建置!
|
一旦指南建置完成,只要在瀏覽器中開啟 build/docs/index.html
檔案就能檢閱變更。