Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Equinox p2 Engine"

Line 22: Line 22:
 
** What is the order in which phases are executed when IUs are being installed and uninstalled.
 
** What is the order in which phases are executed when IUs are being installed and uninstalled.
  
 +
* Phases:
 +
We currently have two phases, fetch and install. We are thinking of introducing a third one, configure. We likely need others, which one? We should look at what is in SI/SPX and other specs.
 +
 +
* Transaction handling:
 +
** When multiple profiles are being modified in one operation, what is the scope of the transaction.
 
[[Category:Provisioning|Engine]]
 
[[Category:Provisioning|Engine]]
 
[[Category:Equinox|Provisioning Engine]]
 
[[Category:Equinox|Provisioning Engine]]

Revision as of 17:37, 16 August 2007

This page contains random notes and questions about the Engine.

  • Is the engine only invoked for provisioning related operations? For example could it be used to obtain the log file of a particular touchpoint.
    • For not the answer is no. The engine is only used for provisioning related operations.


  • Operations that we need to invoke on the engine:
    • Reboot the targeted touchpoint.
    • Compute the size of things being downloaded. It would invoke the touchpoint to actually know whether or not the IU should be obtained.
    • Validation of checks contained in IUs
    • Qualification, for example discovery of an eclipse install


  • Engine API:
    • The OSGi Deployment Admin service has an interesting API that we should mimic.
    • The parameters passed to the engine does not give us flexibility for other operations than Install and Uninstall.


  • IU processing:
    • Currently the processing is done breadth first, in that first all the IUs are being fetched, then they are all installed and finally configured. Is that too strict? Should we allow for some phases to specify how they should be run?
    • An IU may appear multiple times in an operation and may have different bindings (e.g. different IUs). This allows to process IUs being uninstalled in their "binding" of the past, and it allows to process IUs being installed with their "binding" of the future.
    • What is the order in which phases are executed when IUs are being installed and uninstalled.
  • Phases:

We currently have two phases, fetch and install. We are thinking of introducing a third one, configure. We likely need others, which one? We should look at what is in SI/SPX and other specs.

  • Transaction handling:
    • When multiple profiles are being modified in one operation, what is the scope of the transaction.

Back to the top