Felix maven-bundle-plugin 传递依赖问题
我是 OSGI 新手,正在尝试部署我的第一个应用程序。我的 pom.xml 中有一个 spring 依赖项。在部署时,我意识到 Felix 运行时需要所有传递依赖项才能正确安装捆绑包。从那时起,我就一直在努力解决这个问题。我尝试过嵌入式依赖和嵌入式传递选项,但没有运气。这是我的 pom。
<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>com.test</groupId>
<artifactId>taxonomydaobundle</artifactId>
<version>1.0.0</version>
<packaging>bundle</packaging>
<name>Taxonomy Dao Bundle</name>
<url>http://maven.apache.org</url>
<repositories>
<repository>
<id>fusesource</id>
<url>http://repo.fusesource.com/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
<repository>
<id>apache-public</id>
<url>https://repository.apache.org/content/groups/public/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>taxonomymodelbundle</artifactId>
<version>1.0.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.5</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.0.1</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>com.test.taxonomy.api.*;version=1.0.0
</Export-Package>
<Import-Package>com.test.taxonomy.message.*;version=1.0.0,
*
</Import-Package>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
最初,我尝试 mvn install 但它只包含直接依赖项,而不包含传递依赖项。阅读 felix maven 插件文档后,我尝试了 mvn org.apache.felix:maven-bundle-plugin:bundleall。但是,执行失败,因为它无法从其使用的存储库获取所需的 jar 文件。查看日志,我可以看到它指的是 http://repo1.maven.org/maven2没有所需版本的存储库。例如,这个来自 hessian 3.1.3 等。
[INFO] Unable to find resource 'hessian:hessian:pom:3.1.3' in repository central
(http://repo1.maven.org/maven2)
如果有人可以分享他们在这方面的经验,我将不胜感激。
-谢谢
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
使用 -X 选项运行 Maven,这将使捆绑插件打印它认为的依赖关系树。
不幸的是,您无法调整项目的 pom depdnencyManagement 部分以删除“可选”依赖关系,因为 maven-bundle-plugin 忽略了这一点。
根据 FELIX-954 它几乎将访问所有可选依赖项。
我能提供的唯一建议是找到那些可选的工件并确保 Maven 可以解决它们。
Run Maven with the -X option, which will get the bundle plugin to print what it thinks the dependency tree is
Unfortunately you can not tweak your project's pom depdnencyManagement section to remove "optional" dependencies because maven-bundle-plugin is ignoring this.
According to FELIX-954 its pretty much going to visit all optional dependencies.
The only advice I can offer is to find those optional artifacts and make sure Maven can resolve them.
在 OSGi 环境中,部署所需库的常见方法是将它们部署为自己的包。如果库未启用 OSGi,则嵌入库是最常用的选项(据我所知),并且对于 OSGi 容器中的其他包无关紧要。
因此,如果您的捆绑包依赖于其他库,您应该首先查看这些库是否启用了 OSGi,并将它们作为自己的捆绑包安装在 OSGi 容器中。
如果您使用未启用 OSGi 的库,您可以查看一些提供启用 OSGi 的“包装”这些库的捆绑包的地方,例如
春天是否启用了 OSGi - 您应该可以自行部署这些包。我还建议查看 Spring 动态模块 (文档)。如果您构建支持 Spring 的捆绑包,您还可以从已经使用这些捆绑包准备好的 OSGi 容器开始。我在 FUSE ESB (免费(基于 apache servicemix)OSGi 容器(以及更多),具有商业支持)。
因此,虽然我没有回答您的具体问题,但我分享了一些我的经验,希望对您有所帮助。祝你好运!
In the OSGi environment the common way to deploy required libraries is to deploy them as own bundles. Embedding a library is an option that is most used (as I know) if the library is not OSGi enabled and does not matter for other bundles in the OSGi container.
So, if your bundle depends on other libraries you should first have a look, if these libraries are OSGi enbabled and install them as own bundles in the OSGi container.
If you use a library that is not OSGi enabled you can have a look to some places that offer OSGi enabled "wrapped" bundles of these libraries, e.g.
Spring is OSGi enabled - it should be possible for you to deploy these bundles on their own. I also recommend to have a look at Spring Dynamic Modules (documentation). If you build Spring enabled bundles you can also start with an OSGi Container that's already prepared with these bundles. I made good expirience with FUSE ESB (which is free (based on apache servicemix) OSGi container (and more) with commercial support).
So although I did not answer your concrete questions I shared some of my experience and hope that will help you. Good luck!
maven-bundle-plugin 的传递依赖项管理中存在一个错误 使其查找可选依赖项(其中一些可能不存在)。我怀疑这就是当它试图引入粗麻布时发生的情况。
我会赞同 K. Claszen 的想法,即在 springsource 或 fusionsource 上查找捆绑包的版本,但如果找不到捆绑包,则 maven-bundle-plugin 会提供 bundleall 目标(在目标部分中进行了描述)。此目标将导致捆绑包插件为应用程序的所有传递依赖项创建捆绑包。然后,您可以使用在 springsource/fusesource 中找不到的那些。完成此操作后,您无需将 jar 嵌入到您的捆绑包中,这将使它们也可供其他捆绑包使用。
您可能会遇到的一个警告是需要部署捆绑包,以便在其依赖项之一之前不部署任何捆绑包。过去,我使用 Eclipse Virgo 服务器来解决这个问题。它允许您将所有捆绑包放入存储库中,并让服务器确定部署顺序。
There is a bug in the transitive dependencies management for the maven-bundle-plugin that causes it to look up optional dependencies (some of which may not exist). I suspect this is what is happening when it tries to pull in hessian.
I'll second K. Claszen's idea of looking for versions of your bundles on springsource or fusesource, but if there are bundles you cannot find, the maven-bundle-plugin provides a bundleall goal (it's described in the goals section). This goal will cause the bundle plugin to create bundles for all of the transitive dependencies of your application. You can then use the ones you couldn't find in springsource/fusesource. Once you've done this, you won't need to embed the jars into your bundle, which will make them available to other bundles as well.
One caveat that you may run into is the need to deploy the bundles such that no bundle is deployed before one of its dependencies. In the past, I have used the Eclipse Virgo server to get around this. It allows you to place all of your bundles in a repository and have the server determine the deployment order.