Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Equinox p2 Meetings
Contents
Week of 20070820
Agenda
- We need a lot of events, some are core to the functioning of the system, others are to help drive the UI. Currently we have our own event bus. Should we migrate to the osgi event service?
Week of 20070813
Agenda
- Separation of concerns around the artifact repository (https://bugs.eclipse.org/bugs/show_bug.cgi?id=197644).
- Shared install:
- How much of the things noted in the discussion (http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02692.html) are provisioning related vs runtime related (location of preferences, log files, cache, etc.)
- Controlling the Engine:
- The engine currently takes an operation to install, or uninstall IUs. Can this separation of installation / uninstallation / update / etc. be kept? How do we reconcile?
Attendees
- DJ Houghton
- Jeff McAffer
- Simon Kaegi
- Pascal Rapicault
- John Arthorne
- Susan McCourt
- Dave Stevenson
- James Miles
- Patrick Dempsey
- Stefan Liebig
- Ted Habeck
- Joe Rusnak
Minutes
We initially attempted an Asterisk conference call, but the line quality was not acceptable. We moved all participants to a private number until we find an acceptable way to do a public call.
Artifact repository
We need to be able to perform post-processing steps after download, such as unpack-200, re-assembling compressed deltas. Should the repository be aware of these post-processing steps, or should it be done independently? When mirroring between repositories, some post-processing steps are not necessary (for example unpacking zips/jars
In our discussion, we distinguish between original bytes (as they are added to the repository from build system), and stored bytes (the actual bytes stored on disk in the repository). When mirroring between repositories it is more efficient to directly mirror the stored bytes, rather than the original bytes.
We should have different artifact descriptors for each available representation of an artifact (jarred version, delta compressed version, etc). Leave it up to download manager or some other entity on the client to decide which artifact descriptor it wants to load for its current circumstances. The artifact key uniquely identifies the original bytes, whereas the artifact descriptor identifies various flavors of stored bytes.
Two main methods for artifact repository API: getArtifactBytes(IArtifactKey), returning the "original bytes", and getArtfactDescriptors(IArtifactKey), which returns all the available descriptors corresponding to the given key.
Tangible next steps are to implement post-processing steps for pack200 and signature verification.
Discussion skipped because Andrew Overholt is leading this work and wasn't present
Engine discussion
Currently the engine API only allows a single operation to be performed at once. We may want to be able to pass a batch of operations to the engine and have them be performed together (atomically).
Currently the interesting units are ProvisioningOperand and Phase. An EngineOperation just provides an ordered list of phases. The operands actually provide the interesting behavior (install, uninstall, update).
Could we specify the engine API instead in terms of states, and an operation is just a request to transition from one state to another. The precise phases required for that state transition are implementation details.
On a multi-user install, some phases are no-ops because they have already been performed before by another user.