Xuất bản một bom từ một dự án đa mô-đun

Question

Chúng tôi là một công ty lớn với khoảng 2000 dự án Java riêng biệt. Vì lý do lịch sử, chúng tôi không có dự án nhiều mô-đun, nhưng chúng tôi muốn giới thiệu chúng.

Về mặt logic, chúng tôi đã có "nhóm" dự án, nghĩa là ai đó chịu trách nhiệm về (nói) 50 dự án liên quan chặt chẽ. Người này thường xuyên xuất bản một BOM có chứa các phiên bản gần đây, mạch lạc của 50 dự án này.

Bây giờ, sẽ có nhiều ý nghĩa để lấy 50 dự án này và đưa chúng vào một dự án nhiều mô-đun lớn. Tuy nhiên, nó sẽ là cần thiết để xuất bản một BOM vì các dự án khác (bên ngoài nhóm của chúng tôi) cần phải có các phiên bản mạch lạc.

Vì vậy, tóm tắt, chúng tôi cần một BOM có chứa các phiên bản của tất cả 50 dự án là một phần của dự án đa mô-đun. Tôi tự hỏi điều gì sẽ là "cách Maven" để tạo ra một BOM như vậy. Những gì tôi có thể nghĩ đến:

• Bom là dự án thứ 51 của dự án đa mô-đun. Các phiên bản của các phụ thuộc được thiết lập bởi các thuộc tính trong pom cha.
• Bom được tạo ra từ thông tin có trong dự án đa mô-đun và được xuất bản dưới dạng tạo tác phụ (điều này có thể yêu cầu chúng tôi viết một plugin Maven cho việc này).

Điều gì sẽ được khuyến khích?

Answer 1

Chúng tôi đang sử dụng BOM cũng như cho các dự án đa mô-đun của chúng tôi, nhưng chúng tôi không gắn kết thế hệ của họ hoặc cập nhật để xây dựng các mô-đun đó.

Một BOM chỉ được cập nhật khi quy trình quản lý phát hành hoàn thành việc phân phối mô-đun đã xây dựng (hoặc nhóm mô-đun): sau khi được phân phối, BOM được cập nhật và đẩy lên Nexus (được lưu trữ dưới dạng phiên bản 1.0-SNAPSHOT) ghi đè sau mỗi lần giao hàng)

các BOM sau đó được bao gồm trong POM của chúng tôi (đối với dự án mono hoặc nhiều mô-đun) và sử dụng chỉ quản lý phụ thuộc, có nghĩa là các dự án của chúng tôi phụ thuộc vào vật mà không phiên bản: quản lý sự phụ thuộc từ BOM cung cấp phiên bản phân phối mới nhất của các mô đun phụ thuộc khác.

Nói cách khác, chúng tôi tách biệt khía cạnh xây dựng (thực hiện ở đây với maven) từ phần phát hành: "hóa đơn nguyên liệu" đại diện cho những gì đã được phân phối và đảm bảo tất cả các dự án đang xây dựng với các phiên bản được coi là hoạt động tốt với nhau (chúng đã được đưa vào sản xuất cùng nhau).

Answer 2

Tôi chưa từng thấy 2K các dự án Java thương mại, như vậy sẽ căn cứ câu trả lời của tôi về cách mã nguồn mở hoạt động:

• Thư viện không nên được nhóm lại theo người - họ nên được nhóm lại theo những vấn đề họ giải quyết. Các dự án mã nguồn mở thường có nhiều libs, ví dụ: Jackson có jackson-databind, jackson-datatype-jsr310, vv Các libs này liên quan chặt chẽ với nhau và có thể phụ thuộc lẫn nhau.
• Các nhóm như vậy không nên quá lớn. Một số dự án có thể có 1, những dự án khác - 5 hoặc 10. 50 libs trong một nhóm có vẻ quá nhiều.
• Sẽ dễ dàng hơn nếu libs trong một nhóm được giải phóng tất cả cùng một lúc (ngay cả khi chỉ có một cập nhật). Điều này giúp bạn dễ dàng theo dõi các phiên bản trong các ứng dụng sử dụng nhiều lib từ một nhóm.
• Nên có không phụ thuộc giữa các nhóm! Và đây có lẽ là quy tắc quan trọng nhất. Phân cấp sâu của các thư viện phụ thuộc vào nhau là không thể chấp nhận được vì bây giờ bạn cần phải giữ sự tương thích giữa nhiều dự án và libs. Điều này chỉ không quy mô. Điều đó có nghĩa là thỉnh thoảng sẽ có mã sao chép-dán giữa các lib - đây là cái ác nhỏ hơn.
• Có thể có một số ngoại lệ đối với quy tắc cuối cùng (có thể là một lib được sử dụng ở mọi nơi) nhưng phải giữ lại tính tương thích ngược của API công khai cho đến khi không có dự án nào phụ thuộc vào API cũ. Các thư viện này rất khó duy trì và tốt hơn nên mở chúng ra.

Dự án độc lập bây giờ có thể phụ thuộc vào thư viện từ cùng một nhóm hoặc khác nhau, nhưng vì phiên bản trong nhóm giống nhau, thật dễ dàng để đặt nó làm thuộc tính chỉ một lần.Hoặc:

• Bạn có thể nhìn vào <scope>import</scope> mà cho phép nhập khẩu <dependencyManagement> phần từ các tập tin POM khác như POMs cha mẹ trong một nhóm (đối với một số lý do không bao giờ làm việc cho tôi).
• Hoặc tại tất cả các mô-đun xxx - một mô-đun phụ thuộc vào tất cả các mô-đun khác trong nhóm và do đó khi bạn phụ thuộc vào nó, bạn cũng phụ thuộc vào người khác quá mức.