Maven cha mẹ pom vs mô-đun pom

Dường như có một số cách để cấu trúc các poms cha trong một bản dựng đa hướng và tôi tự hỏi liệu có ai có bất kỳ suy nghĩ nào về những lợi thế / nhược điểm của mỗi cách không.

Phương pháp đơn giản nhất để có một pom cha sẽ là đặt nó vào gốc của một dự án tức là

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

trong đó pom.xml là cả dự án mẹ cũng như mô tả các mô-đun -core -api và -app

Phương pháp tiếp theo là tách cha mẹ thành thư mục con riêng của nó như trong

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

Trường hợp pom cha vẫn chứa các mô-đun nhưng chúng là tương đối, ví dụ ../myproject-core

Cuối cùng, có tùy chọn trong đó định nghĩa mô-đun và cha mẹ được phân tách như trong

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

Trong đó pom cha chứa bất kỳ cấu hình "chia sẻ" nào (phụ thuộc quản lý, thuộc tính, v.v.) và myproject / pom.xml chứa danh sách các mô-đun.

Mục đích là có thể mở rộng để xây dựng quy mô lớn, do đó nên có thể mở rộng cho một số lượng lớn các dự án và hiện vật.

Một vài câu hỏi về phần thưởng:

• Đâu là nơi tốt nhất để xác định cấu hình được chia sẻ khác nhau như trong kiểm soát nguồn, thư mục triển khai, plugin chung, v.v. (Tôi giả sử là cha mẹ nhưng tôi thường bị cắn bởi điều này và họ đã kết thúc trong mỗi dự án thay vì một phổ biến).
• Làm thế nào để plugin phát hành maven, hudson và nexus đối phó với cách bạn thiết lập nhiều dự án của mình (có thể là một câu hỏi lớn, sẽ có nhiều hơn nếu có ai bị phát hiện khi xây dựng nhiều dự án)?

Chỉnh sửa: Mỗi dự án phụ có pom.xml riêng, tôi đã bỏ nó để giữ cho nó ngắn gọn.

Theo tôi, để trả lời câu hỏi này, bạn cần suy nghĩ về mặt vòng đời dự án và kiểm soát phiên bản. Nói cách khác, pom cha có vòng đời riêng của nó tức là nó có thể được phát hành riêng biệt với các mô-đun khác hay không?

Nếu câu trả lời là có (và đây là trường hợp của hầu hết các dự án đã được đề cập trong câu hỏi hoặc trong các bình luận), thì pom cha mẹ cần mô-đun của riêng mình từ một VCS và từ quan điểm của Maven và bạn sẽ kết thúc với một cái gì đó như thế này ở cấp độ VCS:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

Điều này làm cho việc kiểm tra hơi đau đớn và một cách phổ biến để đối phó với điều đó là sử dụng svn:externals. Ví dụ: thêm một trunksthư mục:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

Với định nghĩa bên ngoài sau:

parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk

Việc thanh toán trunkssau đó sẽ dẫn đến cấu trúc cục bộ sau (mẫu số 2):

root/
  parent-pom/
    pom.xml
  projectA/

Tùy chọn, bạn thậm chí có thể thêm một pom.xmltrong trunksthư mục:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

