2012-02-23 89 views
5

我們的團隊對於基於JVM的開發有點新。我們正在開發由許多其他庫組成的應用程序。使用Play 2.0應用程序進行依賴管理

我們發現Play框架對開發Web應用程序非常有吸引力。這個框架非常棒,但是我們本地開發的庫的依賴管理有點令人煩惱。我們使用Play 2.0的RC2,雖然我們能夠將我們的庫加載到Play中進行更改,但這絕對是一個尷尬的過程,會中斷通常平滑的Play過程。

我們正在做的是將我們的庫推送到我們的本地(在每個開發人員的機器上)Maven存儲庫,然後將這些相同的庫導入到Play項目中。它有效,但正如我所說,它很尷尬。

我們應該採用什麼樣的最佳實踐來讓這項工作更順利?

FWIW,我們使用的IntelliJ 11.0(旗艦版)

============ ============編輯

我如何改進我的Maven構建過程,我會得到很好的答案,我很欣賞這一點。但是,這不是我正在尋找的答案。

爲了使這個具體,假設我建立一個服務和Web應用程序來監視/管理服務。該服務是一個普通的Java/Scala項目,Web App是一個Play!項目。我們將稱這些「服務」和「應用程序」。 (請不要挑剔這個建議的結構,我簡化它的目的是這個問題)

在Eclipse或IntelliJ中,我可以添加'服務'模塊(或項目爲Eclipse)作爲依賴項'App'項目。這使得在「服務」庫中進行更改時,開發人員可以快速完成轉換(例如,向模型添加屬性)。重新編譯和運行比編譯,打包,部署,導入和重新加載瀏覽器要快幾個數量級。

根據我對Play 2.0和SBT文檔的閱讀,我唯一真正的答案是使'服務'成爲'應用'的子項目。有更好的答案嗎?

回答

1

您有2個選項。

第一個,就像Rich提到的那樣,是一個本地存儲庫。這並不意味着您的開發機器中的本地文件夾,maven創建爲本地緩存並且正在使用。這意味着您的局域網中的一個中央服務器,您可以在其中存儲Play以供稍後檢索的應用程序版本。按照Rich的推薦,Nexus是一個不錯的選擇。

第二個選項是簡單地構建您的罐子並將它們作爲非託管庫部署在您的「庫」文件夾中。然後你可以將它提交給你的源代碼管理系統,並且所有的開發者都會擁有相同的代碼。

我推薦第一種方法,長期好得多,但這是您的選擇。

編輯點評 你說你不想管理依賴關係。我能想象的唯一的第三種情況是你想要把所有的代碼作爲一個塊。在這種情況下,您可以使用subprojects。我沒有看到其他選擇。

+0

我很欣賞你在說什麼,但是你仍然在努力改進一個我正試圖消除的過程。我要編輯這個問題來澄清這一點。 – 2012-02-24 15:47:35

+0

@AndyDavis見更新 – 2012-02-24 16:06:26

+0

再次感謝您的意見。如果你能看看我的例子,看看子項目是否可行,我將不勝感激。 – 2012-02-24 16:13:42

0

在大多數情況下,Play的確有很大的興趣。但是,有一種情況是Play可能不是最好的解決方案,正是您指出的問題:當有其他組件時,庫將集成到應用程序中。

我並不是說這是不可能的,它根本不是Play被設想的方式。

+0

抱歉,這是FUD。 Play 2.0使用sbt來管理依賴關係,maven,sbt或ivy之間的區別幾乎爲零。那麼,所有使用它們的項目都是錯誤的嗎? :) – 2012-02-24 15:10:25

+0

我可能沒有足夠的Play2遊戲體驗,但它確實是Play 1.x的例子。 – 2012-02-24 15:13:32

1

您應該推送到本地Maven鏡像/代理,例如Nexus

+0

我已經有一個本地存儲庫。我並不想改善這一點,因爲我期望繞過它(至少對於開發而言) – 2012-02-24 14:06:38