Difference between revisions of "Equinox p2 Plan"

Revision as of 11:05, 1 October 2007

This page lays out milestone plans for the development of the Equinox Provisioning system (p2) in Eclipse 3.4.

Plan

M1 - August 2, 2007

Goals:

• Operations supported: install, uninstall, update, rollback.
• Self provisioning from a small download of the agent
• The agent runs in process

Details:

• Director / metadata:
  • Implement groups and selectors
  • Define constraints descriptors
  • Refine how fragments are being attached

• Engine:
  • Define new phases and operations.

• UI:
  • Browse what's installed in a profile
  • Invoke operations
  • Browse a repository

• First run integration: ability to ship metadata / artifact repo / profile with eclipse
• Investigate shared install problems

M2 - September 21, 2007

Goals:

• Updating the running profile (self update with a reasonable UI)
• Support for update / rollback in the director
• Support for transaction in the engine

Details:

• Director / metadata:
  • Implement groups and selectors
  • Refine and implement constraints descriptors

• Engine:
  • Support for transaction

• UI:
  • End user UI to install and update
  • Presentation of metadata repo content to the user

• Misc
  • Move to ECF 1.0.2
  • Support for relative paths
  • Review the usage of framework admin:
    • How are we using it?
    • Why do we use it, what does it bring?
  • Discover the JRE being used to run

• Shared install:
  • Initial implementation

• Repository:
  • Support for filtering content presented to the user
  • Make the artifact repository writable and have support for post-processing
  • Have an artifact repository implementation to read update sites

M3 - November 2, 2007

• Establish concrete set of functionality to be available in 3.4 final
• Perform rename of bundles and packages to the new name: p2. Updating wiki pages and other documents accordingly (dj)
• True self hosting:
  • Produce regular I-builds and nightly builds of p2 bundles (Kim/DJ)
  • p2 team will update across I-builds using p2 (all)
  • PDE target provisioning from bundles.txt
• Cross-platform:
  • Build the agent for all platforms (dj)
  • Metadata generation for all platforms (dj)
  • Be able to install to any platform/os from a single update site
• Engine:
  • Transaction support across phases
• Multiple forms of an artifact in a repository (Stefan/Jeff)
• Integrate metadata generation with current build update site generation (dj)
• Polish end-user UI work flows (Susan)
• Shared install (AndrewO, Tim)
• Pluggable download manager strategy (Tim)
• ECF support for pause/resume (Scott)
• ECF support for introspecting transports (throughput, latency) (Scott)
• Review Framework admin API, and usage of Framework admin in p2
• Define 3.3/3.4 compatibility story

M4 - December 14, 2007

M5 - February 8, 2008

Pending Items

If you are looking to be involved, feel free to pick any item listed below.

Questions for M3:

• Variables - parameters required at install time, such as port numbers
• Nested profiles - multiple products installed together but run independently
• Prerequisites
• Governor - What does the governor look like?
• Installer - what does the installer look like?
• Branding experience for install
• Installing into the agent (customizing installer)
• Resolver - can't backtrack, do we need a new resolver algorithm?
• Metadata shape
  • Uses
  • Advice (aka recommendations)
  • Signatures/authentication for metadata
• Simple configurator policy
• Replacement for Xstream
• Rhino: do we need to replace it? What with?
• IU cross reference
• Staged update

New items:

• Refactor engine/director relationship
• Size computation: download size, installed size
• Touchpoint data
• Touchpoint actions

Old items:

• Artifact repo
  • partial downloads of new jars
  • Resilience to dl failures
  • Ability to restart failed download

• Engine
  • undo/redo API
  • touchpoint API
  • define more phases and how phases are ordered, review Dave idea where everything is an operation
  • engine API

• Director / Metadata
  • fixes
  • translation
  • disable (==> uninstall but keep the metadata and artifacts)?
  • variable / prerequisites / checks
  • default selectors
  • nested profiles
  • Refine how fragments are being attached
  • Refine how operations to the engine are being constructed

• Security
  • artifact validation
  • trust
  • signature check (disabled in trusted site)
  • How to interact with user during signature check - do we need changes to ProcessingStep API

• Transports
  • proxy
  • authentication
  • https
  • socks
  • automatic retries
  • automatic picking of mirrors
  • download time estimation
  • suspend/resume
  • download in parallel

• Misc:
  • Shared install scenarios
  • Discovery mechanism for non eclipse things (JRE)
  • Mechanism to query the user for data
  • Make the agent dynamic
  • Scalability: review the data structure and API for scalability
  • Review the usage of rhino
  • Review the usage of xstream

• GC
  • Ability to remove metadata from the metadata cache
  • Ability to remove a plug-in from the bundle pool

• Tooling
  • Mechanism to ship the install registry, artifact reg, etc. as part of the SDK

• End user functionality (see also Equinox Provisioning User Interface)
  • Improved way to present licenses
  • Remember accepted licenses
  • Give the ability to name what is being installed
  • Installation by drag and drop on a running eclipse
  • Automatic installation
  • Ability to update to a new version of a base and keep other plug-ins
  • Ability to install from other eclipse installs on the machine
  • Install from a click on the web page
  • Silent (headless) installation
  • Support installation even when there are errors in the configuration

• Touchpoints
  • Support for discovering files to allow for configuration
  • Native touchpoint
    • Implement a native touchpoint
  • Java touchpoint
    • Define the relationship between java touchpoint and eclipse touchpoint
  • Rename Eclipse touchpoint to OSGi touchpoint