Chia tách một dự án lớn để tạo dự án Maven đa mô-đun


23

Tôi đang làm việc trên một ứng dụng Spring-MVC mà chúng tôi đang sử dụng Maven để quản lý phụ thuộc. Khi dự án lớn, chúng tôi đang nghĩ đến việc chia dự án thành nhiều phần. Tôi đã có một số nghi ngờ, mà tôi hy vọng sẽ nhận được câu trả lời ở đây.

Hiện tại, chúng tôi đang triển khai một tệp WAR duy nhất như ROOT.wartrên tomcat Apache trên máy chủ của chúng tôi. Vì dự án rất lớn, có các phần trong ứng dụng web như Thông báo và Email, dịch vụ của bên thứ ba, PUSH (Cometd), API REST, v.v. Hiện tại tất cả chúng đều được ghép thành câu lạc bộ và phụ thuộc vào nhau. Ví dụ: Notificationđối tượng cũng phụ thuộc vào Personđối tượng, vì Thông báo được tùy chỉnh cho người dùng.

Mục đích chính của việc chia tách dự án lớn là có thể hoạt động trên các mô-đun riêng lẻ, để sửa lỗi, thêm tính năng, kiểm tra, v.v. Và khi hài lòng, chỉ có thể thay thế mô-đun này trên máy chủ thay vì toàn bộ ứng dụng. Điều này có thể không?

Như tôi đã đề cập trước đây, có các phụ thuộc và ánh xạ giữa các đối tượng. Làm thế nào những cái đó sẽ được quản lý trên các mô-đun phụ khác nhau, hoặc chỉ các báo cáo nhập khẩu sẽ thay đổi để bao gồm các dự án khác?

Như tôi đã nói, ý định là làm việc trên các mô-đun riêng lẻ và có thể triển khai chúng (tốt nhất là nóng). Hiện tại, chúng tôi chỉ có một tệp WAR duy nhất là ROOT.war. Việc chia tách sẽ tạo ra nhiều tệp chiến tranh, sau đó được gọi bằng URL là domain-name.com/module_name/some_mapping?

Tôi hiện đang kiểm tra tài liệu, nhưng đây là mục tiêu chính mà chúng tôi muốn đạt được với nhiều mô-đun được cung cấp bởi Maven và quan tâm để biết liệu điều này có khả thi hay không. Nếu có thêm thông tin cần thiết, xin vui lòng cho tôi biết.

Hiện tại tôi đang sử dụng POM gốc từ mùa xuân như sau:

<parent>
    <groupId>io.spring.platform</groupId>
    <artifactId>platform-bom</artifactId>
    <version>1.1.3.RELEASE</version>
    <relativePath />
</parent>

1
Tôi để nó cho người khác trả lời. Ý tưởng rất âm thanh. Bạn có thể bắt đầu với POM gốc với Quản lý phụ thuộc và một nhóm cho các DAO như Person. Một thư viện rất cơ bản. Và như vậy. Tất nhiên không phụ thuộc theo chu kỳ.
Eggen

Câu trả lời:


20

Có thể không?

Vâng chắc chắn. Tôi có trong cấu trúc quá khứ một vài dự án như thế này, ở đây một số bit tôi hy vọng sẽ giúp bạn bắt đầu.

Có hai tính năng chính của Maven mà bạn sẽ sử dụng để dệt mọi thứ lại với nhau:

Phân chia và chinh phục

Bạn sẽ cần phải chia các dự án của bạn trong nhiều dự án độc lập. Ở đây bởi độc lập tôi có nghĩa là tất cả các tham chiếu đến mã bên ngoài dự án được thực hiện thông qua các phụ thuộc trong Maven và không trực tiếp hợp nhất cây nguồn.

Tùy thuộc vào trạng thái của cây nguồn của bạn, điều này có thể đại diện cho rất nhiều công việc. Điều đó nói rằng bạn không làm điều đó để đánh giày với Maven mà là một phương tiện để cấu trúc và vệ sinh cơ sở mã của bạn. Hãy nghĩ về nó như là công cụ của bạn, dễ dàng hơn để tìm thấy những thứ ở đây:

Dụng cụ đẹp

hơn ở đây:

Công cụ không đẹp

Maven phụ thuộc rất nhiều vào quy ước nên công cụ của bạn được tổ chức tốt hơn là Maven có thể giúp bạn nhiều hơn. Điều đó nói rằng, nó có thể yêu cầu bạn tổ chức lại để phù hợp hơn với quy ước của riêng nó và nếu tôi phải đưa ra một lời khuyên ở đây là việc thay đổi công cụ của bạn để phù hợp với quy ước của Maven hơn là thử và định cấu hình Maven thành hiểu quy ước của bạn.

Nếu các dự án này có thể sử dụng được bên ngoài ứng dụng chính, chúng có thể sống như các thư viện thực sự độc lập và bao gồm cả phụ thuộc maven. Họ nên sống trong kho lưu trữ của riêng họ (không phải trong cây nguồn ứng dụng) và không nên phụ thuộc vào bất kỳ phần nào của ứng dụng chính.

