2012-07-07 28 views
17

Có hai phương pháp chính khi phát triển ứng dụng OSGi với Maven: POM-first và MANIFEST trước.Tôi có nên sử dụng POM trước hoặc MANIFEST trước khi phát triển ứng dụng OSGi với Maven không?

Tôi đang tìm câu trả lời dưới dạng bảng hiển thị ưu và nhược điểm của từng phương pháp.

Để cụ thể hơn, tôi cũng muốn biết làm thế nào nó liên quan đến:

  • đáo hạn của bộ công cụ
  • Vendor độc lập
  • dễ dàng phát triển (trong đó bao gồm việc tìm kiếm những người có thể làm phát triển trên các dụng cụ)
  • Compatibility
  • Tránh ClassNotFound
  • Tránh công việc tay chân
+0

"Chúng tôi chơi cả hai loại nhạc ở đây ... Quốc gia * và * Phương Tây". Nói cách khác, bạn đã đặt ra một sự phân đôi sai, và có nhiều lựa chọn hơn "POM đầu tiên" và "MANIFEST đầu tiên". Cụ thể là bạn đã xem xét IDE Bndtools? –

+1

Câu hỏi này rõ ràng nằm trong danh mục tranh luận và tranh luận và nên được đóng lại. – Robin

+0

Tôi chỉ biết hai phương pháp để giải quyết vấn đề này: maven-bundle-plugin và tycho-maven-plugin. Tôi đang ở giữa chuyển đổi plugin Eclipse của tôi để sử dụng Tycho ngay bây giờ vì vậy tôi có một lý do "thực sự" để sử dụng nó. Và ứng dụng OSGi tham chiếu của tôi không phải là Eclipse dựa trên việc sử dụng Felix. Cho đến nay tôi thấy nhiều nhược điểm hơn với Tycho khi tôi sử dụng nó. –

Trả lời

17

hiện này Tại là những gì tôi có thể đưa ra

POM-Đầu tiên Ưu điểm (sử dụng maven-bó-plugin)

  • thúc đẩy hiện Maven kỹ năng, kho và dụng cụ. Có thể dễ dàng tìm thấy những người biết cách quản lý pom.xml hơn là MANIFEST.MF cùng với pom.xml
  • Hầu hết thông tin trong MANIFEST.MF có thể lấy từ chính tệp pom.xml.
  • Có thể làm việc với các IDE khác không chỉ dựa trên Eclipse.
  • Ít xâm lấn, chỉ cần thêm đơn plugin và thay đổi kiểu đóng gói để "bó"

POM-Đầu Nhược điểm

  • ClassNotFoundException nhiều khả năng xảy ra khi chạy. Tuy nhiên, điều này có thể được giảm thiểu bằng cách sử dụng pax-thi (mặc dù nó là rất phức tạp để thiết lập).
  • Vẫn cần hiểu cách MANIFEST được thiết lập để đảm bảo phần tử cấu hình instructions được đặt chính xác.

Ưu MANIFEST-đầu tiên (sử dụng Tycho-maven-plugin)

  • Có vẻ là cách tiếp cận đề nghị, hoặc ít nhất là nói về như phương pháp được khuyến khích, nhưng tôi có thể không thực sự nhìn thấy tại sao nó có lợi ích đáng kể. (Do đó tại sao câu hỏi này lại được hỏi).
  • Tốt để phát triển các plugin Eclipse và tích hợp tốt với PDE
  • Cung cấp công cụ để thử nghiệm do đó cho phép ClassNotFoundException xuất hiện trong khi thử nghiệm JUnit thay vì thời gian chạy.

MANIFEST đầu tiên Nhược điểm

  • Dường như chỉ hoạt động tốt trên IDE dựa Eclipse. Bạn không cần phải sử dụng Eclipse, nhưng không có PDE bạn muốn?
  • Vi phạm nguyên tắc DRY vì tôi phải đặt tên và phiên bản từ POM và MANIFEST.MF đồng bộ hóa.
  • Cần phải đặt tên cho mọi thứ trong một thời trang cụ thể
  • Bạn không thể trộn lẫn, có nghĩa là cài đặt đa dự án Maven hiện tại có thể không chỉ tack vào sự hỗ trợ OSGi
  • Rất nhiều cấu hình hơn so với maven-bó-plugin là cần thiết để có được ít cảnh báo: http://wiki.eclipse.org/Tycho/Reference_Card#Examplary_parent_POM
  • Phải làm cho các trường hợp thử nghiệm là một dự án riêng biệt. Nó sẽ không chạy khi được xây dựng trong src/test/java.
  • Dường như nó sẽ chỉ kiểm tra các lớp học được tiếp xúc, nói cách khác là các lớp trong ".internal". không thể kiểm tra được.

Nếu tôi được hỏi cho một đề nghị cho doanh nghiệp được sử dụng Maven đã và muốn chuyển sang OSGi sau đó nó sẽ là POM đầu tiên

Nếu tôi được hỏi cho một đề nghị cho những người là làm phát triển plugin Eclipse, sau đó nó là Tệp kê khai đầu tiên - với tycho

+0

Có cách nào để tạo phụ thuộc POM từ MANIFEST.MF không? –

