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"
(→Current Milestone Plan: 3.4 M3 - November 2, 2007) |
(→Current Milestone Plan: 3.4 M3 - November 2, 2007) |
||
Line 7: | Line 7: | ||
* True self hosting: | * True self hosting: | ||
** [[Image:Ok_green.gif]] Produce regular I-builds and nightly builds of p2 bundles (Kim/DJ) | ** [[Image:Ok_green.gif]] Produce regular I-builds and nightly builds of p2 bundles (Kim/DJ) | ||
− | ** p2 team will update across I-builds using p2 (all) | + | ** (x) p2 team will update across I-builds using p2 (all) |
** PDE target provisioning from bundles.txt | ** PDE target provisioning from bundles.txt | ||
* Cross-platform: | * Cross-platform: | ||
** [[Image:Ok_green.gif]] Build the agent for all platforms (dj) | ** [[Image:Ok_green.gif]] Build the agent for all platforms (dj) | ||
** [[Image:Progress.gif]] Metadata generation for all platforms (dj) | ** [[Image:Progress.gif]] Metadata generation for all platforms (dj) | ||
− | ** Be able to install to any platform/os from a single update site | + | ** (ok for m3) Be able to install to any platform/os from a single update site |
* Engine: | * Engine: | ||
** [[Image:Progress.gif]] Transaction support across phases (Simon) | ** [[Image:Progress.gif]] Transaction support across phases (Simon) | ||
− | * Multiple forms of an artifact in a repository (Stefan/Jeff) | + | * (aim for m3) Multiple forms of an artifact in a repository (Stefan/Jeff) |
* [[Image:Progress.gif]] Integrate metadata generation with current build update site generation (dj) | * [[Image:Progress.gif]] Integrate metadata generation with current build update site generation (dj) | ||
* UI (see more details at [[Equinox p2 User Interface#Milestone Plan]]): (Susan) | * UI (see more details at [[Equinox p2 User Interface#Milestone Plan]]): (Susan) |
Revision as of 11:14, 22 October 2007
This page lays out milestone plans for the development of Equinox p2 in Eclipse 3.4.
Contents
- 1 Current Milestone Plan: 3.4 M3 - November 2, 2007
- 1.1 Questions for M3
- 1.1.1 Variables
- 1.1.2 Nested profiles
- 1.1.3 Prerequisites
- 1.1.4 Governor
- 1.1.5 Installer
- 1.1.6 Installing into the agent (customizing installer)
- 1.1.7 Resolver
- 1.1.8 Advice
- 1.1.9 Security
- 1.1.10 Simple configurator policy
- 1.1.11 Locating files
- 1.1.12 Sequenced update
- 1.1.13 Reasoning about versions
- 1.1.14 Shared Agent data access
- 1.1.15 Advising the metadata generator
- 1.1.16 Revise capabilities model
- 1.1 Questions for M3
- 2 Future Plans
- 3 Previous Plans
- 4 Legend
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:
- (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)
- 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)
- 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?
- 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
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. 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
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
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