Bugzilla – Full Text Bug Listing
| Summary: | [prov] manifest flag to "execute on startup" | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | David Williams <david_williams> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | pascal |
| Version: | 3.4 | ||
| Target Milestone: | 3.4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 93219 | ||
|
Description
David Williams
Dare I answer with ideas... Oh ok. There is the osgi.bundles list in config.ini. There you can spec plugins that are run on startup (see the comment in the file for details). If you really were going to do something like this then I would suggest some dedicated plugin that manages such properties and then setting/unsetting them effectively registers/deregisters the values appropriately. Note also that if you are talking about setting system properties then these too can just be set in the config.ini. this file is loaded at runtime and the contained properties put in the system properties list. Jeff mentions the osgi.bundles list in the config.ini. This will work well if you have control over the config.ini that is shipped with a product. But I can imagine in some cases you may be installing your plugins into an existing product for which you do not have control over the the config.ini. In this case you can conceptually do the same thing that Jeff suggests by using the OSGi StartLevel service instead of the osgi.bundles list. This solution would use two plugins. - A "preference setting" bundle would provide the preference page for setting the values. When the user first sets any settings on the preference page this bundle would find the "initial startup" bundle and set its start level to the appropriate level (if the "initial startup" bundle does not require core.runtime then you can set the startlevel to 1 which is the earliest possible start level). After you set the start level of the "initial startup" bundle then you should start it. - An "initial startup" bundle would read whatever settings you set and act appropriately when it is started. This bundle must NOT have the "Eclipse-AutoStart: true" header in its bundle manifest. This will allow it to be persistently started on next launch. On each launch this bundle will get started very early and can read your settings and act accordingly. yup. that's a good approach. One challenge is how the bundle is started (ie., where/when is Bundle.start() called). Assuming the initial install case is handled, what about -clean or updates? Despite our moral resistance to this kind of thing, we should consider possibilities for managing this and other scenarios. A similar discussion has been going on in the equinox-dev mailing list. We should investigate if there is something we can do in 3.3. This is not going to be done in 3.3. Maybe the new provisioning story will come to the rescue and allow us to configure bundles to be persistently started easily. (In reply to comment #5) > This is not going to be done in 3.3. Maybe the new provisioning story will > come to the rescue and allow us to configure bundles to be persistently started > easily. > Which came first, the chicken or the egg? ... :) If that provisioning needs to use a proxy server, getting those preferences to take effect at the right moment may be more important than ever! Thanks for considering (and everyone's comments). p2 allows to associate a start level with a bundle and also to mark it started. I don't think much else is needed here from the initial requirements. Also we have touchpoint actions to add vm args and program args. |