... from the "Can't We All Just Get Along?" department, you may feel as I do... You want to be lazy where you can, and let these specific Java tools do your work for you. 

And of course, you want it to happen without them fighting each other, and without keeping multiple layers of duplicate metadata synched up in pom.xml, MANIFEST.MF, and gosh knows what other files. In other words, you want DRY.

Sounds great huh? Consider Tycho, if that's your situation. This is Sonatype's work in progress, which neither supports nor fights Spring OSGI, and lets you use the MANIFEST.MF file as your configuration instead of your pom.xml. Even works with p2, if that's you thing.

So I decided to take it for a spin, even though it isn't supposed to be ready yet.


I've confirmed it as not ready - just as advertised. :) But interestingly, it isn't because I couldn't get it to work - that was no problem. I just couldn't get it to work with m2eclipse, and I've taken an affection to this tool as a part of my daily work for the last couple years. I like  m2eclipse because it's DRY. In that, your pom.xml acts as your class path file. That's pretty logical, from my perspective.

Most importantly for this blog is not the up or down vote on Tycho. What is important below is knowing how to succeed if you want to try. Do not follow the directions on the site! Or at least, not totally. Instead, here is how I got a successful trial done May 3, 2010 with verson 0.8.0 of Tycho .


  • This is NOT for Maven newbies.
  • This is probably not for OSGI newbies.
  • Requires latest Maven 3 release
  • Requires RCP version of Eclipse
  • Requires the delta plugin (I think - I installed it anyway)
  • Requires subversion client to check out the dynaresume code. (I used subversive)
  • No idea if it required Nexus, mine was already running
  • If you're an old Maven hack who never bothered to use features nesting projects under (perhaps multiple) hierarchies of parent poms like me, you'll want to bone up on that a little bit before you start. The dynaresume project is the perfect example for that, but so is any Pax generated project.
  • It did not take me too much time, once I had everything I needed.


High level review:

You're going to start by reading the documentation, and thinking that you will follow these docs. But then, don't. Instead, check out the dynaresume project, and get to know how it is structued. Then read the blog linked below, and follow it almost to the letter. You may then opt to use the pom files in the dynaresume project against your simpler example genereated from the blog, and you'll have something of your own working pretty quickly.

As below:

  • Get all your pre-requisites set up per the listing above.
  • Start with this documentation to mostly just read, and then ignore. Especially do not use the code - it's obsolete.
  • Check out the dynaresume project from here.
  • Follow Mattias Holmqvist's super helpful blog, excepting the one more up to date plugin code below.
  • [Optional] Adopt the above infrastructure code to a mores serious project of your own.


More Up To Date pom.xml code

I found that this plugin code was required, instead of the one referenced in the Mattias's blog:



This above xml seemed to be required to make it work with p2 properly. Just for the record, p2 will be the very first thing I learn to cut out of my own development process, should that be possible. I'm here to do the DRY thing with Maven and OSGI, not eclipse plugins.

Finishing Up:

After I finished the above exercise, I did some more extensive testing with real OSGI projects I had in my arsenal. 

Even added in a completely separate proguard plugin step to the install phase to shrink the jar. It worked just fine, even though it seemed like it was using the OSGI runtime to do so? Nice.

Then moved on to where I spent most of the time - and that's also where I had the most problems - trying things out with the m2eclipse tool. Interestingly, an earlier version of  m2eclipse   worked, though it gave me some errors in the IDE. A later version didn't give me those same errors, but then it didn't work for running a maven process, either. Heh, this toolset is not advertised to be ready yet, so I shouldn't expect it to be.


When all was said and done and I had swapped out my own projects into the mix, there was very little if any difference between my OSGI projects that used Tycho, and the ones that used Pax, which works for me fine as is. Only the parent pom.xml has to change.

So what I've decided to do is keep developing exactly as I am now, using  Pax .

  • Disadvantage: It's not DRY, it's up to me to maintain both pom.xml and MANIFEST.MF separately. No biggie for now.
  • Advantage: It works in m2eclipse if I use my own  boilerplate .classpath file, and it's pretty dumb (maintainable) code.

Then, when Tycho is ready, I simply switch the parent pom, and I'm ready to move to the new kid in town. Pretty cool stuff.


Obviously, most of the credits go the awesome guys at Sonatype, not only Jason van Zyl, but primary Tycho developer Igor, and the whole team that maintains the foresight to push this technology into what seems to be important territory.

Special credits to Mattias Holmqvist for the great blog that made my exploration of Tycho possible, and for Joel Rosi-Schwartz for posting the link in the Tycho Users list with the explanation that it was the easiest resource to use.

And special thanks as well to Pascal Leclercq and team for the superb example project they created in the dynaresume. Great stuff to learn from.


Jason van Zyl advised, after the blog was published, that there is an m2eclipse configurator that allows Tycho projects to work with it. I look forward to learning more about it, and possibly revising ths blog again later.