Requirements for a new update manager

From Eclipsepedia

Revision as of 02:09, 26 September 2006 by Pombredanne.nexb.com (Talk | contribs)

Jump to: navigation, search

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.)
    • Regardless of the transport there should be provision to support suspendable/resumable dwonload 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

Tooling

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