Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox p2 Plan"
(→Pending Items) |
(→Pending Items) |
||
Line 114: | Line 114: | ||
* Touchpoint actions | * Touchpoint actions | ||
− | Old items: | + | '''Old items''': |
* Artifact repo | * Artifact repo | ||
** partial downloads of new jars | ** partial downloads of new jars |
Revision as of 11:06, 1 October 2007
This page lays out milestone plans for the development of the Equinox Provisioning system (p2) in Eclipse 3.4.
Contents
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