Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OSGi Sticker Shock Eclipse Con 2010


Published on

Slides for EclipseCon 2010 presentation.

Published in: Technology
  • Be the first to comment

OSGi Sticker Shock Eclipse Con 2010

  1. 1. Overcoming Sticker Shock Addressing the unexpected costs of OSGi in the Enterprise Eric Johnson
  2. 2. We think OSGi is great. <ul><li>Developers are forced to identify dependencies
  3. 3. Cannot “cheat” on component architecture
  4. 4. Runtime fails to “wire”, rather than obscure Class incompatibilities
  5. 5. Potentially a very dynamic runtime! </li></ul>
  6. 6. Where are we using OSGi? <ul><li>Runtime </li><ul><li>Bundles inside of OSGi frameworks </li></ul><li>Design-time </li><ul><li>Extending the Eclipse environment </li></ul><li>Deployment </li><ul><li>Tracking what is and needs to be deployed, and where? </li></ul><li>Build-time </li><ul><li>Using stated dependencies to reduce surprises </li></ul></ul>
  7. 7. OSGi is too fine grained. <ul><li>We build features, not individual OSGi bundles
  8. 8. We ship products, not features or bundles
  9. 9. … therefore we need additional levels of metadata </li><ul><li>Not all dependency data can be derived from lower levels. </li></ul></ul>
  10. 10. More specifically, what has slowed us down? <ul><li>Metadata </li><ul><li>Metadata for our own software
  11. 11. Third party software metadata - including Eclipse! </li></ul><li>Build architecture, infrastructure, & tooling
  12. 12. Packaging & deployment granularity
  13. 13. Dual-target code </li><ul><li>Same code running in design-time (Eclipse), and runtime (pure Equinox), but not the same metadata! </li></ul><li>Common development platform … and none of that is code to solve customer problems!!! </li></ul>
  14. 14. For our own metadata, what do we do? <ul><li>Version entire feature as one! </li><ul><li>Even if you touch only one source file, bump every package, every bundle, and version of feature
  15. 15. Only way to safely maintain multiple branches of code. </li></ul><li>Use “Import-Package” </li><ul><li>Different runtime environments have different packages from “outside” OSGi runtime
  16. 16. All packages are versioned on export and import </li></ul><li>Version ranges </li><ul><li>Always up to, but not including next major version </li></ul></ul>1.0 1.0 1.0 1.1 1.1 1.1
  17. 17. What have we learned about integrating third-party libraries? <ul><li>We wrap all of them. Why? </li><ul><li>No Java standard for versioning of JAR files, much less packages
  18. 18. Need to state all “Import-Package” entries
  19. 19. Existing attempts not strict enough (SpringSource) </li></ul><li>Wrap Eclipse stuff too! </li><ul><li>Eclipse typically uses Require-Bundle instead of Import-Package
  20. 20. Once you redo bundles, you have to build new features.... </li></ul><li>We built a validation tool... </li><ul><li>Scans byte-code to make sure that all needed packages have been imported.
  21. 21. … and enforces other best practices (naming, versions, etc.) </li></ul></ul>
  22. 22. What about version #s? <ul><li>Version numbers are customer facing!
  23. 23. Only first three parts of version # matter </li><ul><li>Impractical to maintain Import-Package constraints that vary qualifier
  24. 24. IDE tooling doesn't support it </li></ul><li>Yet we maintain four distinct branches: </li><ul><li>Major, minor, service pack, “hot fix” -> version space is incomplete
  25. 25. Solution: A.B.100 is a “service pack” A.B.1, A.B.2 are “hot fixes” </li></ul><li>Built tools for: </li><ul><li>Checking version number consistency against what's GA'd
  26. 26. Bumping version numbers consistently. </li></ul></ul>
  27. 27. We've developed our own build infrastructure and tooling. <ul><li>Numerous “update sites” </li><ul><li>Capturing release/debug builds
  28. 28. “Stable” vs. “unstable”
  29. 29. Eclipse specific sites (Eclipse 3.2, Eclipse 3.3, Eclipse 3.4, …) </li></ul><li>Leveraged existing PDE builder & Ant
  30. 30. Built tooling to create “target platforms” </li><ul><li>See my presentation from EclipseCon 2009
  31. 31. Must generate dynamically for agility </li></ul><li>Internal web site for: </li><ul><li>Analyzing products/features/bundles
  32. 32. What's used by what?
  33. 33. What's shipped?
  34. 34. What's in the pipeline? </li></ul></ul>
  35. 35. How do we present “deployment” to our users? <ul><li>Customers don't want to see individual bundles </li><ul><li>Want product “features”
  36. 36. “functionality” always larger than Eclipse features </li></ul><li>Our customers want stable environments </li><ul><li>Updating bundle X must not affect bundle Y
  37. 37. So OSGi dynamism not a key capability
  38. 38. Sometimes, you just need a separate JVM </li></ul></ul>What customer wants to see Products, features, bundles
  39. 39. Dual-targets, huh? And why? <ul><li>Some bundles are the same </li><ul><li>EMF-based models, utility classes, validation code, need to work in both Eclipse and runtime </li></ul><li>Runtime metadata doesn't work with Eclipse </li><ul><li>“Import-Package” in conjunction with “Require-Bundle” can be bad </li></ul><li>Bundles only need to be dual target... </li><ul><li>When importing a package provided by Eclipse environment
  40. 40. When using javax.* packages </li></ul><li>Consequence: We need a parallel set of feature & plugin metadata! </li></ul>
  41. 41. What did we do to accommodate Eclipse? <ul><li>Conventions:
  42. 42. To reduce complexity </li><ul><li>Same exact version number
  43. 43. No code rebuilt, just metadata changes
  44. 44. Developers only provide alternate bundle MANIFEST.MF </li><ul><li>feature.xml file are generated </li></ul></ul></ul>feature.foo_1.0.0 bundle.foo_1.0.0
  45. 45. We need a common Eclipse environment..., but we could be doing more... <ul><li>Examples: </li><ul><li>Need a team using same version of EMF, version control plugin
  46. 46. Want everyone using code coverage tools, static analysis tools
  47. 47. Efficiency – preconfigured Mylyn, integration with our automated systems. </li></ul><li>Caveats: </li><ul><li>A single company-wide mandate doesn't work
  48. 48. Different branches require different versions of EMF
  49. 49. Each team wants one or more configurations...
  50. 50. Preferences for different tool sets </li></ul><li>Still need to... </li><ul><li>Figure out best way to share/compare configurations
  51. 51. Get developers up-to-speed quickly </li></ul></ul>
  52. 52. Where do we go from here...? <ul><li>Community conventions on using OSGi? </li><ul><li>Common versioning expectations?
  53. 53. Import-Package everywhere? </li></ul><li>Bundle grouping </li><ul><li>“features” - not quite right
  54. 54. OSGi Alliance might help with an “application” notion </li></ul><li>Build infrastructure </li><ul><li>Tooling that builds a target platform from OSGi metadata? </li></ul></ul>
  55. 56. References <ul><li>Artwork: </li><ul><li>Slide 2 boot: , house:
  56. 57. Slide 3 stop: , dancers:
  57. 58. Slide 4 ant:
  58. 59. Slide 8 box: , checkmark:
  59. 60. Slide 15 road:
  60. 61. Slide 16 question mark: </li></ul><li>Content </li><ul><li>EclipseCon 2009 talk:
  61. 62. Version qualifiers thread: </li></ul></ul>