Handling non-OSGi dependencies when integrating Ma

问题:

I have a bunch of Eclipse-based plugins that I have been migrating to Maven/Tycho. Most of these plugins depend on separate libraries that I now manage through Maven, rather than muddle around with .jar files.

The most cumbersome part of my current setup is due to the apparent inability of Tycho to process Maven-only (i.e. non-OSGi) artifacts. My current setup works like this:

1. In the pom.xml of each Eclipse plugin I issue an unpack goal to maven-dependency-plugin during the initialize phase. This unpacks the artifacts that I specify to a separate target/dependencies directory.

2. The target/dependencies directory is added as an output directory in build.properties, so that Tycho can add it to the classpath when compiling:

   source.. = src/main/java/
   output.. = target/classes/
   output.. = target/dependencies/
   

3. The target/dependencies directory is added to the Bundle-ClassPath library in META-INF/MANIFEST.MF.

These settings allow the compile Maven directive to compile the plugin. Importing the project from VCS and manually specifying the target/dependencies directory as a class folder in Eclipse allows said IDE to also compile the plugin.

Unfortunately this is a rather cumbersome solution for a few reasons:

• Configuring the maven-dependency-plugin requires listing all artifacts that should be unpacked. One could use unpack-dependencies instead of unpack, but that would also unpack all OSGi dependencies - having half of Eclipse unpacked in each project directory is not my idea of fun...

• Adding the class folder in Eclipse requires Maven initialize to be run once, so that the target/dependencies directory is created.

• There is no source connection between the pure Maven projects and their depending Tycho projects in Eclipse. For a change to propagate from a Maven project to an Tycho project, so that e.g. Eclipse may show a potential compilation problem, one has to mvn install the Maven project and then run mvn clean initialize in the Tycho project to remove the previously unpacked dependencies and pull in the current set. Then you have to refresh the Eclipse project and hope that Eclipse does the right thing.

  In the same vein, viewing the source of a dependency from a Tycho project will not show the primary source file, but rather whatever is available in target/dependencies - quite possibly just a .class file.

I am thinking that there must be a more reasonable way to go about this - something that would allow Eclipse and Maven projects to integrate more tightly.

So, what am I missing? What is the recommended setup for this use case? Is there a better alternative? Preferably something that would not require setting a bunch of Nexus and/or p2 repositories?

回答1:

It seems like we apply similar strategies. However, I use a nexus mixed repository (having both maven and p2).

1. For unpacking dependencies, I use the maven-dependency-plugin to place them in target/dependency (see below).
   • 1.1. copy-dependencies does what is needed without unpack.
2. Your source and output is about the same as mine.
   • 2.1. Yes, mvn has to initialize the target/dependencies
3. I only include the required jars in the MANIFEST, because 1 will retrieve many unnecessary jars.
   • 3.1. I manually select the relevant jars.
   • 3.2. Yes, if the non-Eclipse-managed (maven) projects change (outside of your workspace), then you have to run mvn build to update them.
   • 3.3. A key to making this work, is to:
     • 3.3.1 Deploy your maven and Eclipse projects to a (snapshot) repository. I use http://www.sonatype.org/nexus/ . Thus, when you run maven, it looks at the nexus repository for updates of both maven and Eclipse projects.
4. Some other notes, which may already be obvious:
   • 4.1. The pom.xml file should only contain non-Eclipse jars as dependencies. (The tycho plugin handles all the Eclipse dependencies, which should be found in your (nexus) repository.)
   • 4.2. Add the dependent jars to the runtime in Eclipse (by editing the plugin.xml runtime)

Maven plugin:

        <plugin>
            <!-- Copy non-Ecipse plugins to target/dependency so that may be referenced 
                for runtime use. -->
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.1</version>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                    <configuration>
                        <excludeGroupIds>org.XXX</excludeGroupIds>
                    </configuration>
                </execution>
                <execution>
                    <id>classpath</id>
                    <goals>
                        <goal>build-classpath</goal>
                    </goals>
                    <configuration>
                        <fileSeparator>/</fileSeparator>
                        <prefix>target/dependency</prefix>
                        <outputFile>${project.build.directory}/classPath.txt
                        </outputFile>
                    </configuration>
                </execution>
            </executions>
        </plugin>

Example build.properties

bin.includes = META-INF/,
target/classes/,
plugin.xml,
target/dependency/mongo-java-driver-2.11.3.jar

Example manifest (only a subset of jars):

Bundle-ClassPath: .,
target/classes/,
target/dependency/mongo-java-driver-2.11.3.jar

回答2:

You can try maven-bundle-plugin with Embed-Dependency.

See http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts

The official demo works well. However, i'm still not succeed in using my jar file in this way.

回答3:

The official demo indeed works well and shows the way to embed non-OSGI dependencies, or in other words create OSGI facade for other dependencies.

The way is indeed copying the dependencies manually, making them part of OSGI manifest and exporting packages of interest.

The real problem is however the execution of the dependency plugin from within Eclipse.

Is simply doesn't run, even with respective M2E connector thus blocking discovery and PDE class-path resolution.