Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Share Dependencies Between RCP Tycho Driven Project and Plain Maven

DZone's Guide to

Share Dependencies Between RCP Tycho Driven Project and Plain Maven

· DevOps Zone
Free Resource

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

It is well known that RCP bundle is not the Maven's best friend. Peacemaker between them is Maven's plug-in Tycho. I was recently migrating my free time RCP based project into Maven Tycho. My goal was to share dependencies between normal Maven project and Tycho driven project. Plain maven project is needed for running TestNG tests (TestNG is not supported by Tycho).

There are two approaches how to automatically handle dependencies of Eclipse 4 RCP based project driven by Tycho:

  • manifest-first - this approach follows standard RCP/OSGi dependency mechanisms. All dependencies has to be also assembled into bundles. This is preferred and nicely described in tutorial suggested by Tycho's website. It is hosted on github. But there are few problems complicating my goal:

    • It is needed to find existing bundle or create one for every dependency. Unhandy.

    • If I would use manifest-first approach, bundle dependencies wouldn't be visible by non Tycho maven projects. I would need to have two set of dependencies. Redundancy.

  • pom-first – this is alternative approach when dependencies are packed into bundle by maven-bundle-plugin and this is used as dependency to project's bundle. This approach is described here. Problem of this approach:

    • It is working only for Maven build and dependencies are not picked up by Eclipse.

Finally got the clue here (in the last approach) and came up with solution that is maybe not that pretty, but the dependencies are specified at one place and even Maven as well as Eclipse can pick them up. It is using some aspects both mentioned approaches.

I will show here only configuration crucial for my workaround. Whole project can be found on google code page. Let me describe maven projects structure:


discography-organizer.parent – contains various properties used by child poms. Is also used to run build of all sub-modules.

discography-organizer.dependencies.parent – shared dependencies are specified here

discography-organizer.dependencies.bundle – is doing two important steps:

  1. maven-bundle-plugin to pack dependencies

    <plugin>
    	<groupId>org.apache.felix</groupId>
    	<artifactId>maven-bundle-plugin</artifactId>
    	<version>2.1.0</version>
    	<extensions>true</extensions>
    	<configuration>
    		<instructions>
    			<Export-Package>*; -split-package:=merge-last</Export-Package>
    		</instructions>
    	</configuration>
    </plugin>
  2. maven-antrun-plugin to copy packed jar with all dependencies into location where it can be picked up by RCP project

    <plugin>
    	<groupId>org.apache.maven.plugins</groupId>
    	<artifactId>maven-antrun-plugin</artifactId>
    	<version>1.7</version>
    	<executions>
    		<execution>
    			<phase>package</phase>
    			<configuration>
    				<target>
    					<copy tofile="${temp.dependencies.folder}/dependencies.jar">
    						<fileset dir="${project.build.directory}" includes="*.jar" />
    					</copy>
    				</target>
    			</configuration>
    			<goals>
    				<goal>run</goal>
    			</goals>
    		</execution>
    	</executions>
    </plugin>

discography-organizer.bundle – main RCP bundle project driven by Tycho. Expect Tycho call, there are two important configurations done:

  1. In plugin.xml configuration on tab “Runtime” choose dependency jar created by discography-organizer.dependencies.bundle


  2. Pack main project classes into jar. This will be used by testing project discography-organizer.tests

    a) packing of application classes into jar

    <plugin>
    	<groupId>org.apache.maven.plugins</groupId>
    	<artifactId>maven-antrun-plugin</artifactId>
    	<version>1.7</version>
    	<executions>
    		<execution>
    			<phase>package</phase>
    			<configuration>
    				<target>
    					<jar destfile="${temp.dependencies.folder}/${bundle.name}-TESTING.jar" 
    						basedir="${project.basedir}/bin"/>
    				</target>
    			</configuration>
    			<goals>
    				<goal>run</goal>
    			</goals>
    		</execution>
    	</executions>
    </plugin>

    b) pom file for this test dependency    


    <groupId>sk.lkrnac.discorg</groupId>
    <artifactId>discography-organizer.bundle</artifactId>
    <version>TESTING</version>
    <packaging>jar</packaging>

discography-organizer.tests – normal maven project with tests. It is reading testing classes from jar created by discography-organizer.bundle

<dependency>
	<groupId>sk.lkrnac.discorg</groupId>
	<artifactId>${bundle.name}</artifactId>
	<version>TESTING</version>
	<scope>system</scope>
	<systemPath>${temp.dependencies.folder}/${bundle.name}-TESTING.jar</systemPath>
</dependency>

And that's it. Dependencies needed by main bundle or test artifacts are packed into jar files. This workaround has side effects that I really don't like. Dependencies are ugly packed in one jar for main bundle. But I can live with that because this approach enables me to combine features of Tycho and non-Tycho maven plug-ins. I am planning to use another Tycho's features (automatic building and JUnit plug-in tests) and I have good start point for it.

If you can think of some simpler or more elegant solution please don't hesitate to comment it. Thanks

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}