Requirements for a new update manager

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)

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