Проблемы с Maven, встроенным OSGi, включая зависимости - PullRequest
9 голосов
/ 15 февраля 2012

В настоящее время я начинаю с аннотаций OSGi, iPOJO и iPOJO и пытаюсь создать простой компонент для развертывания в Felix. К сожалению, я спотыкаюсь о различных проблемах, на решение которых у меня уходят часы или которые я не могу решить даже после потери времени, например:

Я хочу использовать существующую библиотеку в моем комплекте OSGi, который мы создаем с помощью Maven. В настоящее время библиотека не является OSGI-ified, и мы не планируем делать это в среднесрочной перспективе. Поэтому я хочу включить эту библиотеку и все ее зависимости в комплект, используя…:

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

Теперь у меня есть следующий файл pom.xml для компонента 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>

Файл JAR комплекта создается без проблем, но при развертывании и запуске комплекта на Apache Felix я получаю следующую ошибку:

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)

Я установил в журнале самый высокий уровень детализации, к сожалению, больше информации нет. Когда я удаляю mylibrary, комплект запускается без проблем.

Любые предложения приветствуются!

Ответы [ 2 ]

10 голосов
/ 15 февраля 2012

Судя по всему, библиотека использует com.sun.jdmk.comm, который не предоставляется из пакета фреймворка. Вы можете проверить этот вопрос , если он вам действительно нужен, или исключить его из импорта, введя дополнительную инструкцию

<Import-Package>!com.sun.jdmk.comm, *</Import-Package>
4 голосов
/ 15 февраля 2012

Если у вас получится огромный список исключений, вы, вероятно, должны принять это как признак того, что что-то не так с вашим процессом сборки и комплектом.

Если бы это был я, первое, что я сделал бы, это взломал ваш пакет и посмотрел, какие классы он включает, и какие пакеты он экспортирует. Я подозреваю, что у вас довольно массивный пакет, а это значит, что зависимости вашего пакета будут довольно обширными. Это означает, что вы теряете много преимуществ модульности OSGi, и это может вызвать много практических проблем.

Каждый раз, когда вы объявляете пакет необязательным, вы говорите: «Я рад принять исключения ClassDefNotFoundException для классов в этом пакете». Для вашего кода вы, вероятно, можете знать, является ли пакет действительно необязательным, но довольно сложно догадаться, какие пакеты, используемые третьей стороной, являются необязательными. Это, конечно, то, почему предварительно упакованные банки более удобны, но я понимаю, что это не очень поможет вам. :)

То, что вы делаете, встраивая стороннюю библиотеку, объединяет ее, но не так, чтобы ее можно было повторно использовать. (Другое отличие состоит в том, что он будет использовать загрузчик классов совместно с пакетом встраивания, что может заставить вещи работать намного лучше, если, например, сторонняя библиотека попытается загрузить вашу классификацию отражением.) Так как у вас возникают проблемы с зависимостями Я бы предпочел добавить шаг сборки, который обернет сторонний jar-файл, чтобы вы могли четко видеть, какие классы и зависимости относятся к вашему коду, а какие к этому дополнительному jar-файлу.

Другая вещь, на которую я бы посмотрел, - это ваш экспортный пакет = * предложение. Это будет экспортировать каждый пакет в вашем classpath, что означает, что все эти пакеты будут встроены в ваш jar. И вы получаете весь их пакет импорта тоже. Ваш плохой комплект становится целым приложением, а не модулем OSGi, на который вы надеялись. Вы должны ограничить свой экспорт до минимума (вы хотите, чтобы ваши внутренности были приватными, и вы определенно не хотите делиться чужими внутренностями).

-

Enterprise OSGi в действии: http://www.manning.com/cummins

...