比方說，我有一個構建，其中有一些相關的子項目，但它們的邏輯分類超出了構建通常意識到的那些類別。多項目構建中的交叉「邏輯」範圍
例如，我可能有子項目
我知道，緯和酒吧是我稱之爲服務器組件的一部分。 Baz是兩者的共同依賴，Foo，Quux和Oink都在客戶端。整個構建是各個子項目的集合，但有時我只想「關注」服務器端或客戶端或其他任何方面。
一方面，我已經考慮了嵌套的聚合項目，但我不確定它是如何與sbt的其他功能一起工作的。
另一方面，我正在考慮制定跨越子項目的自定義範圍。我希望能夠使用類似的鍵配置相關項目，所以能夠說我想爲相關項目組更新某個關鍵字非常方便。
這種事情的好方法是什麼？我在想它錯嗎？
我的看法：跳過子項目。將項目發佈爲獨立項目時，拆分項目很不錯。但是多個項目也會造成麻煩：在多個項目之間建立良好穩定的接口非常困難。
我會盡快將項目拆分爲多個項目。只有一個大項目，依賴管理（特別是循環依賴），重構（特別是類的移動）和工具支持（特別是IDE集成）要好得多。
當覆蓋跨越多個項目時，像測量代碼覆蓋率這樣的事情也會變得非常困難。
自定義範圍和六個子項目：在我看來，這是完全過度工程。留在一個項目中，讓整個事情運行並在稍後分解（如果需要的話）。
與此類似的情況。
我的解決方案是將事情分解成sbt中的所有子項目，並使用dependsOn來鏈接子項目。這裏很好的意外後果是，dependsOn的子項目完美地模擬了Maven的依賴關係。如果你發佈其中的一個，它會奇蹟般地爲其他人提供maven依賴。像eclipse和intelli這樣的工具通常也會很容易地看到這些依賴鏈。
這使您可以選擇是否將物品放在同一個SBT項目中，最後幾乎沒有區別。他們只是在'maven風格'的依賴關係上聯繫在一起。在這裏或遠程的地方使用本地maven回購很有效。在這一點上，您可以根據代碼管理而不是dep-management來選擇是否將事情分解成不同的SBT項目。
編輯：所以最後，如果你想移動模塊出的多項目SBT的事情，你只需要定期行家DEPS添加到任何代碼庫，要求其他
但它已經是分裂。我試圖有效地處理大量現有的代碼庫:) –
@MyseriousDan：可憐的你。也許你至少可以合併一些子項目。儘管理論上很好，但在不同的子項目中拆分代碼通常會在實踐中導致很多麻煩。 –