Áp dụng quy ước đặt tên nhóm quạ

Question

Tôi đang phát triển một số dự án (hiện đang được tổ chức làm dự án nhật thực). Có một dự án cốt lõi mà chủ yếu cung cấp API lõi và một số triển khai thứ cấp và các lớp trừu tượng. Tất cả các dự án khác đều phụ thuộc vào dự án này.

Khi tích hợp các dự án vào kho lưu trữ maven của chúng tôi, chúng tôi gặp sự cố với quy ước đặt tên maven. Như đã thảo luận trên SO, groupId thường phải là tên miền công ty ngược lại (com.example) cộng với tên dự án (com.example.foo). Các quy ước đặt tên maven đề xuất một postfix bổ sung cho các dự án phụ như các plugin (com.example.foo.plugin).

Trong trường hợp của chúng tôi, chúng tôi chưa có plugin, nhưng triển khai nhiều (chủ yếu là độc lập) của API do dự án cốt lõi cung cấp. đặt tên đề nghị hiện tại của chúng tôi là:

• com.example.foo như groupId của tất cả các dự án, mặc dù họ đang chia ra thành các gói java khác nhau (com.example.foo chứa các API, com.example.foo.bar chứa thi bar)
• tên dự án như artifactId , mà không có một tiền tố đề cập đến dự án (bar thay vì foo-bar)

điểm mấu chốt là (mặc dù các dự án của chúng tôi được lan truyền accross gói như đã mô tả ở trên) họ không thực sự phụ p rojects của dự án lõi API.

Đề xuất này có tuân thủ các quy ước đặt tên maven không?

Chỉ trong trường hợp: Câu hỏi này là không phải số yêu cầu trả lời được phân tích mà là câu trả lời cho câu hỏi trên.

Answer 1

Tôi cho rằng đây là vấn đề sở thích và sở thích của riêng bạn.

Thông thường, bạn sẽ nhóm các nhóm mô-đun tương tự theo cùng một groupId. Ví dụ, bạn có thể có những điều sau đây:

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) ... 

Bạn không nhất thiết cần phải nhóm tất cả các module mà các lớp học bắt đầu với một gói chung dưới cùng groupId. Bạn có thể làm điều đó, nếu bạn thích, nhưng đó là hiếm khi mọi người thực sự sử dụng nó trong cuộc sống thực. Mức độ nghiêm ngặt và độ lớn của chi tiết tùy thuộc vào bạn, nhưng trong trường hợp các hiện vật, nó thường không quan trọng nhiều như không có gì để buộc tên gói vào groupId.

Ngoài ra, việc sử dụng tiền tố cho mô-đun của bạn cũng hữu ích, nhưng tùy thuộc vào bạn. Nếu bạn thích, bạn có thể có:

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

Điều này thực sự tùy thuộc vào bạn. Một số người cho rằng nếu bạn có số groupId như com.foo.bar, thì bạn không cần phải có tiền tố bar- trong bar-parent. Điều này đúng ở một khía cạnh nào đó. Nhưng sau đó bạn có thể có com.foo.bar:parent và com.foo.bar.web:parent và khi bạn đang sử dụng trình quản lý kho như Nexus, Archiva hoặc Artifactory và bạn đang tìm kiếm parent, (hoặc một số tên thông dụng khác như ... commons, ví dụ), bạn có thể kết thúc với danh sách kết quả khá dài, trái ngược với bar-parent.

Cuối cùng, điều quan trọng là mức độ chi tiết bạn muốn đi và điều gì thực sự phù hợp với nhu cầu của bạn. Maven cho phép bạn tự do bạn cần trong lĩnh vực này.

Answer 2

Vì vậy, khi tôi nhìn thấy nó, bạn có một loạt các tùy chọn mà theo quy ước đặt tên maven ...

Foo đề cập đến API lõi và thanh đề cập đến việc thực hiện.

1. com.example.foo (tham chiếu api lõi) làm nhóm và sau đó triển khai thực hiện foo-bar (quy ước cho biết bạn đưa móc vào nhóm trong tên tạo tác).

2. com.example.bar như nhóm Thr và id vật là thanh-impl hoặc một số hậu tố thích hợp khác

3. com.example.foo.bar như nhóm và thanh-impl hoặc một số hậu tố thích hợp khác .

Đối bạn đang nói đến quen thuộc: việc thực hiện được kết hợp chặt chẽ với các API và có một chu kỳ phát hành liên quan chặt chẽ. Khi một phiên bản mới của API lõi được phát hành, một phiên bản thực hiện cũng được phát hành. Hơn nữa việc thực hiện là một đứa trẻ của API cốt lõi và không thực sự đứng một mình. Bạn cũng nói rằng việc kinh doanh cốt lõi của quán bar là thực hiện thanh và có ít giá trị ngoài nó (nó không làm được gì nhiều).

Trong bạn đang nói đến việc thực hiện các API cốt lõi không phải đó là vòng đời riêng và nói chung không được phát hành vào chu kỳ giống như API.Hơn nữa nó không phải là một dự án phụ của API lõi và do đó có thể đứng một mình. Nói cách khác, đó là kinh doanh cốt lõi và cách sử dụng không chỉ là một ý nghĩa của foo. Nếu quán bar có thể có anh chị em thì điều này đặc biệt hấp dẫn.

là con đường ở giữa. Nó nói thanh có giá trị của chính nó cũng như có ý nghĩa như một thực hiện foo và cũng có khả năng cho phép anh chị em. Nó hơi cải thiện trên 2 vì nó cung cấp một số thông tin phản hồi rằng hiện vật này là một thực hiện của foo. Một lần nữa, nếu quán bar có thể có anh chị em này có ý nghĩa hơn.

Vì vậy, tôi đoán bạn cần chọn nơi triển khai API của bạn. Người lái xe lớn nhất có lẽ là thanh có thể có anh chị em ruột.

Answer 3

Tôi muốn nói rằng bạn có thể có tất cả các tạo phẩm của mình trong cùng một nhómId. Nhưng bạn nên sử dụng mô hình dự án phụ nếu thích hợp.

Ví dụ: mùa xuân có tất cả các tạo phẩm chính trong một nhómId, org.springframework. Điều đó bao gồm cốt lõi của mùa xuân và các tiểu dự án JMS, ORM và WMV. Nhưng sau đó các dự án con lớn hơn như Spring Boot có một groupId riêng biệt, org.springframework.boot. Tôi sẽ nói đây là một mô hình tốt để làm theo.

Answer 4

Việc đặt tên cho mọi thứ thực sự quan trọng và tên phải truyền đạt thông tin quan trọng ngay lập tức. Vì lý do này, các quy ước mà công ty của tôi đã sử dụng cho rằng Id nhóm nên giống nhau đối với tất cả việc triển khai một điều cụ thể: mỗi Id nhóm của một người là com.example.foo, bởi vì chúng đều là triển khai thực hiện điều đó.Tên dự án nên tham khảo giao diện, và có gạch nối với tên thực hiện cụ thể của họ, với pom mẹ chính nhãn nổi bật như 'mẹ':

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

Bằng cách này, bạn có thể nói trong nháy mắt từ những cái tên chính xác những thứ này có liên quan như thế nào, và các tên tạo tác cũng có nghĩa là chúng là các loại foo khác nhau. Điều này cũng có nghĩa là nhập khẩu trong mã java theo chính xác cấu trúc tương tự. Nó cũng làm cho việc nhập khẩu rất rõ ràng và dễ hiểu trong mã java.