2012-02-15 32 views
7

tôi đang bắt đầu với OSGi, iPOJO và iPOJO Chú thích và cố gắng xây dựng một thành phần đơn giản để được triển khai trong Felix. Thật không may, tôi đang vấp phải nhiều vấn đề khác nhau khiến tôi mất nhiều giờ để giải quyết hoặc thậm chí tôi không thể giải quyết sau khi lãng phí giờ, như sau:Vấn đề với maven xây dựng OSGi bao gồm cả phụ thuộc

Tôi muốn sử dụng thư viện hiện có trong gói OSGi mà chúng tôi xây dựng bằng Maven. Thư viện hiện không phải là "OSGI-ified" và chúng tôi không dự định làm như vậy trong trung hạn. Do đó, tôi muốn bao gồm thư viện này và tất cả các phụ thuộc của nó trong gói, sử dụng ...:

<Embed-Dependency>*</Embed-Dependency> 
<Embed-Transitive>true</Embed-Transitive> 

Những gì tôi có bây giờ, là file pom.xml sau cho thành phần OSGi:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>foo</groupId> 
    <artifactId>samplecomponent</artifactId> 
    <packaging>bundle</packaging> 
    <version>0.0.1-SNAPSHOT</version> 
    <build> 
     <plugins> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-compiler-plugin</artifactId> 
       <version>2.3.2</version> 
       <configuration> 
        <compilerArgument>-Xlint:all</compilerArgument> 
        <showWarnings>true</showWarnings> 
        <source>1.6</source> 
        <target>1.6</target> 
        <compilerArguments> 
         <encoding>UTF-8</encoding> 
        </compilerArguments> 
        <showDeprecation>true</showDeprecation> 
        <verbose>true</verbose> 
        <encoding>UTF-8</encoding> 
       </configuration> 
      </plugin> 
      <plugin> 
       <groupId>org.apache.felix</groupId> 
       <artifactId>maven-bundle-plugin</artifactId> 
       <extensions>true</extensions> 
       <version>2.3.6</version> 
       <configuration> 
        <instructions> 
         <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> 
         <Embed-Dependency>*</Embed-Dependency> 
         <Embed-Transitive>true</Embed-Transitive> 
         <Embed-Directory>lib</Embed-Directory> 
         <Export-Package>*</Export-Package> 
         <_exportcontents>*</_exportcontents> 
        </instructions> 
       </configuration> 
      </plugin> 
      <plugin> 
       <groupId>org.apache.felix</groupId> 
       <artifactId>maven-ipojo-plugin</artifactId> 
       <version>1.6.0</version> 
       <executions> 
        <execution> 
         <goals> 
          <goal>ipojo-bundle</goal> 
         </goals> 
        </execution> 
       </executions> 
      </plugin> 
     </plugins> 
    </build> 
    <dependencies> 
     <dependency> 
      <groupId>org.apache.felix</groupId> 
      <artifactId>org.apache.felix.ipojo.annotations</artifactId> 
      <version>1.8.0</version> 
      <scope>provided</scope> 
     </dependency> 
     <dependency> 
      <groupId>foo</groupId> 
      <artifactId>mylibrary</artifactId> 
      <version>1.2.3</version> 
      <scope>compile</scope> 
     </dependency> 
    </dependencies> 
</project> 

các file jar bó được xây dựng mà không cần bất kỳ vấn đề, nhưng khi triển khai và bắt đầu bó trên Apache Felix, tôi nhận được lỗi sau:

g! install file:/…/samplecomponent-0.0.1-SNAPSHOT.jar 
Bundle ID: 8 
g! start 8 
org.osgi.framework.BundleException: Unresolved constraint in bundle samplecomponent [8]: Unable to resolve 8.0: missing requirement [8.0] osgi.wiring.package; (osgi.wiring.package=com.sun.jdmk.comm) 

tôi đã thiết lập mức độ đăng nhập vào verbos cao nhất ity, không có thêm thông tin không may. Khi tôi loại bỏ mylibrary, gói được bắt đầu mà không có vấn đề gì.

Bất kỳ lời đề nghị đánh giá cao!

Trả lời

9

Rõ ràng, thư viện sử dụng com.sun.jdmk.comm, mà không tiếp xúc từ bó khuôn khổ. Bạn có thể kiểm tra this question nếu bạn thực sự cần nó, hoặc loại trừ nó ra khỏi hàng nhập khẩu bằng cách đặt trong một hướng dẫn bổ sung,

<Import-Package>!com.sun.jdmk.comm, *</Import-Package> 
+3

Cảm ơn bạn, đó là nói chung một con trỏ tốt. Tuy nhiên, sau khi thêm loại trừ, các phụ thuộc chưa được giải quyết khác xuất hiện. Những gì tôi đã làm bây giờ, được đặt phụ thuộc vào "tùy chọn": ' *; độ phân giải: = tùy chọn' Bây giờ tôi đã nhận nó hoạt động như mong đợi :) – qqilihq

+0

