on Mar 3rd, 2009OSGi Declarative Services Tooling
For those who have been following the OSGi v4.2 specification revisions lately, hopefully you’re aware that the Declarative Services (DS) portion received some updates. In the 1.1 version of DS, there were these additions:
- name attributes are now optional on references and components (default to the class name)
- activate and deactivate method names on components so you can have POJO components (i.e., no dependency on ComponentContext)
- the ability to activate based on configurations in ConfigurationAdmin (via the configuration-policy attribute)
If people are interested in these additions, I can blog about them in a future post, just let me know. At Eclipse, we have a solid implementation of DS (thanks Prosyst), so solid that we have decided to ship it as part of the Eclipse SDK for the Galileo release this June. As an added bonus, PDE has created some DS tooling to make it easier to craft service component definitions:
With the new tooling, it’s easy to specify your referenced and provided services:
For the people who can’t live without a source view, we have great source editing support:
I’m pleased with the support Eclipse has for DS 1.1 in the Galileo release. I predict that we’ll see a lot more DS usage within the SDK because noone likes to write error prone ServiceTrackers anymore! If you would like to know more about DS, I highly suggest picking up a copy of the new Equinox OSGi book as it has the most indepth chapter on DS I know about. I have been working closely with the book authors and improving the tooling based on their feedback. Also, if you need a lighter introduction to DS, Neil Bartlett has some good introductory articles.
In the end, if you come across any bugs or have suggestions for improvements, please file a bug against PDE with the summary prefix: [ds tooling]. The PDE team takes suggestions seriously and loves feedback, it’s the only way we’ll improve the tooling! Don’t be shy to file bugs!
Related posts:
Did you use data binding for the new editor?
Boris, we didn’t use JFace Databinding for the tooling in the SDK. The main reason was that we reused a lot of the existing PDE editor framework code which doesn’t use databinding. However, in the PDE Incubator (thanks to Benjamin Cabe), we have started work on what the DS editor would look like if it was fully based on EMF + Databinding:
http://dev.eclipse.org/viewcvs/index.cgi/pde-incubator/modeling/plugins/
My goal is to move most if not all of PDE’s editors to this approach in the e4 timeframe. I want to use EMF to manage the model and different versions of that model. I want to use Databinding to help build the UI for that model… in effect saving a lot of boilerplate code. Expect a future blog post on the awesomeness in terms of code savings and other cool things with this approach.