Skip to main content
Jump to: navigation, search

Requirements for a new update manager

Revision as of 09:39, 25 September 2006 by Pascal (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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
  • 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)
  • Support for partial updates (aka fix packs)
  • 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.)
  • 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).
  • Translatable metadata
  • Extensible metadata


  • Ability to generate part of the metadata from bundle level dependencies

Back to the top