Hm, tốt để thấy rằng bạn đang giải quyết vấn đề, nhưng 'độ phân giải: = tùy chọn' chỉ nên được sử dụng trong những thời điểm tuyệt vọng: bạn làm suy yếu cơ chế giải quyết OSGi bằng cách làm điều đó, vì bạn đánh dấu _every_ import là tùy chọn. Tôi thích cái gì đó như '! Com.sun. *, *'. –

+0

Được rồi, tôi sẽ ghi nhớ điều này trong tương lai, cảm ơn bạn đã cảnh báo. Nhưng trong ví dụ trên, vấn đề là, thiếu phụ thuộc mới chưa được giải quyết đã xuất hiện cho các không gian tên khác nhau, tạo ra một danh sách loại trừ rất lớn. – qqilihq

4

Nếu bạn kết thúc với một danh sách loại trừ rất lớn, có lẽ bạn nên coi đó là một dấu hiệu cho thấy một cái gì đó không phù hợp với quy trình xây dựng và gói của bạn.

Nếu là tôi, điều đầu tiên tôi muốn làm là vết nứt mở bó của bạn và có một cái nhìn vào những gì lớp nó bao gồm, và những gói xuất khẩu. Tôi nghi ngờ bạn đã có một gói khá lớn, có nghĩa là các gói phụ thuộc của bạn sẽ khá rộng rãi. Điều này có nghĩa là bạn mất rất nhiều lợi ích về mô đun của OSGi, và nó cũng có thể gây ra nhiều vấn đề thực tế.

Bất cứ lúc nào bạn khai báo một gói là tùy chọn, bạn đang nói 'Tôi rất sẵn lòng chấp nhận ClassDefNotFoundExceptions cho các lớp trong gói này.' Đối với mã của bạn, bạn có thể biết nếu một gói thực sự là tùy chọn, nhưng nó khá khó để đoán những gói nào được sử dụng bởi một bên thứ ba là tùy chọn. Điều này, tất nhiên, là lý do tại sao jars trước khi đóng gói thuận tiện hơn, nhưng tôi nhận ra điều này không giúp ích nhiều cho bạn. :)

Những gì bạn đang làm bằng cách nhúng thư viện của bên thứ ba đang gói gọn thư viện, nhưng theo cách không tái sử dụng được. (Sự khác biệt khác là nó sẽ chia sẻ một trình nạp lớp với gói nhúng, điều này có thể làm cho mọi thứ hoạt động tốt hơn nhiều nếu thư viện của bên thứ ba cố gắng tải lớp của bạn theo sự phản chiếu, chẳng hạn.) Vì bạn đang gặp vấn đề với các phụ thuộc , Tôi muốn có khuynh hướng thêm một bước xây dựng kết thúc tốt hơn bình của bên thứ ba, để bạn có thể thấy rõ ràng những gì lớp và phụ thuộc liên quan đến mã của bạn, và cái nào cho cái bình thêm này.

Một điều khác tôi muốn nhìn vào là gói xuất khẩu của bạn = * khoản. Điều này sẽ xuất khẩu tất cả các gói trên classpath của bạn, có nghĩa là tất cả những gói được xây dựng vào jar của bạn. Và bạn cũng nhận được tất cả các gói nhập khẩu của họ. Gói nghèo của bạn trở thành một ứng dụng hoàn chỉnh, chứ không phải là mô-đun OSGi nạc mà bạn mong đợi. Bạn nên hạn chế xuất khẩu của bạn đến mức tối thiểu (bạn muốn giữ cho các sản phẩm của bạn ở chế độ riêng tư, và bạn chắc chắn không muốn chia sẻ nội bộ của người khác).

-

Enterprise OSGi trong hành động: http://www.manning.com/cummins

+0

Cảm ơn bạn đã làm rõ. Tôi đã thu hẹp 'Xuất-Gói' thành điều cần thiết. Những gì tôi đã không hoàn toàn hiểu được là gợi ý của bạn "[...] thực hiện việc thêm một bước xây dựng kết thúc tốt hơn bình của bên thứ ba, để bạn có thể thấy rõ ràng các lớp và phụ thuộc có liên quan gì đến mã của bạn, và cái nào thêm vào jar này. " - bạn có thể giải thích về điều này không? – qqilihq

+0

Có một số cách để thực hiện việc này, nhưng hầu hết sử dụng cùng một cơ chế mà trình cắm bó maven đang sử dụng dưới bìa, bnd. Bạn có thể tải xuống bnd làm công cụ dòng lệnh và sau đó chỉ cần gọi 'bnd wrap [yourjar]', với tệp bnd tùy chọn để tinh chỉnh những thứ như tên gói, nhập và xuất. Hoặc bạn có thể sử dụng maven để làm điều đó (google 'maven bundle wrap goal'). Cả hai thứ này sẽ cung cấp cho bạn, khá nhanh chóng, một phiên bản jar của bạn với siêu dữ liệu OSGi. Sau đó, bạn có thể nhìn vào bên trong, xác nhận rằng bạn đã chỉ kéo vào các lớp từ chính jar và kiểm tra việc nhập gói là hợp lý. –

+0

Holly, xin lỗi vì đã trả lời muộn và cảm ơn vì gợi ý của bạn. Rất được đánh giá cao! – qqilihq

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