應用maven groupId命名約定

我正在開發一些項目（目前組織爲eclipse項目）。有一個主要提供核心API和一些輔助實現和抽象類的核心項目。所有其他項目都依賴於這個項目。應用maven groupId命名約定

將項目集成到我們的Maven存儲庫時，我們遇到了Maven命名約定的問題。正如在SO上所討論的，groupId通常應該是反向公司域名（com.example）加上項目名稱（com.example.foo）。 maven命名約定爲插件等子項目提供了額外的後綴（com.example.foo.plugin）。

在我們的例子中，我們沒有插件，但是核心項目提供了API的多個（主要是獨立的）實現。我們當前的命名建議是：

com.example.foo所有項目的groupId，雖然他們分成不同的Java包（com.example.foo包含API，com.example.foo.bar包含bar實現）
項目名稱爲的artifactId ，沒有前綴參照項目（的bar代替foo-bar）

關鍵的一點是，（雖然我們的項目被分散翻過包如上所述），他們是不是真的子-p API核心項目的主要內容。

此建議是否符合maven命名約定？

以防萬一：這個問題是而不是要求有意義的答覆，但對上述問題的爭論性答案。

來源

2014-09-01 just lerning

我必須誠實地說，我從來沒有把這麼多想法放入Maven的命名約定中:-) – kaqqao 2014-09-01 18:50:55

@kaqqao嗯，我們做:) – 2014-09-01 19:43:05

我會說這是你自己的品味和喜好的問題。

通常情況下，您可以在相同的groupId下對相似的模塊組進行分組。例如，你可以有以下幾點：

com.foo.bar:parent       (parent pom for all projects) 
com.foo.bar:core-api      (some very core classes) 
com.foo.bar:commons       (some common classes) 
com.foo.bar:io        (some IO classes) 
com.foo.bar:utils       (some utility classes) 
com.foo.bar.messaging:messaging-core  (messaging core classes) 
com.foo.bar.messaging:messaging-rest-api (REST API for messaging) 
com.foo.bar.messaging:messaging-jms   (some JMS code) 
com.foo.bar.web:rest-api     (your restlets) 
com.foo.bar.web:web-core     (core classes to be used by web modules) 
com.foo.bar.web:web-parent     (a parent pom for all your web projects) 
com.foo.bar.web:web-ui      (UI stuff like css/images/js/etc) 
com.foo.bar.web:web-assembly    (a web assembly that bundles all modules) 
... (I hope by now you get my drift) ...

你並不一定需要一羣人的班級開始在相同groupId一個共同的包中的所有模塊。你可能這樣做，如果你喜歡，但很少有人真正在現實生活中使用它。嚴格程度和詳細程度取決於您，但對於工件而言，通常無關緊要，因爲沒有必要將包名稱與groupId綁定。

此外，爲您的模塊使用前綴也很有幫助，但取決於您。如果你喜歡，你可以有：

com.foo.bar:bar-parent 
com.foo.bar:bar-core-api 
com.foo.bar:bar-commons

這真的取決於你。有人會說，如果你有groupId像com.foo.bar，那麼bar-parent的前綴就不需要有bar-的前綴。在某種程度上，這是事實。但是，您可能有com.foo.bar:parent和com.foo.bar.web:parent，並且當您使用像Nexus，Archiva或Artifactory這樣的存儲庫管理器時，如果您正在搜索parent（或其他常用名稱，例如... commons），則可能會結束結果列表較長，與bar-parent相反。

最後，重要的是你願意去什麼樣的細節和什麼會真正適合你的需求。 Maven可以讓你在這方面獲得所有你需要的自由。

來源

2014-09-04 13:07:10 carlspring

另外：請記住，groupId + artifactId組合在全球範圍內必須是唯一的（！），因此使用domainname作爲groupId的開頭的約定會有所幫助。使用單個groupId就像爲所有文件使用單個文件夾：一旦您達到某個數字，您將忽略概述，並且會引入子文件夾。切換到新的groupId和/或artifactId可能對Maven有影響，因爲它不知道它是相同的，導致項目中出現重複的代碼。所以是的，在前面選擇合適的組。 – 2014-09-07 12:41:06

很高興收到一位Maven官方開發人員的評論，確認（並擴展）我的觀點！ – carlspring 2014-09-07 12:51:39

所以當我看到它，你有一堆隨後行家命名約定選項...

富指的是核心API和酒吧是指實施。

com.example.foo（指核心API）作爲組，然後是FOO條的實施（約定說您在您的工件名稱鉤回組）。
com.example.bar作爲THR組和工件ID是直板IMPL或其它一些適當的後綴
com.example.foo.bar作爲組和條形IMPL或其它一些適當的後綴。

對於你說對不熟悉的：實現緊密耦合到API並具有密切相關的發佈週期。當核心API的新版本發佈時，還會發佈一個版本的實現。此外，實施是核心API的一個孩子，並不是真正的獨立。你也在說酒吧的核心業務是實施酒吧，除此之外沒什麼價值（它不會做其他事情）。

您在說核心API的實現確實有它自己的生命週期，並且通常不會在與API相同的週期內發佈。此外，它不是核心API的子項目，因此可以獨立運作。換句話說，這是核心業務，使用不僅僅是作爲foo的實現。如果酒吧可以有兄弟姐妹，這是特別有吸引力的。

是兩者之間的中間道路。它表示bar本身具有價值，並且具有作爲foo的實現的重要性，並且還可能允許兄弟姐妹。它略微提高了2，因爲它提供了一些反饋，這個工件是foo的實現。再次，如果酒吧可以有兄弟姐妹，這更有意義。

所以我想你需要選擇你的API實現的位置。最大的推動力可能是酒吧是否可以有兄弟姐妹。

來源

2014-09-04 10:56:40

好吧，酒吧可以有兄弟姐妹，我們開發了一個由獨立實現的客戶端和服務器包組成的實現。你描述的第三種方式聽起來很棒。你能再給我一個答案嗎？如果我寫了一個基本上在api附近提供UI的gui，該怎麼辦？它與核心api無關，所以應該是com.example.foo.gui還是com.example.foo-gui？我想這終究真的是個人品味的問題，你怎麼看？無論如何感謝您的回答！ – 2014-09-04 11:17:00

我想說可以將所有工件放在同一個groupId中。但是你應該在適當的地方使用子項目模式。

例如，spring的所有主要工件都在一個組中，org.springframework。這包括Spring的核心和JMS，ORM和WMV子項目。但是，像Spring Boot這樣的更大的子項目有一個單獨的組ID，org.springframework.boot。我會說這是一個很好的模式。

來源

2014-09-04 11:44:23

事物的命名非常重要，名字應該馬上傳達重要信息。出於這個原因，我公司使用的約定規定，對於特定事物的所有實現，組Id應該是相同的：每個組的Id都是com.example.foo，因爲它們都是實現的。該項目的名稱應該是指接口，並且，連字符和名稱爲自己特定的實現，以顯着位置標明爲「父」主父POM：

com.example.foo:parent 
com.example.foo:foo-bar 
com.example.foo:foo-bat 
com.example.foo:foo-baz

這種方式，你可以從名字一眼就能看出這些事情究竟是如何相關的，並且工件名稱也單獨表示它們是不同類型的foo。這也意味着在java代碼中的導入遵循完全相同的結構。它也使得導入在java代碼中非常易讀易懂。

來源

2014-09-11 01:11:49

應用maven groupId命名約定

回答

相關問題