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 Meetings"
| Line 17: | Line 17: | ||
* John Arthorne | * John Arthorne | ||
* Susan McCourt | * Susan McCourt | ||
| − | * | + | * Dave Stevenson |
* James Miles | * James Miles | ||
* Patrick Dempsey | * Patrick Dempsey | ||
| Line 27: | Line 27: | ||
=== Artifact repository === | === 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. | ||
[[Category:Equinox|Provisioning Weekly Discussion Topics]] | [[Category:Equinox|Provisioning Weekly Discussion Topics]] | ||
[[Category:Provisioning|Weekly Discussion Topics]] | [[Category:Provisioning|Weekly Discussion Topics]] | ||
Revision as of 11:57, 13 August 2007
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 ??
Minutes
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.