【问题标题】:Problems with maven built OSGi including dependenciesmaven 构建的 OSGi 包括依赖项的问题
【发布时间】:2012-03-06 18:01:22
【问题描述】:

我目前从 OSGi、iPOJO 和 iPOJO Annotations 开始,并尝试构建一个简单的组件以部署在 Felix 中。不幸的是,我遇到了各种各样的问题,这些问题需要我几个小时才能解决,或者浪费了几个小时后我什至无法解决,如下所示:

我想使用我们使用 Maven 构建的 OSGi 包中的现有库。该库目前不是“OSGI-ified”,我们不打算在中期这样做。因此,我想在包中包含这个库及其所有依赖项,使用...:

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

我现在拥有的是以下用于 OSGi 组件的 pom.xml 文件:

<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>

bundle jar 文件构建没有任何问题,但是在 Apache Felix 上部署和启动 bundle 时,我收到以下错误:

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 时,bundle 启动时没有问题。

任何建议表示赞赏!

【问题讨论】:

    标签: maven osgi apache-felix


    【解决方案1】:

    显然,该库使用com.sun.jdmk.comm,它没有从框架包中公开。如果你真的需要它,你可以检查this question,或者通过添加额外的指令将它从导入中排除,

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

    【讨论】:

    • 谢谢,总的来说这是一个很好的指针。但是,在添加排除后,会弹出更多未解决的依赖项。我现在所做的是将依赖项设置为“可选”:&lt;Import-Package&gt;*;resolution:=optional&lt;/Import-Package&gt; 现在我得到了它按预期工作:)
    • 嗯,很高兴看到你的问题已经解决了,但是 resolution:=optional 应该只在非常痛苦的时候使用:你这样做破坏了 OSGi 解析机制,因为你标记了 every 导入为可选。我更喜欢!com.sun.*,* 之类的东西。
    • 好的,以后我会记住这一点的,谢谢你的警告。但在上面的例子中,问题是,新的缺失的未解决的依赖项正在为各种不同的命名空间弹出,形成一个巨大的排除列表。
    • @qqilihq 您建议的解决方案的问题是所有包导入现在都标记为可选。如果您要这样做,为什么还要费心使用 OSGi?
    • @Neil Bartlett 你是对的,但此时我只是在寻找一个快速(且肮脏)的解决方案。我正在为 OSGi 优化整个项目,但我目前只是进入这个主题,需要我的时间:)。
    【解决方案2】:

    如果您最终得到一个巨大的排除列表,您可能应该将其视为您的构建过程和捆绑包出现问题的迹象。

    如果是我,我要做的第一件事就是打开你的包,看看它包含哪些类,以及它导出的包。我怀疑你有一个相当庞大的包,这意味着你的包的依赖关系将非常广泛。这意味着您失去了 OSGi 的很多模块化优势,并且还会导致很多实际问题。

    任何时候你声明一个包是可选的,你就是在说“我很高兴接受这个包中的类的 ClassDefNotFoundExceptions。”对于您的代码,您可能可以知道一个包是否真的是可选的,但是要猜测第三方使用的哪些包是可选的非常棘手。当然,这就是为什么预先捆绑的罐子更方便的原因,但我意识到这对你没有多大帮助。 :)

    您通过嵌入第三方库所做的是将其捆绑在一起,但以一种不太可重用的方式。 (另一个区别是它将与嵌入包共享一个类加载器,例如,如果第三方库尝试通过反射加载您的类,这可以使事情工作得更好。)因为您遇到了依赖项问题,我倾向于添加一个包装第三方 jar 的构建步骤,这样您就可以清楚地看到哪些类和依赖项与您的代码相关,以及哪些与这个额外的 jar 相关。

    我要看的另一件事是您的 export package=* 子句。这将导出类路径上的每个包,这意味着所有这些包都会内置到您的 jar 中。你也得到了他们所有的包进口。您可怜的包变成了一个完整的应用程序,而不是您希望的精益 OSGi 模块。你应该将你的出口限制在最低限度(你想让你的内脏保密,而且你绝对不想分享其他人的内脏)。

    --

    企业 OSGi 实战:http://www.manning.com/cummins

    【讨论】:

    • 感谢您的澄清。我已经将Export-Package 缩小到基本范围。我不完全理解的是您的建议“[...] 添加一个包装第三方 jar 的构建步骤,这样您就可以清楚地看到哪些类和依赖项与您的代码相关,以及哪些与这个额外的 jar 相关。 " ——你能详细说明一下吗?
    • 有几种方法可以做到这一点,但大多数使用的机制与 maven bundle 插件在幕后使用的机制相同,bnd。您可以将 bnd 作为命令行工具下载,然后只需调用“bnd wrap [yourjar]”,并使用可选的 bnd 文件来优化包名称、导入和导出等内容。或者,您可以使用 maven 来执行此操作(google 'maven bundle wrap goal')。这些都应该很快给你一个带有 OSGi 元数据的 jar 版本。然后你可以看看里面,确认你只是从 jar 本身中拖入类,并检查包导入是否合理。
    • Holly,抱歉回复晚了,感谢您的提示。非常感谢!
    猜你喜欢
    • 2014-03-12
    • 1970-01-01
    • 1970-01-01
    • 2017-06-05
    • 2023-03-24
    • 2013-01-12
    • 1970-01-01
    • 2017-09-10
    • 1970-01-01
    相关资源
    最近更新 更多