Versions Compared

Old Version 6

changes.mady.by.user T.C. Chou

Saved on

compared with

New Version 7

changes.mady.by.user T.C. Chou

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note
title要點
  1. 不要自行做出大型的成果(程式碼, ... 等等)之後, 才貢獻給 OFBiz。
  2. 如果有一個大型的成果要貢獻, 我們可以和你一起進行, 但和一般貢獻有差異, 必須進行不同的審核和法律撿審程序, 細節在後面網址有說明 http://incubator.apache.org/ip-clearance/index.html。
  3. 當一個方法被停用(deprecated), 需解釋該用那個方法, 及什麼被改變了。
  4. 藉由貢獻方式來替代開發。意思是如同一般的開發, 但和 OFBiz 社群透過論壇, 以及持續貢獻修補檔案保持溝通。
  5. 如果團隊中沒有一位 OFBiz 的提交者, 可能會降低開發速度, 對策是 "賣出" 一位專案中的提交者, 和 OFBiz 提交者建立結盟關係, 以持續正式審核與提交你專案中的修補檔案。請注意到, 如果讓我們知道是在擘劃進行更大進展的特質, 我們或許可找到一位志願與你一同進行工作的人。
  6. 請瞭解到在 OFBiz 中沒有支付薪水的員工, 全部都是志願者。也許會看到你的修補檔案在 Jira 待了很長一段時間, 而提交者都在處理其他事情。這通常是由於提交者會優先處理發生問題的地方, 或為了生活先去處理有付款的合約, 這才能繼續幫助 OFBiz。
  7. 沒有 OFBiz 提交者加入, 只靠自己的努力也許會有些風險。請明白提交者能在技術上, 業務上, 以及法律方面提供協助, 無論是由他們自己本身, 或透過與 ASF 內的專案成員經常性合作。

Anchor
NamingEntities
NamingEntities

Note
title實體與欄位的命名

這裡有一些慣例, 或說是樣式, 做為共通用來定義實體與其欄位。

  • 實體名稱必須是大駝峰式命名法 (UpperCamelCase)。
  • 實體名稱長度要短到以符合自動轉成的資料庫表格名稱 (大寫字母前會加上底線符號), 要小於 30 個字元。
  • 欄位名稱長度要短到以符合自動轉成的資料庫欄位名稱 (大寫字母前會加上底線符號), 要小於 30 個字元。
  • 外鍵名稱不應超過 18 個字元。
  • 如果實體名稱有縮寫像是 Unit Of Measure (UOM), 則視為英文單字處理, 如: Uom。
  • 欄位名稱必須是小駝峰式命名法 (lowerCamelCase), 且名稱應要能充份表達該欄位目的。
  • 如果關連標籤(tag)指定了兩個實體之間的關係, 則外鍵應包含兩個實體的單字, 並以底線 ("_") 區隔。
  • 如果實體關連和其它實體的定義超過一次, 就該用標題(title)屬性來區分, 定義出 "來自" 那裡或 "至" 那裡。
  • 如果兩邊欄位在 <key-map> 標籤是相同的, 就不用指定 rel-field-name。
  • 在檢視實體 (view entities) 名稱應包含所有成員實體的名稱。
  • <view-link> 應該要定義, 才能正確在網站工具(webtools)看到。

除了上面描述的之外, 也可參考 entitymodel.xsd 來瞭解標籤的用途。

Anchor
DeprecatingEntities
DeprecatingEntities

Warning
title停用實體

當在 OFBiz 要停用一個實體, 底下這些事情必須完成, 否則所有提交者都應駁回此修補:

  1. 將停用的實體改名, 加上 Old 在前面, 然後指定實體的表格名稱屬性, 仍舊指到資料庫原本的表格名稱。
  2. 建立新的實體取代舊的, 並寫註解做說明
  3. 實作一個服務把舊的停用實體資料搬到新的實體

將會看到這種樣式在一些地方使用。這方式是使用者所期待的, 便於從 OFBiz 的一個版本升級到另一個版本。

Center

如何發送貢獻 (或如何建立與使用修補檔案)

