Difference between revisions of "Equinox p2 Plan"

Revision as of 14:37, 25 October 2007

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

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:
  • Produce regular I-builds and nightly builds of p2 bundles (Kim/DJ)
  • (defer) 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)
  • (ok for m3) Be able to install to any platform/os from a single update site
• Engine:
  • Transaction support across phases (Simon)
• (aim for m3) 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
  • (slip to M4)Improved support for browsing repos (categories, filtering)
  • Admin UI shows more info in artifact repo view
  • Polish and cleanup
• (should have basics in for M3) 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)
• (slip to M4) Define 3.3/3.4 compatibility story (Pascal)
• (risk of slip) Replacement for Xstream (Dave)
• Review Director/Engine relationship and API (Pascal+Susan)

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?
• Mechanism to query the user for data

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

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. Advice may not come in the same form as IUs etc.

• when can advice be supplied?
  • Must be defined at the beginning of resolution. Otherwise we would be in a dynamic advice situation (see below).
• where does advice come from
  • top level IU?
  • side files etc?
• Version control - should be able to do
• Adding requirements (Causality) - essentially adding new requirements on other IUs
  • how does this relate to fragments
  • related to eager optional requirements
  • should be able to do this one
• Uses
  • see above, not likely to do
• Affinities
  • seems related to uses. Similarly then it is unclear how we can implement this now.
• Dynamic Advice
  • no

Security

Various levels of security

• JAR signuture verification - Yes
• MD5 hash verification - yes
• signatures on IUs themselves - not now
• secure transports (HTTPS, ...) - yes
• Repository trust - rudimentary facilities
  • signed repositories/certificates on server - yes
  • white/black lists - yes
• login - yes

Simple configurator policy

Whether or not the simple configurator should play nicely with others who call installBundle()

• not sure what the implications would be
• seems harsh to simply uninstall things that we don't know about
• have an option to play nice - yes but you what you asked for.
• do something simple not involving state resolution and optimization. Just whether or not to uninstlal things that SC did not install.

Locating files

The ability for to find where a file was put during the install. Example you might need to know where the java.exe is so it can update a script. This is somewhat related to variables but has a different flavour/approach. An extension of this is the ability of one IU to look for files from another IU.

• Actions have to participate by letting the system know where it put files or by offering to help find files when someone is looking for them
• Ask Andrew how this works in RPM etc
• Locating files within one IU - yes
• Locating files across IUs - maybe Try to do something at least basic here.

Sequenced update

Expressing the need to update along a certain path. For example, updating from Foo 1.0 to Foo 1.2 may require that you update to Foo 1.1 first and then update to Foo 1.2. For example to get some data transformations run that are only available in Foo 1.1.

• Need for a new kind of dependency to express the path. for example Foo 1.1 needs to say that it can update Foo 1.0 whereas Foo 1.2 would say it can update Foo 1.1.
• should try to do something here if it is reasonably easy

Reasoning about versions

How do you reason about version numbers that are in different formats. For example, the current Version class does not allow to properly reason about the version of JRE.

• Two approaches
  • Make versions representation/logic pluggable.
  • canonicalize the version number schemes in terms of the base Version scheme
• Do the second approach (canonicalization) for now

Shared Agent data access

If there are multple Agents running all using the same data area we need to protect the actual data files. This can happen for exapmle when you have several p2 enabled applications running where each has the agent code in it.

• Seems like a real usecase
• need to do something at least basic here.

Advising the metadata generator

Allow people to advise the metadata generator to add various dependencies, configuration information, ... as the metadata and artifacts are generated.

• This is a must have

Revise capabilities model

Right now the capabilities model mixes meta-level capabilities (e.g., declaring the IU type) with base-level capabilities (e.g., exporting a package). This is convenient but makes it hard to reason about the IU.

• Must do something here.

tooling

self hosting

Future Plans

M4 - December 14, 2007

• API Cleanup
• UI
  • Preferences for reminding user of available updates Bug 207493
  • Improved support for browsing repos
    • IU categories Bug 203115
    • Filtering of available IU view Bug 204826
    • Polish items for quick repo entry Bug 207220
    • Browse from web page?
  • UI for Revert Bug 205223
  • Improved way to present licenses and remember accepted licenses Bug 205232

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

Legend

Needs some investigation

Patch in progress

Bug fixed / Feature added