Đây pom.xmllà một loại pom "giả": nó không bao giờ được phát hành, nó không chứa phiên bản thật vì tệp này không bao giờ được phát hành, nó chỉ chứa một danh sách các mô-đun. Với tệp này, thanh toán sẽ dẫn đến cấu trúc này (mẫu số 3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

"Hack" này cho phép khởi chạy một lò phản ứng xây dựng từ gốc sau khi thanh toán và làm cho mọi thứ trở nên tiện dụng hơn. Trên thực tế, đây là cách tôi muốn thiết lập các dự án maven và kho lưu trữ VCS cho các bản dựng lớn : nó chỉ hoạt động, nó có quy mô tốt, nó cung cấp tất cả sự linh hoạt mà bạn có thể cần.

Nếu câu trả lời là không (quay lại câu hỏi ban đầu), thì tôi nghĩ bạn có thể sống với mẫu số 1 (làm điều đơn giản nhất có thể có thể làm việc).

Bây giờ, về các câu hỏi tiền thưởng:

• Đâu là nơi tốt nhất để xác định cấu hình được chia sẻ khác nhau như trong kiểm soát nguồn, thư mục triển khai, plugin chung, v.v. (Tôi giả sử là cha mẹ nhưng tôi thường bị cắn bởi điều này và họ đã kết thúc trong mỗi dự án thay vì một phổ biến).

Thành thật mà nói, tôi không biết làm thế nào để không đưa ra câu trả lời chung chung ở đây (như "sử dụng mức độ mà bạn nghĩ nó có ý nghĩa để tương tác mọi thứ"). Và dù sao, poms con luôn có thể ghi đè cài đặt được kế thừa.

• Làm thế nào để plugin phát hành maven, hudson và nexus đối phó với cách bạn thiết lập nhiều dự án của mình (có thể là một câu hỏi lớn, sẽ có nhiều hơn nếu có ai bị phát hiện khi xây dựng nhiều dự án)?

Các thiết lập tôi sử dụng hoạt động tốt, không có gì đặc biệt để đề cập.

Trên thực tế, tôi tự hỏi làm thế nào maven-phát hành-plugin xử lý với mẫu số 1 (đặc biệt là với <parent>phần vì bạn không thể có phụ thuộc SNAPSHOT tại thời điểm phát hành). Điều này nghe có vẻ như là một vấn đề về gà hoặc trứng nhưng tôi không thể nhớ nếu nó hoạt động và quá lười để kiểm tra nó.

Từ kinh nghiệm của tôi và thực tiễn tốt nhất của Maven, có hai loại "cha mẹ"

• "công ty" pom cha - pom này chứa thông tin và cấu hình cụ thể của công ty bạn kế thừa mọi pom và không cần phải sao chép. Những thông tin này là:

  • kho lưu trữ
  • bộ phận quản lý phân phối
  • cấu hình plugin phổ biến (như phiên bản đích và nguồn của trình biên dịch maven-trình biên dịch)
  • tổ chức, nhà phát triển, v.v.

  Chuẩn bị pom cha mẹ này cần phải được thực hiện một cách thận trọng, bởi vì tất cả các pom công ty của bạn sẽ được thừa hưởng từ nó, vì vậy pom này phải trưởng thành và ổn định (phát hành phiên bản pom cha mẹ không nên ảnh hưởng đến việc phát hành tất cả các dự án công ty của bạn!)

• loại cha mẹ thứ hai là cha mẹ đa mô hình. Tôi thích giải pháp đầu tiên của bạn - đây là quy ước maven mặc định cho các dự án đa mô-đun, thường đại diện cho cấu trúc mã VCS

Mục đích là có thể mở rộng để xây dựng quy mô lớn, do đó nên có thể mở rộng cho một số lượng lớn các dự án và hiện vật.

Mutliprojects có cấu trúc của cây - vì vậy bạn không bị tụt xuống một cấp độ của cha mẹ. Cố gắng tìm một cấu trúc dự án phù hợp cho nhu cầu của bạn - một ví dụ điển hình là làm thế nào để loại bỏ các dự án đột biến

distibution/
documentation/
myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml
pom.xml

Một vài câu hỏi về phần thưởng:

• Đâu là nơi tốt nhất để xác định cấu hình được chia sẻ khác nhau như trong kiểm soát nguồn, thư mục triển khai, plugin chung, v.v. (Tôi giả sử là cha mẹ nhưng tôi thường bị cắn bởi điều này và họ đã kết thúc trong mỗi dự án thay vì một phổ biến).

Cấu hình này phải được phân chia một cách khôn ngoan thành pom cha mẹ "công ty" và pom (s) cha mẹ dự án. Những điều liên quan đến tất cả các dự án của bạn thuộc về "công ty" cha mẹ và điều này liên quan đến dự án hiện tại đi đến dự án một.

• Làm thế nào để plugin phát hành maven, hudson và nexus đối phó với cách bạn thiết lập nhiều dự án của mình (có thể là một câu hỏi lớn, sẽ có nhiều hơn nếu có ai bị phát hiện khi xây dựng nhiều dự án)?

Công ty mẹ pom phải được phát hành đầu tiên. Đối với đa quy tắc tiêu chuẩn áp dụng. Máy chủ CI cần biết tất cả để xây dựng dự án một cách chính xác.

1. Một cha mẹ độc lập là cách thực hành tốt nhất để chia sẻ cấu hình và các tùy chọn trên các thành phần khác. Apache có một dự án pom cha mẹ để chia sẻ các thông báo pháp lý và một số tùy chọn đóng gói phổ biến.

2. Nếu dự án cấp cao nhất của bạn có công việc thực sự trong đó, chẳng hạn như tổng hợp javadoc hoặc đóng gói một bản phát hành, thì bạn sẽ có xung đột giữa các cài đặt cần thiết để thực hiện công việc đó và các cài đặt bạn muốn chia sẻ qua cha mẹ. Một dự án chỉ dành cho phụ huynh tránh điều đó.

3. Một mô hình phổ biến (bỏ qua số 1 vào lúc này) là các dự án có mã sử dụng một dự án mẹ làm cha mẹ của chúng và để nó sử dụng cấp cao nhất làm cha mẹ. Điều này cho phép mọi thứ cốt lõi được chia sẻ cho tất cả mọi người, nhưng tránh được vấn đề được mô tả trong # 2.

4. Plugin trang web sẽ rất bối rối nếu cấu trúc cha không giống với cấu trúc thư mục. Nếu bạn muốn xây dựng một trang web tổng hợp, bạn sẽ cần phải thực hiện một số vấn đề để giải quyết vấn đề này.

5. Apache CXF là một ví dụ mẫu trong # 2.

Có một chút bắt với cách tiếp cận thứ ba. Vì các POM tổng hợp (myproject / pom.xml) thường không có cha mẹ, chúng không chia sẻ cấu hình. Điều đó có nghĩa là tất cả các POM tổng hợp đó sẽ chỉ có các kho lưu trữ mặc định.

Đó không phải là vấn đề nếu bạn chỉ sử dụng plugin từ Trung tâm, tuy nhiên, điều này sẽ thất bại nếu bạn chạy plugin bằng cách sử dụng plugin: định dạng mục tiêu từ kho lưu trữ nội bộ của bạn. Ví dụ: bạn có thể có foo-maven-pluginnhómId org.examplecung cấp mục tiêu generate-foo. Nếu bạn cố chạy nó từ gốc dự án bằng lệnh like mvn org.example:foo-maven-plugin:generate-foo, nó sẽ không chạy được trên các mô đun tổng hợp (xem ghi chú tương thích ).

Một số giải pháp có thể:

1. Triển khai plugin vào Maven Central (không phải lúc nào cũng có thể).
2. Chỉ định phần kho lưu trữ trong tất cả các POM tổng hợp của bạn (phá vỡ nguyên tắc DRY ).
3. Có kho lưu trữ nội bộ này được định cấu hình trong tệp settings.xml (trong cài đặt cục bộ tại ~ / .m2 / settings.xml hoặc trong cài đặt toàn cục tại /conf/sinstall.xml). Sẽ khiến việc xây dựng thất bại nếu không có các tệp cài đặt đó (có thể ổn đối với các dự án lớn trong nhà không bao giờ được xây dựng bên ngoài công ty).
4. Sử dụng cha mẹ với các cài đặt kho lưu trữ trong các POM tổng hợp của bạn (có thể có quá nhiều POM gốc không?).