Các phần cốt lõi của ứng dụng của bạn, một khi được phân chia trong các dự án có thể được đặt cùng nhau dưới dạng các mô-đun. Thông thường, bạn sẽ đặt chúng làm thư mục con của thư mục nguồn chính của ứng dụng.

Ngoài ra POM cha của bạn cho ứng dụng của bạn sẽ chứa khai báo mô-đun. Bạn cũng sẽ đặt vào đó tất cả các phụ thuộc chung cho ứng dụng của mình cũng như khai báo hầu hết các plugin xây dựng và cấu hình của chúng. Ở đây tôi cũng khuyên bạn nên đặt một nhóm các thuộc tính cho những thứ như phiên bản của ứng dụng mà bạn có thể sử dụng lại trong các mô-đun. Quản lý dễ dàng hơn nhiều khi mọi thứ đều có cùng một phiên bản và có phiên bản ở một nơi làm cho điều này chỉ hoạt động.

Dụng cụ

Nếu bạn là một nhóm lớn hơn 1, tôi cũng rất khuyến khích bạn cài đặt một kho lưu trữ cho các phụ thuộc Maven của bạn. Nhìn vào Artifactory , Nexus hoặc Archiva . Bạn có thể định cấu hình tệp POM để cài đặt trực tiếp vào các tệp này để một khi chạy, nó sẽ không tốn nhiều chi phí nhưng sẽ tiết kiệm cho nhóm của bạn rất nhiều thời gian để giải quyết các phụ thuộc với bình đúng ở đúng vị trí.

Về chủ đề công cụ, bước hợp lý tiếp theo ở đây là một hệ thống tích hợp liên tục ( Jenkins , còn nhiều thứ nữa). Nó sẽ xử lý việc xây dựng nguồn chạy các bài kiểm tra và đẩy đến mức giả tạo, với tất cả điều này tại chỗ, tất cả những gì bạn phải làm là làm việc mã và phần còn lại chỉ hoạt động.

Vì bạn đang đóng gói ứng dụng của mình như một con ma chiến tranh có thể xử lý việc xây dựng chiến tranh và đặt tất cả các phụ thuộc vào vị trí thích hợp của chúng mà không phải hợp nhất các tệp jar hoặc công việc tương tự khác xung quanh, vì vậy không phải lo lắng ở đó.

Thí dụ

Tôi có thể tiếp tục lâu hơn ở đây nhưng không có gì là một ví dụ tốt. Nhìn vào github cho các dự án có độ lớn tương tự và xem cách chúng xây dựng các tệp pom và phân cấp thư mục của chúng. Nhìn vào nhiều hơn một, một số sẽ phù hợp với thiết lập của bạn hơn so với những người khác, không ai thực sự hóa thân vào sự thật nhưng bạn nên tìm đủ để thúc đẩy suy nghĩ của bạn về cách hoàn thành nó.

Lấy Jenkins làm ví dụ:

Bạn có thể thấy POM cha mẹ của họ khá rộng.

Họ sử dụng các mô-đun như bạn có thể thấy trong phần này:

<modules>
    <module>core</module>
    <module>war</module>
    <module>test</module>
    <module>cli</module>
</modules>

Và mỗi mô-đun tương ứng một thư mục con có cùng tên cũng chứa POM. Bạn có thể lồng nhiều như bạn muốn, mặc dù vậy hãy giữ nó trong mức độ tỉnh táo;).

Khởi đầu nhỏ

Nếu bạn chưa bao giờ sử dụng Maven, tôi sẽ đề nghị tuy nhiên bạn không bắt đầu với các mô-đun ngay lập tức. Hãy làm chậm, bắt đầu với, nói một trong những thư viện đơn giản hơn bạn có thể có và biến nó thành một dự án maven. Sau đó, làm cho ứng dụng chính của bạn là một dự án maven đơn giản. Khi công việc đó, bắt đầu thêm các phụ thuộc đơn giản, sau đó tách mô-đun đầu tiên của bạn và cứ thế.

Maven là một công cụ tuyệt vời nhưng nó cũng có thể là một siêu đau ở cổ đặc biệt là khi mọi thứ không theo cách của bạn. Bắt đầu với toàn bộ sự phiền toái trong lần đầu tiên của bạn là một người nhận thảm họa (là cho tôi!).

Nếu mọi thứ hơi kỳ lạ, bạn luôn có thể sử dụng mvn help:effective-pomlệnh để xem Maven thực sự hiểu gì.

bổ sung

Từ nhận xét của bạn tôi hiểu rõ hơn những gì bạn muốn đạt được. Trong trường hợp này tôi sẽ đi tiếp cận plugin. Tạo một dự án hiển thị API của các điểm mở rộng mà bạn muốn cô lập công việc. Sau đó, bạn có thể sử dụng điều này như một sự phụ thuộc trong một dự án mới sẽ thực hiện nó. Trong ứng dụng chính của bạn, chỉ cần thêm các phụ thuộc thích hợp cho các triển khai này (không sử dụng các mô-đun maven lần này) và bạn sẽ thấy ổn. Cuối cùng, dự án ứng dụng chính sẽ mang gần như không có mã nguồn mọi thứ được thực hiện trong các dự án bên ngoài và được tải thông qua các phụ thuộc.