0

MANIFEST trước hết không khóa bạn vào Eclipse (mặc dù tôi sẽ ngạc nhiên nếu nhiều hơn một thiểu số nhỏ sẽ sử dụng bất kỳ thứ gì khác). MANIFEST là tệp đếm, và cần phải được thêm vào một cái bình, bất kể bạn làm như thế nào.

Mặt khác, POM đầu tiên khóa hoàn toàn bạn vào Maven, bạn mất lợi thế là một gói OSGi là một lọ thông thường bạn có thể thực hiện theo bất kỳ cách nào bạn muốn.

Tôi đã thử cả hai, tôi thực sự thích MANIFEST trước. Tệp MANIFEST là một tệp thực sự quan trọng, tôi thích tạo tệp đó hơn là tạo một tệp tạo tệp đó. Nếu có điều gì đó lạ xảy ra, (và nó sẽ ở một thời điểm nào đó) tệp MANIFEST là tệp đầu tiên cần kiểm tra, sẽ dễ dàng hơn nếu đó là tệp của riêng bạn. Bên cạnh đó, bạn sẽ phải quen thuộc với nó anyway.

Vì vậy, nếu Maven là alpha và omega của bạn, POM đầu tiên sẽ phù hợp với bạn nhất, nhưng bạn vẫn sẽ cần phải có sự hiểu biết sâu sắc về tệp MANIFEST.

+3

Tôi không thể không đồng ý với vị trí này nhiều hơn, tốt hơn hết là tạo MANIFEST hơn là giữ nguyên nó theo cách thủ công vì nó chứa quá nhiều thông tin trùng lặp (ví dụ: các gói đã nhập). Lập luận về nó rất quan trọng là không có thật, bởi vì các tệp '.class' trong ứng dụng của bạn cũng rất quan trọng, và bạn sẽ không mơ ước viết chúng bằng tay. –

+0

Thú vị. Tôi không chống lại việc tạo ra một tệp MANIFEST, tôi chỉ nói rằng bạn cần phải làm quen với nó. Nhiều vấn đề hiển thị tại stackoverflow có thể được giải quyết hoặc phân tích bằng cách xem tệp MANIFEST. Tôi chưa từng thấy ai yêu cầu bytecode. Hai người có một vai trò khác nhau. Dù sao, tôi mong được câu trả lời của bạn. –

+1

Có .. bạn phải biết Manifest của bạn trông như thế nào. Khi bạn tạo tệp kê khai, bạn vẫn phải kiểm tra xem nó có hoạt động tốt hay không nhưng bạn có ít công việc thủ công hơn rất nhiều. Vì vậy, tôi cũng hỗ trợ thay vì tạo ra các Manifest. –

5

Tôi nghĩ bạn nên chọn theo trường hợp sử dụng. Đối với các dự án OSGi phía máy chủ, tôi ưu tiên kiểu pom đầu tiên. Nó độc đáo phù hợp với xây dựng maven và ít hơn nhiều lỗi dễ bị hơn so với Manifest đầu tiên. Trong thực tế bnd mà là đằng sau các plugin bó maven được Manifest quyền cho hầu hết các trường hợp mà không cần bất kỳ cấu hình bổ sung. Bí quyết là sử dụng một số quy tắc đặt tên. Ví dụ: nếu bạn đặt tên gói nội bộ hoặc nội bộ sẽ không được xuất. Sử dụng kiểu này, bạn không thể sử dụng phối cảnh của trình cắm thêm Eclipse (ít nhất là không có bndtools mà tôi không thích) nhưng tôi chưa bỏ lỡ quan điểm này. Tôi là một nhà phát triển trong các dự án Apache Karaf, CXF và Camel, nơi chúng tôi sử dụng phong cách này và nó hoạt động rất tốt. Đặc biệt đối với CXF và Camel, điều tuyệt vời là chúng tôi có thể hỗ trợ triển khai OSGi và không OSGi với cùng một công cụ và công cụ.

Đối với các ứng dụng RCP Eclipse Tệp kê khai đầu tiên là cách để đi khi bạn cần phối cảnh plugin và các công cụ IDE của Eclipse. Nếu bạn muốn kết hợp với maven thì tycho có lẽ là con đường để đi.

+0

Tôi thấy chính xác điều tương tự là đúng. Tôi cũng đã phát triển theo cả hai phương pháp và tiếp tục làm như vậy khi thích hợp. Đây là lý do tại sao chúng tôi sử dụng Tycho cho mã RCP của chúng tôi, vì vậy chúng tôi vẫn có thể sử dụng maven nhưng nó cho phép phát triển dễ dàng hơn trong Eclipse cho RCP bằng cách làm cho vua biểu lộ. – Robin

+0

Cảm ơn, kết luận của bạn phù hợp với tôi, thực sự kết luận của bạn là những gì tôi nghĩ trước khi tôi thậm chí còn viết câu hỏi. Lý do cho câu hỏi là liệt kê các ưu và nhược điểm của mỗi trường hợp trong trường hợp tôi phải biện minh cho lý do tại sao tôi chọn cái kia. –

Các vấn đề liên quan