[tycho-user] Keeping Eclipse and Tycho in sync

[Barrie Treloar <baerrach@xxxxxxxxx>]

My RCP application was three plugins, where one plugin had all the
code (and extra libraries embedded in the bundle and included on the
classpath) and the other two were big fat map/geocoding stuff the
first plugin could make use off.

The bundle with the embedded libraries had a MANIFEST.MF that looked
something like this
Bundle-ClassPath: .,
 lib/commons-validator-1.3.1.jar,
 lib/commons-beanutils-1.7.0.jar,
 lib/spring-context-2.0.8.jar,
 lib/spring-jms-2.0.8.jar,
 lib/aopalliance-1.0.jar,
 lib/commons-digester-1.8.jar,
 lib/commons-logging-1.1.jar,
 lib/commons-pool-1.3.jar,
 lib/spring-beans-2.0.8.jar,
 lib/spring-core-2.0.8.jar,
 lib/spring-dao-2.0.8.jar,
 lib/spring-support-2.0.8.jar,
 lib/commons-collections-3.2.jar,
 lib/spring-aop-2.0.8.jar,
 lib/spring-remoting-2.0.8.jar,
 lib/<module-1>-2.0.11-SNAPSHOT.jar,
 lib/<module-2>-2.0.11-SNAPSHOT.jar,
 lib/slf4j-api-1.6.1.jar,
 lib/xpp3_min-1.1.3.4.O.jar,
 lib/xstream-1.2.2.jar,
 lib/commons-lang-2.5.jar,
 lib/commons-io-1.4.jar,
 lib/commons-lang-LANG-378-2.4.0.2010-06-08.jar,
 lib/mina-core-1.1.7.jar,
 lib/gwt-user-1.4.62.jar,
 lib/jaxb-api-2.1.jar,
 lib/slf4j-log4j12-1.6.1.jar,
 lib/log4j-1.2.16.jar

So we've got Spring, Log4j, Apache Commons, and XStream in here.
Plus two additional libraries that are part of the current Maven build
needed for this RCP app to work.

So far I've migrated this over to use Tycho.
Originally I kept the embedded libraries to make the transition easier.

But keeping the embedded libraries in sync previously was a bit of a
pain and a source of common errors.
As mentioned in other emails .classpath, build.properties and
MANIFEST.MF need modifying to ensure they reference they right stuff.

I was hoping that moving to a target platform would make this a bit
easier as the plugin would just depend on the versions in the target
platform, so there would be one place to define versions.
I've managed to move to an Eclipse Target Platform file (*.target)
which has shrunk the Bundle-Classpath to just include the two modules.
This was a chore.
Because Spring, Log4j, XStream and Commond Validator/Digester all want
to do Class loading it has meant adding the Eclipse specific bundle
headers "Eclipse-BuddyPolicy: registered" to those wrapped jars and
occasionally inserting "Eclipse-RegisterBuddy:" across these jars to
get them to find classes.  If anyone has suggestions on a better way
to do this, I'm all ears.

What I am not clear on is how do I remove these last two modules and
get them included in the Target Platform file?
All my locations in the target file point to Nexus with the
Experimental OSGi plugin exposing the P2 metadata.

I could split the build into smaller sections and ensure that the
modules have been deployed as snapshots to Nexus which can then be
included in the target platform, but this will slow development down.

Ideally I want to be able to make changes in Eclipse and have them
available so I can run my app inside Eclipse for quick testing.
Maven/Tycho would be used to build the zip file for deployment and
would use the target dependencies and the reactor to find the modules
dependencies instead of requiring a snapshot deploy first.
Is this achievable?
Is this sane?

I haven't had enough time to play with this alternative to come to any
conclusions.
I think:
* the need to wrap so much stuff with OSGi headers is going to make
upgrading artifact versions a pain
* the loss of dependency information in the pom will mean its possible
that the server side infrastructure upgrades artifacts and the client
really should as well but it won't get noticed since its buried in
target platforms and Require-Bundles.
* not sure how release process will go

What do other people do?
Has anyone got anything similar in their RCP application and can share
knowledge?

Cheers