OSGI problems and dillemmas


(Zbigniew Sokołowski) #1

What is missing I need a better documentation how to use OSGI plugin. We introduce gradle to huge project. Some devs arguing for using tycho. As far as I understand tycho, it’s advantage is, that it takes everything from the manifest.

tycho: takes dependencies from the manifest etc. gradle: define dependencies in build.grade and generate manifest

For an developer who only wants to use eclipse, the manifest-fist policy of tycho is more comfortable, as you do not have to touch any build file, because you can edit the manifest via eclipse GUI.

What is the best way in gradle?

Thanks! Zbigniew


(Phil Swenson) #2

OSGi is the path to slow development velocity, complicated build systems, lousy testing frameworks, and trading jar hell for bundle hell. You can get modularity simply by following the Single Responsibility Principle + Inversion of Control + using a nice build system that supports modularity (like Gradle). Just my take based on a lot of pain…


(Phil Swenson) #3

Since you probably are going to go OSGi anyway… there is no way you are going to get around editing build files. You have to declare your dependencies. And gradle will generate your eclipse project files for you based on these dependencies. Also, having your manifest generated by gradle means you can insert variables. And a build file is way more readable than the manifest. We tried using eclipse manifest UI and it didn’t go well.


(Luke Daley) #4

Hi Zbigniew,

If that’s the approach you want to take, I’d suggest sticking with Tycho. Their OSGi solution is generally more evolved than Gradle’s currently.

That said, you could write code to parse a manifest and programatically build up the dependencies in Gradle. All you’d be achieving is declaring your dependencies in manifest format.