首先是為自己在 JIRA 事例追蹤服務 建立一個帳號, 然後才建立一個新的事例。描述貢獻做了什麼: 是修正一個錯誤, 改進一項既有功能, 或者建立一個新的功能? 請儘可能詳細描述, 也可能附帶螢幕截圖, 如果可以展示成果的話。OFBiz 是個巨大的專案, 對你來說很直覺的, 對其他人則不一定, 即使像是提交者熟悉這個專案也會如此。

然後送出修補檔案。這個檔案描述修改的程式碼和 OFBiz 在 Subversion 儲存庫之間的不同。請使用下面慣用名稱為修補檔案命名。
修補檔案名稱應該是 OFBIZ-編碼_功能描述.patch (OFBIZ-number_featureDescription.patch), 在這裡 OFBIZ-編碼 是 Jira 事例的名稱, 而 功能描述 是 Jira 事例的標題, 如果標題短就全放, 長的話就放部分。

可藉由以下方式建立修補檔案

  • 命令列 (請參考後面說明如何做)
  • Eclipse 內部命令 ... 不要點選 結束 (Finish), 但去做 選擇專案 (select project) 已避免在修補檔案出現首兩列文字, 參考 OFBIZ-4410 起中有意見說明此例。
  • 像是 Tortoise 這類的工具

我們偏好從根目錄建立的修補檔案, 對提交者會較容易處理合併。因此請從 OFBIZ_HOME 目錄建立你的修補檔案 (通常是 ofbiz/), 其中包含著相對的檔案路徑。
"相對的檔案路徑" 意謂修補的檔案名稱該看起來像這些:
applications/party/widget/partymgr/PartyScreens.xml
framework/webtools/config/WebtoolsErrorUiLabels.properties
不該有檔案名稱像是: C:\myfiles\ofbiz\applications\party\widget\partymgr\PartyScreens.xml

使用命令列的範例:

Code Block
svn di applications/product > OFBIZ-編號_功能說明.patch

如果有加入新的檔案, 請先使用 "add" 命令, 然後才做 diff

Code Block
svn add applications/product/<我的-檔案>
svn di applications/product > OFBIZ-編號_功能說明.patch

可指定確切的檔案置入修補檔案中, 有時候有些檔案被修改過, 但不希望提交出去。舉例來說, 可以先用

Code Block
svn status applications/product

可以看到什麼檔案被改過 (那些以 "M" 開頭) 或新加的 (那些以 "?" 開頭)。
然後執行:

Code Block
svn di applications/product/entity/ applications/product/script/org/ofbiz/shipment/shipment/ShipmentServices.xml > OFBIZ-編號_功能說明.patch

這個例子表示只要把 entity/ 子目錄, 以及 ShipmentServices.xml 做成修補檔案。

請確定你使用本地版本是當前最新的版本, 或儘可能是最近從 OFBiz SVN 儲存庫而來的。 本地版本可使用下面指令檢查:

Code Block
svn info

要確定使用最新最近的版本, 請在動手做修補檔案前更新 SVN, 執行下面指令:

Code Block
svn up

這是在提交一個修補檔案前必須要做的, 否則這修補可能無法使用。如果你的本地儲存庫是從其他 SVN 儲存庫, 像是供應商分支取出的, 而不是直接從 OFBiz 的 SVN 取得。那就應該先請上游供應商先更新分支, 合併, 而後在做 svn diff 建立修補檔案前, 更新你本地的儲存庫。

接下來上傳修補檔案到你的 JIRA 事例。請使用 .patch 為副檔名, 有些工具會使用它, 且這對提交者的工作有幫助。
最後, 同一個事例中, 如果有數個修補檔案存在, 請在意見中寫明應該使用那一個。最佳實務是更新修補檔案時, 保持相同的檔案名稱。Jira 將會特別處理, 留下這些檔案(有歷史比較好), 但因檔名相同, 舊的會變成灰色表示停用。對提交者來說, 很容易一眼看到要用的檔案。而當檔名不相同, 也能讀下面頭一個意見瞭解該怎麼做。

當 Jira 事例已完全解決, 我們會關閉事例, 而不是標示已解決。有些情況是, 雖然有暫時的方案, 但故意不 關閉 事例, 因為想獲得更多回報, 或是其他人來審核, 測試, 修正。如果是簡單的事例, 特別是本身就做好回報, 最好的方式就是逕行 關閉, 而不是之後再做 關閉。

未完 ...