Maven + Tycho, adding Maven dependencies

Question

We have an Eclipse Plugin which we build using Maven and Tycho. Currently however, we still provide all project dependencies through a bunch of manually added JAR files and not by Maven. This is due to the following reasons: (1) The dependencies are not available through a standard Eclipse update site (at least not in a current version), (2) the dependencies are not available as bundles.

The biggest part of these dependencies are the Selenium libraries (API, Remote, browser-specific libs and their transitive dependencies, such as Guava, etc.)

I've wasted hours, trying to pull those dependencies during our Maven build. Following this SO question, I tried the p2-maven-plugin, created an update site with our dependencies which I added to my Eclipse target platform. However, during runtime, classes, which are referenced across different JARs could not be loaded (I assume, from my very limited OSGi knowledge, because some necessary information was missing in the MANIFEST.MF files). Here's an example of the issue, when trying to create a RemoteWebDriver, which uses the DesiredCapabilities class (both classes in different bundles):

Exception in thread "Thread-8" java.lang.NoClassDefFoundError: org/openqa/selenium/remote/DesiredCapabilities
    at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:243)
    at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:126)
    at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:153)
    …
Caused by: java.lang.ClassNotFoundException: org.openqa.selenium.remote.DesiredCapabilities cannot be found by org.seleniumhq.selenium.remote-driver_2.45.0
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 7 more

Is there anything I still need to take care of, when using the p2-maven-plugin? The relevant parts of the pom.xml looked like this:

<plugin>
    <groupId>org.reficio</groupId>
    <artifactId>p2-maven-plugin</artifactId>
    <version>1.1.1-SNAPSHOT</version>
    <executions>
        <execution>
            <id>default-cli</id>
            <configuration>
                <artifacts>
                    <artifact>
                        <id>org.seleniumhq.selenium:selenium-remote-driver:2.45.0</id>
                    </artifact>
                </artifacts>
            </configuration>
        </execution>
    </executions>
</plugin>

Answer 1

Couldn't get it to work, so we're now using the maven-dependency-plugin with the copy-dependencies, which we execute during the Maven initialize phase to pull all necessary dependencies (contrary to my initial feeling, this can be combined with the pom.xml using the eclipse-plugin packaging and the "manifest first" approach). The relevant part looks like this:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.10</version>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <phase>initialize</phase>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                    <configuration>
                        <includeScope>runtime</includeScope>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

The Maven dependencies are then copied to target/dependency.

Only little issue: The Bundle-ClassPath in the MANIFEST.MF needs to be manually updated in case the name of a JAR file changes when updating Maven dependencies (e.g. commons-io-2.4.jar becomes commons-io-2.5.jar).

[edit] Revisiting this answer in regards to the last sentence above: The version numbers can be conveniently stripped through the following option: <stripVersion>true</stripVersion>. This means, the above library will be renamed to commons-io.jar and thus no paths need to be updated when a version number changes.