Bạn sẽ cần phải triển khai lại toàn bộ ứng dụng, tuy nhiên với cách tiếp cận này, bất kể lõi có thay đổi hay không vì chiến tranh được xây dựng tĩnh từ các phụ thuộc, thay đổi một trong số chúng ngụ ý xây dựng lại toàn bộ. Nghe có vẻ tệ nhất so với thực tế, thực tế chỉ có những thay đổi mới thực sự được xây dựng, phần còn lại về cơ bản sẽ là một bản sao của (các) bình trước đó. Nhưng vì mọi thứ đều nằm trong tệp tin chiến tranh nên nó sẽ cần phải được xây dựng lại, và máy chủ sẽ cần phải dừng lại và khởi động lại.

Nếu bạn cần phải đi xa hơn, mọi thứ sẽ phức tạp hơn một chút, mặc dù không phải là không thể. Tôi sẽ khuyên bạn nên xem xét OSGI, Apache Felix có thể giúp bạn bắt đầu, mặc dù cũng có những triển khai khác. Điều này sẽ cho phép bạn lấy bình bên ngoài và biến chúng thành các plugin thích hợp. Bạn sẽ có được nhiều quyền kiểm soát hơn trong vòng đời thời gian chạy của các thành phần mở ra cánh cửa để tải lại và cập nhật động. Tuy nhiên, nó sẽ yêu cầu những thay đổi lớn đối với cốt lõi của bạn một lần nữa, có lẽ không phải là điểm khởi đầu tốt. Tuy nhiên, một khi bạn có một dự án tách biệt và có tất cả các phần tách biệt theo cách bạn muốn, đó có thể là bước tiếp theo tự nhiên nếu bắt đầu và dừng ứng dụng khi cập nhật là một vấn đề lớn.

Sự khác biệt cơ bản giữa Mô-đun và phụ thuộc là:

  • Các mô-đun sẽ sống trong cùng một cây nguồn với ứng dụng chính, là thư mục con lý tưởng.
  • Phụ thuộc có thể là bất cứ nơi nào.

Bạn có thể tìm thấy kinh thánh ở đây .

Hy vọng điều này sẽ giúp, chúc may mắn.


Trên thực tế, việc bó các mô-đun thông qua maven thay vì cây nguồn đã làm sáng tỏ rất nhiều câu hỏi mà tôi có. Bạn có thể vui lòng cho tôi biết về việc triển khai một dự án như vậy. Một trong những lý do khác mà chúng tôi đang xem xét là để các nhà phát triển có thể làm việc trên mô-đun cần thiết của họ và thực hiện các thay đổi theo thời gian thực. Một điều chúng tôi muốn tránh là dừng máy chủ ứng dụng và bắt đầu lại, ngoại trừ mô-đun lõi. Như 2 mô-đun tôi có thể nghĩ sẽ chứa mã thay đổi thường xuyên. Chúng tôi sử dụng tomcat làm máy chủ ứng dụng, được cân bằng tải bởi Apache. Cảm ơn bạn.
Chúng tôi là Borg

Các mô-đun Maven thường ngồi trong cùng một cây nguồn với ứng dụng chính. Sử dụng các mô-đun maven bên ngoài cây nguồn thực sự phức tạp hơn giá trị thực sự của nó. Nếu bạn lưu trữ các dự án bên ngoài cây nguồn thì hãy tìm các dự án độc lập bình thường và sử dụng các phụ thuộc bình thường.
Newtopian

Tôi nghĩ rằng chúng tôi sẽ trực tiếp thêm các phần của dự án của chúng tôi dưới dạng phụ thuộc Maven. Bằng cách này, chúng ta có thể trực tiếp làm việc trên các phần của dự án. Tôi chỉ có một câu hỏi, nếu chúng ta thêm một trong các dự án con làm phụ thuộc trong POM.xml, giả sử phiên bản 2.0.0 và sau đó với một số thay đổi, chúng ta sẽ đẩy mô-đun 2.0.1 sang sonatype, làm sao chúng ta có thể trực tiếp báo cho mô-đun lõi đi 2.0.1, sẽ chỉ thay đổi POM.xml bên trong ROOT.war và xóa thư mục ROOT là đủ. Mục đích chính là không dừng máy chủ. Cảm ơn bạn.
Chúng tôi là Borg

pom.xml hoàn toàn không có liên quan gì khi chiến tranh đã được tạo, đó là Tomcat (hoặc bất kỳ vùng chứa nào bạn sử dụng) không sử dụng tệp này. Tệp được Maven sử dụng để tạo tệp chiến tranh mới, đến lượt bạn sẽ phải triển khai đến máy chủ. Vì vậy, chu trình hoạt động trên mã, tạo tệp jar, cập nhật phiên bản trong POM của cuộc chiến, tạo tệp chiến tranh, cập nhật máy chủ với tệp chiến tranh mới. Một số máy chủ sẽ hỗ trợ triển khai lại nóng mặc dù nhìn chung điều đó có nghĩa là tắt ứng dụng trong vài giây.
Newtopian
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.