如何使用deploy:deploy-file将OSGi包部署到Maven仓库?

时间:2011-09-13 18:23:27

标签: maven osgi bundle nexus

我有一个OSGi包,是由另一个团队使用Maven构建的。 POM文件将其包装声明为“bundle”并使用Apache Felix插件。

我需要将此工件部署到本地Maven存储库(Nexus),以便我们的内部项目可以使用它。

我已经使用deploy:deploy-file目标将软件包部署到存储库,就像使用标准JAR文件一样,这样可以正常工作。我从包中提取了嵌入的POM并在命令行上传递了它,因此命令行是:

mvn deploy:deploy-file -Dfile=3rdpartybundle.jar -DpomFile=pom.xml -DrepositoryId=internal -Durl=http://internalserver/nexus

问题在于,当我像这样部署它时,打包被设置为bundle,因此存储库中工件的名称最终为.bundle扩展名,而不是.jar扩展名。

现在,我们无法弄清楚如何将其声明为依赖项。如果我们这样声明:

        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <version>...</version>
            <type>bundle</type>
        </dependency>

我们收到一条错误消息,指出无法解析依赖项。有趣的是,错误消息中的GAV坐标实际上具有“jar”作为依赖类型的值,即使我们将其设置为“bundle”。

如果我们将依赖项更改为:

        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <version>...</version>
            <type>jar</type>
        </dependency>

我们得到完全相同的未解决的依赖性错误。

那么你应该如何将作为bundle打包的工件部署到Maven存储库,以便它可以用作另一个项目的编译时依赖?

由于

4 个答案:

答案 0 :(得分:3)

问题是“3rdpartybundle.jar”正在构建而没有设置extensions = true和/或支持的类型:

<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
...
    <extensions>true</extensions>
...
    <configuration>
        <supportedProjectTypes>
            <supportedProjectType>jar</supportedProjectType>
            <supportedProjectType>war</supportedProjectType>
        </supportedProjectTypes>

如果你无法修复上游,那么有几个选择;

1)使用新项目pom将其重新包装为Jar:

                    <plugin>
                            <groupId>org.apache.maven.plugins</groupId>
                            <artifactId>maven-dependency-plugin</artifactId>
                            <version>2.3</version>
                            <configuration>
                                    <actTransitively>false</actTransitively>
                                    <outputDirectory>target/classes</outputDirectory>
                                    <artifactItems>
                                            <artifactItem>
                                                    <groupId>3rd</groupId>
                                                    <artifactId>party</artifactId>
                                                    <version>X.Y.Z</version>
                                            </artifactItem>
                                    </artifactItems>
                            </configuration>
                            <executions>
                                    <execution>
                                            <goals>
                                                    <goal>unpack</goal>
                                            </goals>
                                            <phase>compile</phase>
                                    </execution>
                            </executions>
                    </plugin>

2)尝试将mvn deploy:deploy-file-DgeneratePom=false -Dpackaging=jar -Dfile=/path/to/3rdpartybundle.jar一起使用,但不指定-DpomFile= - 希望在3rdpartybundle.jar中没有META-INF / maven / pom.xml - 它应该可以使用这个但是你需要指定groupId / artifactId / version参数,因为这些参数不会从项目的pom中派生出来。

我知道我过去构建了bundle工件并将它们部署到我们的nexus(v1.9.0.1),而Spring repo中的那些也是类型化的bundle,但是不记得任何问题。 (顺便说一下,您不需要在依赖声明中指定包,如果它是唯一应该推断的神器,则不需要AFAIK)

答案 1 :(得分:0)

您可能想尝试完全删除该类型,然后执行简单的

mvn install

在包含pom.xml文件的目录中。

答案 2 :(得分:0)

首先,您是否尝试过简单地在捆绑文件夹中调用mvn deploy。如果将distributionManagement配置为部署到您的连接,我希望捆绑包可以获取,构建,测试和部署。
如果此操作失败,您可以使用nexus Web界面手动将捆绑包导入托管存储库。

答案 3 :(得分:0)

感谢您的回答,我想我有一个解决方法(我不会称之为解决方案)。

虽然该解决方案没有利用第三方软件包中可用的pom.xml中的所有可用信息(特别是依赖项),但是@earcar仍在正确的轨道上。

所以即使deploy:deploy-file的文档有点含糊,似乎也可以工作,你可以传递一个pom.xml文件 AND 也可以设置打包参数同时。所以我的命令行现在看起来像这样:

mvn deploy:deploy-file -Dfile=3rdpartybundle.jar -DpomFile=pom.xml -DrepositoryId=internal -Durl=http://internalserver/nexus -Dpackaging=jar

这样做,存储库中的pom.xml仍然表示包装类型为“bundle”,并包含所有依赖项等,但工件本身具有.jar文件扩展名。

然后,当我们将依赖声明为类型JAR时,Maven能够成功解析它:

    <dependency>
        <groupId>...</groupId>
        <artifactId>...</artifactId>
        <version>...</version>
        <type>jar</type>
    </dependency>

这基本上解决了我们的问题。我不确定这是多么便携或可靠。 FWIW,我们正在运行Maven 3.0.3

感谢您的帮助。