Skip to main content
Jump to: navigation, search

Equinox Summit 2007 Results

Revision as of 15:36, 25 September 2007 by Aniefer.gmail.com (Talk | contribs) (Tooling)

The Equinox Summit 2007 was arranged as a set of lightning talks and a series of breakout sessions. Each session had a number of parallel discussions with self-assigned and self-organizing participants. The groups then reported to a plenary session, summarizing their results and possibly adding more topics to be discussed in further breakouts.

Day One Results

First breakout meeting

Component Programming Models

  • Service helper: ideal for one-time use.
  • Spring
    • Injection model - no code to acquire the service
    • Client is handed a proxy to the service object
    • Framework manages binding of a real service to the proxy dynamically
    • Distinguish between mandatory and optional service requirements
      • Mandatory: your bundle isn't started until all the mandatory services are available
      • This only guarantees availability at a moment in time: at the moment of startup all mandatory services are available, but they could disappear after that moment.
      • If a mandatory service goes away, the services exported by the bundle needing the service is unregistered.
    • For stateful services, there is a listener model - bind an unbind events occur as service implementations arrive and depart
    • It would be interesting to be able to declare a default service implementation that would be used whenever no real service is available
  • Spring and DS require eager activation, but only for service producers. Many bundles are just service consumers, and so they can be lazily started
  • Requirements for Spring service support: Spring core, Spring AOP, a few other essential Spring core pieces
  • Service Application Toolkit: IBM toolkit for making it easier to work with OSGi services
  • How do we reconcile and combine the various component toolkits available: Spring, DS, SAT, extension registry
  • Spring initializes the app context asynchronously. Typical Eclipse programming model assumes that all initialization has completed by the time any classes are loaded in that bundle.
  • To be scalable, we need a model where service wiring is persisted across sessions, so we don't have the massive event storm of services being started and bound as the system comes up.
  • Most bundles are POJO - how do they specify that they need Spring or some other component system to be available at runtime? Ideally 95% of bundles don't know or care about the active component system - but they need some component system to be around at runtime to inject the services they need.
  • Can we come up with a common syntax where a bundle can specify its service and extension registry imports/exports, and be agnostic about the runtime that will parse it and provide the runtime capabilities.
  • Scoping: extension registry / services are global - how can I publish extensions/services that are only available in a particular scope* only particular set of bundles have access to it. In J2EE world, sometimes only want to register/bind services within a particular web app. Scoped registries - local versus global extension registry.

p2 Design Deep Dive

Interesting topics:

  • Profiles/ hierarchy of profiles
  • Headless agent; managed installs
  • Everything is possible
  • Version range lineups,
  • Security? JAAS
  • Resolver - where does it go? when?
  • Plugable download manager
  • Plugable communications - within ECF. replacing ECF?

Tooling (builds)

  • Enhancements to current export
    • pack/unpack/sign support
    • export to multiple targets (exporting platform dependent fragments)
  • Current Export
    • leave behind generated files for debugging purposes
  • Project Builder (can we get this into the pde.incubator)
    • a new builder project (like existing update site project)
    • Provides a mechanism to bootstrap from export to headless build
    • generates artifacts (features/build.properties/customTargets.xml/allElements.xml) that are input into pde.build
    • provides forms/editors (or wizards) to expose pde.build options
    • Consider different inputs : .product file, launch configuration
    • enable gradual discovery of customizability: customTargets.xml, plugin level build callbacks.
    • Synchronization between workspace and plugin level build properties.
  • PDE/Build proper: selected refactorings to make project builder easier
    • remove need for allElements.xml

Server Side Web apps++

Second breakout meeting

Topic 1

Topic 2

Topic 3

Topic 4

Day Two Results

Third breakout meeting

Topic 1

Topic 2

Topic 3

Topic 4

Fourth breakout meeting

Topic 1

Topic 2

Topic 3

Topic 4

Fifth breakout meeting

Topic 1

Topic 2

Topic 3

Topic 4

Back to the top