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

Question

我有一个由另一个团队使用 Maven 构建的 OSGi 包。 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 扩展名结束，而不是 .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>

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

那么，您应该如何将打包为捆绑包的工件部署到 Maven 存储库，以便将其用作另一个项目的编译时依赖项呢？

谢谢

Answer 1

问题是“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= - 希望里面没有 META-INF/maven/pom.xml 3rdpartybundle.jar - 它应该可以使用它，但您需要指定 groupId/artifactId/version 参数，因为这些参数不会从项目的 pom 中派生。

我知道我过去已经构建过捆绑工件并将它们部署到我们的连接（v1.9.0.1）中，并且 Spring 存储库中的那些也被键入捆绑，但不记得有任何问题。 （顺便说一句，您不需要在依赖项声明中指定捆绑包，据我所知，如果它是唯一应该推断的工件）

Answer 2

感谢您的回答，我想我有一个解决方法（但我不会称其为解决方案）。

@earcar 走在正确的轨道上，尽管该解决方案没有利用 pom.xml 中的所有可用信息，而这些信息已经在第 3 方捆绑包中可用（特别是依赖项）。

因此，尽管deploy:deploy-file 的文档有点模糊，但似乎有效的是，您可以传递 pom.xml 文件并且同时设置打包参数。所以我的命令行现在看起来像这样：

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

感谢您的帮助。

Answer 3

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

Answer 4

您可能想尝试完全删除该类型，然后

mvn install

在包含 pom.xml 文件的目录中执行简单的操作。