How to deploy OSGi bundle to Maven repo with deploy:deploy-file?

I have an OSGi bundle that was built using Maven by another team. The POM file declares its packaging as "bundle" and uses the Apache Felix plugin.

I need to deploy this artifact to a local Maven repository (Nexus) so that it can be used by our internal projects.

I have used the deploy:deploy-file target to deploy the bundle to the repository, just as you would with a standard JAR file and this works without error. I extracted the embedded POM from the bundle and passed that on the command line, so the command line was:

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

The issue is that when I deploy it like this, the packaging is set to bundle and as a result the name of the artifact in the repository ends up with a .bundle extension, instead of a .jar extension.

Now, we cannot figure out how to declare it as a dependency. If we declare it like this:

        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId&开发者_如何转开发gt;
            <version>...</version>
            <type>bundle</type>
        </dependency>

We get an error stating that the dependency cannot be resolved. The interesting thing is that the GAV coordinates in the error message actually has "jar" as the value for the type of the dependency even though we set it as "bundle".

If we change the dependency to:

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

We get the exact same unresolved dependency error.

So how are you supposed to deploy an artifact packaged as a bundle to a Maven repository, so that it can be used as a compile time dependency for another project?

Thanks

The issue is that "3rdpartybundle.jar" is being built without setting extensions=true and/or supported types:

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

If you can't fix that upstream, then there's a couple of options;

1) Repack it as a Jar using a new project pom:

                    <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) Try using mvn deploy:deploy-file with -DgeneratePom=false -Dpackaging=jar -Dfile=/path/to/3rdpartybundle.jar but without specifying -DpomFile= - hope there's no META-INF/maven/pom.xml inside the 3rdpartybundle.jar - it should work using this but you'll need to specify the groupId/artifactId/version parameters as these won't be derived from the project's pom.

I know I've build bundle artifacts in the past and deployed these to our nexus (v1.9.0.1) and those in the Spring repo are typed bundle too, but don't recall any issue. (Incidentally you don't need to specify the bundle in dependency declarations, AFAIK if it's the only artifact it should be inferred)

At first, have you tried to simply invoke mvn deploy in your bundle folder. I would expect that the bundle gets, build, tested and deployed if distributionManagement is configured to deploy to your nexus.
If this fails you can manually import the bundle using the nexus web interface into a hosted repository.

Thanks for the answers, I think I have a workaround (I wouldn't call it a solution though).

@earcar is on the right track, although that solution doesn't leverage all of the information available in the pom.xml that is available in the 3rd party bundle already (particularly the dependencies).

So what seems to work, even though the documentation for the deploy:deploy-file is a little vague, is that you can pass a pom.xml file AND also set the packaging parameter at the same time. So my command line now looks like this:

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

Doing it this way, the pom.xml in the repository still says that the packaging is of type "bundle", and includes all of the dependencies etc., but the artifact itself has a .jar file extension.

Then when we declare our dependency as type JAR, Maven is able to resolve it successfully:

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

This basically solves our problem. I am not sure how portable or reliable this is though. FWIW, we are running Maven 3.0.3

Thanks for the help.

You may want to try removing the type completely, and then doing a simple

mvn install

In the directory containing your pom.xml file.