Problemy z maven zbudowany OSGi w tym zależności

Question

Zaczynam obecnie z adnotacjami OSGi, iPOJO i iPOJO i próbuję zbudować prosty komponent do wdrożenia w Felix. Niestety, natknąłem się na różne problemy, których rozwiązywanie zajmuje mi wiele godzin lub których nie mogę rozwiązać nawet po marnowaniu godzin, takich jak:

Chcę użyć istniejącej biblioteki w moim pakiecie OSGi, który budujemy przy użyciu Mavena. Biblioteka nie jest obecnie "OSGI-ified" i nie planujemy tego zrobić w perspektywie średnioterminowej. Z tego powodu, że chcesz dołączyć tę bibliotekę i wszystkie jego zależności w wiązce, przy użyciu ...:

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

Co mam teraz, jest następujący plik pom.xml dla komponentu 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> 

plik jar wiązka jest zbudowany bez żadnych problemów, ale po wdrożeniu i uruchomieniu pakiet Apache Felix, pojawia się następujący błąd:

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) 

mam ustawić poziom dziennika do najwyższych Verbos niestety nie ma więcej informacji. Po usunięciu mylibrary pakiet jest uruchamiany bez problemów.

Wszelkie sugestie doceniane!

Answer 1

Najwyraźniej biblioteka używa com.sun.jdmk.comm, która nie jest odsłonięta z pakietu ramowego. Można sprawdzić this question jeśli naprawdę potrzebujesz, lub wykluczenia go z importu poprzez wprowadzenie dodatkowej instrukcji,

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

Answer 2

Jeśli kończy się z ogromnym liście wykluczyć, powinieneś wziąć to jako wskazówkę, że coś nie pasuje do twojego procesu budowania i pakietu.

Jeśli chodzi o mnie, pierwszą rzeczą, którą zrobię, jest otwarcie pakietu i sprawdzenie, jakie klasy zawiera i jakie pakiety eksportuje. Podejrzewam, że masz dość masywny pakiet, co oznacza, że ​​zależności twojego pakietu będą dość rozległe. Oznacza to, że tracisz wiele zalet modułowych OSGi i może to powodować wiele praktycznych problemów.

Za każdym razem, gdy deklarujesz pakiet jako opcjonalny, mówisz "Cieszę się, że akceptuję ClassDefNotFoundExceptions dla klas w tym pakiecie". Jeśli chodzi o twój kod, możesz prawdopodobnie wiedzieć, czy pakiet jest rzeczywiście opcjonalny, ale dość trudne jest odgadnięcie, które pakiety używane przez stronę trzecią są opcjonalne. To oczywiście sprawia, że ​​konfekcjonowane słoiki są wygodniejsze, ale zdaję sobie sprawę, że to niewiele pomoże. :)

To, co robisz, umieszczając bibliotekę stron trzecich, jest pakietowaniem, ale w sposób, który nie jest już do ponownego użycia. (Inna różnica polega na tym, że udostępni to program ładujący klasy z pakietem osadzania, co może sprawić, że wszystko będzie działać lepiej, jeśli na przykład trzecia biblioteka spróbuje załadować twoje sklasyfikowane przez odbicie.) Ponieważ masz problemy z zależnościami Byłbym skłonny podjąć decyzję o dodaniu kroku kompilacji, który otacza słoik stron trzecich, dzięki czemu można wyraźnie zobaczyć, jakie klasy i zależności dotyczą kodu, a które do tego dodatkowego słoika.

Inną rzeczą, na którą patrzę, jest twoja klauzula eksportowa = *. Spowoduje to wyeksportowanie każdego pakietu w ścieżce klas, co oznacza, że ​​wszystkie te pakiety zostaną wbudowane w twój słoik. Dostajesz też cały ich import pakietów. Twój słaby pakiet staje się całą aplikacją, a nie szczupłym modułem OSGi, na który liczyłeś. Powinieneś ograniczyć swój wywóz do absolutnego minimum (chcesz zachować prywatne intencje, a na pewno nie chcesz dzielić się cudzymi wnętrznościami).

-

Enterprise OSGi w działaniu: http://www.manning.com/cummins