Requirements for a new update manager
Revision as of 01:10, 26 September 2006 by Pombredanne.nexb.com
This page lists requirements for a new provisioning story. It volunteerly avoids the mention of any specific technology.
- 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 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