• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OSGi Sticker Shock   Eclipse Con 2010

OSGi Sticker Shock Eclipse Con 2010



Slides for EclipseCon 2010 presentation.

Slides for EclipseCon 2010 presentation.



Total Views
Views on SlideShare
Embed Views



3 Embeds 67

http://www.eclipsecon.org 63
http://www.slideshare.net 3
http://webcache.googleusercontent.com 1



Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Welcome. Thank you for the opportunity to tell you more about TIBCO and how we can help you. Let me introduce my team….
  • TIBCO is a leading provider of business integration and process management software. I’m going to play a short video that does a great job of highlighting TIBCO’s core capabilities. By being the leading business integration and process management software provider we can help you: Accelerate projects, initiatives and go-to-market cycles We can help you automate and streamline business processes And we can help you improve operational visibility, collaboration and ability to be proactive.

OSGi Sticker Shock   Eclipse Con 2010 OSGi Sticker Shock Eclipse Con 2010 Presentation Transcript

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