Skip to main content
Jump to: navigation, search

Requirements for a new update manager

Revision as of 01:16, 26 September 2006 by (Talk | contribs) (Tooling)

This page lists requirements for a new provisioning story. It volunteerly avoids the mention of any specific technology.

Functional requirements

  • Provision bundles as well as "root files" (startup.jar, exe, etc.)
  • Provision groups of bundles
  • Provision single bundles
  • Provision non running configuration (manage multiple configurations)
  • Check the validity of the system before installing (a user should know whether the bundles it installs will resolve or not)
  • Transparent provisioning of dependent bundles (in case of a mismatch, missing dependencies should support be updated)
  • Support rollback in case of failure during the install
  • Transparent support for mirrors
    • including the ability to support various pluggable mirror selection techniques (i.e. locale, round robin, speed, etc) Philippe O.
  • Shared pool of plugins (multiple eclipse based products should be able to share the same bundles on disk).
  • Ability to process data on install (e.g. workspace metadata)
    • do you mean by that: metadata update? or preferences provisioning? or both? Philippe O.
  • Support for partial updates (aka fix packs)
    • would you see that go at a lower granularity than a bundle? Philippe O.
  • Integrate nicely with JNLP deployed systems
  • Integration with other provisioning technologies
  • Support bundle level configurability (set bundle start level, auto start, ini file)

Provisioning platform requirements

  • Separation metadata server / byte server
  • Flexible layout of bytes on the "byte server" (for example it is sometimes more interesting to download a big zip than many small zips)
  • Pluggable transports (Http, ftp, etc.)
    • Regardless of the transport there should be provision to support suspendable/resumable transfer of bytes, for those transports and byte servers that support it. Philippe O.
  • Metadata for grouping should have an extensible filtering mechanism (e.g. os=win32)
  • Ability to express dependencies on other things than bundles (e.g JRE >= 1.5).
    • When metadata are used to express filtering or dependencies, they should have at least the same expressing power of OSGi related mechanisms.Philippe O.
  • NLS support for metadata
  • Extensible metadata


  • Ability to generate part of the metadata from bundle level dependencies
  • Ability to provide checks and issue warning when depdencies are expressed on things which are packaged by others Philippe O.

Back to the top