OSGi Best and Worst Practices Chris Aniszczyk — Red Hat Jeff McAffer — EclipseSource Martin Lippert — it-agile Paul Vander...
Don’t Program OSGi
 
Sometimes it better not to know Ignorance is bliss
It's bad mojo to pollute the POJO
Your code sucks. Versioning can help.
Good fences make good neighbors
Size Does Matter
Manage your dependencies
Use services
 
 
Not everything should be a service
...and OSGi made all the apps dynamic
The Easter Bunny is dead
 
If you don't test it, it doesn't work!
OSGi is not a religion
 
Lets look at some controversy Now some controversy
Require-Bundle  Import-Package
Services or Extensions?
Got Questions? http://equinoxosgi.org
Upcoming SlideShare
Loading in …5
×

OSGi Best and Worst Practices

4,745 views

Published on

A presentation I gave with Jeff McAffer, Paul Vanderlei and Martin Lippert at EclipseCon 2010.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,745
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
89
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Jeff
  • Jeff Don’t be too surprised OSGi is rather elegant It is minimalist and unpresumptious This is awesome as it keeps system size down But it is a system's level programming model. - APIs are low level - Dynamics are hard, cause, well, dynamic stuff is hard and there is not a lot of help Fundamentally, OSGi is an implementation detail, an enabling element.  For most people is it something to be hidden from view
  • Sometimes its better not to know whats around you Programming POJOs help isolate you from the OSGi gorp Really we are talking about dependency injection and a style of coding. - Encourages reuse - eases testing - Clarifies design and dependencies This is a pervasive theme throughout this talk In short: Its bad mojo to pollute the POJO
  • Chris
  • chris
  • Martin
  • Jeff Imagine this Hello <cable co> my TV is not working string another line Keep doing that until the price of copper skyrockets and someone steals the pole Know the bundle food chain Minimizing your dependencies improves reuse Improves freedom of action
  • Paul Using services as the unit of reuse is preferred over just sharing packages: -lifecycle management -pluggability DS is better than Service Tracker: -for a bundle needing two services..... -100 lines of code vs 8 lines of XML -error-prone -required hours of effort from experts DS: -encourages good componentizaiton -allows lazy classloading -nice tooling ServiceTracker: -too easily ties your code to OSGi -makes testing and reuse more difficult -pollutes the POJO (bad mojo)
  • this is for a bundle requiring two services
  • Paul just because something in your application needs to be registered, it does not mean that  you should make that thing a service and use the service registry -whiteboard pattern can easily fall into this trap -example: student registers for a course. student is NOT a service -core & other utility classes -HashMapFactoryService counter-example
  • Jeff OSGi is a bit of a fairy tale story. The small but secretly powerful modularity system That runs around brings dynamism to everyone Yeah, well, sorry, but fairy tales are just that, fairy tales. <any kids in the room?>
  • Oh, and BTW, …
  • Dynamics are not free Real work is needed Analogous to running multi-threaded – you have to code for it. not for everyone Relate to Eclipse adoption
  • Paul
  • Paul OSGi is not omnipresent -If you’re spending all your time writing OSGi-related code, you’re doing it wrong! OSGi is not infallible -Plenty of crap in the OSGi holy scriptures: Wire Admin, Event Admin… -OSGi is not omnipotent Not everything OSGi provides is ideal for your application ConfigAdmin
  • Martin
  • Martin
  • Martin
  • shameless plug
  • OSGi Best and Worst Practices

    1. 1. OSGi Best and Worst Practices Chris Aniszczyk — Red Hat Jeff McAffer — EclipseSource Martin Lippert — it-agile Paul VanderLei — Band XI
    2. 2. Don’t Program OSGi
    3. 4. Sometimes it better not to know Ignorance is bliss
    4. 5. It's bad mojo to pollute the POJO
    5. 6. Your code sucks. Versioning can help.
    6. 7. Good fences make good neighbors
    7. 8. Size Does Matter
    8. 9. Manage your dependencies
    9. 10. Use services
    10. 13. Not everything should be a service
    11. 14. ...and OSGi made all the apps dynamic
    12. 15. The Easter Bunny is dead
    13. 17. If you don't test it, it doesn't work!
    14. 18. OSGi is not a religion
    15. 20. Lets look at some controversy Now some controversy
    16. 21. Require-Bundle Import-Package
    17. 22. Services or Extensions?
    18. 23. Got Questions? http://equinoxosgi.org

    ×