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"
(→Governor =) |
(→Installing into the agent (customizing installer)) |
||
Line 70: | Line 70: | ||
Adding function into the agent itself | Adding function into the agent itself | ||
* adding new transports, repositories, touchpoints based on what the user is doing/asking. | * adding new transports, repositories, touchpoints based on what the user is doing/asking. | ||
+ | |||
+ | ==== Resolver [[Image:Progress.gif]] ===== | ||
+ | Current resolver cannot backtrack. We cannot do selection reliably. Do we need a new resolver algorithm? (Pascal) | ||
+ | * Do we need a full resolver? Is there a more constrained problem (e.g., resolving just features) | ||
+ | * Update manager equivalent resolver? | ||
+ | * Can we find a SAT solver that has the right licencse, language, can be used, ... | ||
+ | * need a low bar solution for 3.4. Possibility to extend in the future. | ||
+ | |||
+ | ==== Uses ==== | ||
+ | Do we need to support "uses" clauses in the metadata depenedency | ||
+ | * need support in the resolver/picker and this has proven to be hard | ||
+ | * not doing uses for 3.4 | ||
+ | |||
+ | ==== Advice ==== | ||
+ | The producer/consumer problem needs mechanisms for other people to supply advice on how the agent should behave. See [Equinox P2 Resolution#Limiting the space: advice]. | ||
+ | |||
+ | |||
− | |||
− | |||
− | |||
− | |||
* Security | * Security | ||
** Signatures/authentication for metadata | ** Signatures/authentication for metadata |
Revision as of 12:06, 16 October 2007
This page lays out milestone plans for the development of Equinox p2 in Eclipse 3.4.
Contents
Current Milestone Plan: 3.4 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/John)
- True self hosting:
- Cross-platform:
- Engine:
- Multiple forms of an artifact in a repository (Stefan/Jeff)
- Integrate metadata generation with current build update site generation (dj)
- UI (see more details at Equinox p2 User Interface#Milestone Plan): (Susan)
- Improve workflow and info provided pre-install/update/uninstall
- Polling for automatic updates and user prefs driving how updates are handled
- Improved support for browsing repos (categories, filtering)
- Admin UI shows more info in artifact repo view
- Polish and cleanup
- 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 (John)
- Define 3.3/3.4 compatibility story (Pascal)
- Mechanism to query the user for data (John)
- Replacement for Xstream (Dave)
- Review Director/Engine relationship and API (Pascal)
Questions for M3
Variables
Parameters required at install time, such as port numbers
- Where - in the engine? IU actions
- Why? - for configuration? installation?
- What for? - IU Actions
- Scope?
- When are they actually used?
- are the read/write or read only? who can write?
Nested profiles
Multiple "products" installed together but run independently. Essentially suites of software. Otherwise discussed as Compound Applications
- What are the API changes needed if someone was to do this work?
- Do we really need this in 1.0
Prerequisites
The ability to express dependencies on things other than IUs. For example, hardware, execution environment, ...
- Seems like this is good to do. some sub questions
- how/who to initailize the values? When?
- need new kind of requirement? LDAP filter based?
Governor
What does the governor look like?
- see Bug 205068
Installer
W what does the installer look like?
- How to get the initial install of the agent? JNLP? self-extracting zip, OSGi initial provisioning?
- Should the agent be an installer
- branding the user experience
- installing function/resources into the agent itself
- silent install? (response file)
Installing into the agent (customizing installer)
Adding function into the agent itself
- adding new transports, repositories, touchpoints based on what the user is doing/asking.
Resolver =
Current resolver cannot backtrack. We cannot do selection reliably. Do we need a new resolver algorithm? (Pascal)
- Do we need a full resolver? Is there a more constrained problem (e.g., resolving just features)
- Update manager equivalent resolver?
- Can we find a SAT solver that has the right licencse, language, can be used, ...
- need a low bar solution for 3.4. Possibility to extend in the future.
Uses
Do we need to support "uses" clauses in the metadata depenedency
- need support in the resolver/picker and this has proven to be hard
- not doing uses for 3.4
Advice
The producer/consumer problem needs mechanisms for other people to supply advice on how the agent should behave. See [Equinox P2 Resolution#Limiting the space: advice].
- Security
- Signatures/authentication for metadata
- Simple configurator policy
- Rhino: do we need to replace it? What with? (Simon)
- IU cross reference
- Staged update
- Should versions be pluggable (the current Version class does not allow to properly reason about the version of JRE)
- Multiple processes sharing the same agent data
Future Plans
M4 - December 14, 2007
- API Cleanup
M5 - February 8, 2008
Pending Items
If you are looking to be involved, feel free to pick any item listed below.
- 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
- Size computation: download size, installed size
- Refactor engine/director relationship
- 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)
- 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 p2 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
- Touchpoint data
- Touchpoint actions
- 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
Previous Plans
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
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