Bugzilla – Full Text Bug Listing
| Summary: | [SC] Create a customizer service in simple configurator | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Borislav Kapukaranov <b.kapukaranov> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED INVALID | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | glyn.normington, katya.stoycheva, pascal, tjwatson | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Borislav Kapukaranov
Created attachment 201420 [details]
region customizer example
I have not been able to apply the patch. My main concern here for the user of this new service is to guarantee that the bundle providing the customizer service is up before SC is starting. IIRC equinox.fwkadmin handles that cleanly but you want to check that it is the case. I just applied it on a clean clone. Use "git apply region_customizer_service.patch" with the patch located in the root folder of the p2 repo. It produces some whitespace warnings but don't worry about them :) Note that "git am < region_customizer_service.patch" won't work as the patch is produced of diff between the last commit and what's staged and not of an actual commit so it doesn't have any commit data(author, e-mail). (In reply to comment #2) > I have not been able to apply the patch. My main concern here for the user of > this new service is to guarantee that the bundle providing the customizer > service is up before SC is starting. If we take the region use case in mind then it's clear the region bundle will have to start surely before SC(before any installs take place). That basically means you already have a custom product: region bundle on SL1 and SC on SL2. In such case it is trivial for a user who already created that custom product to add the service provider on SL1 as well. The nature of the scenario is completely optional so it won't affect the normal SC operations in any way if a service provider isn't available. The idea is to get a chance to perform pre-install customizations from which all users with custom setups(not eclipse-like) may benefit. This can be exploited by various use cases and isn't necessarily restricted to regions support. So in a more general sense the right way to guarantee the order is to have a product with SC on SL2 and the service provider on SL1. I can document this extensively on the wiki with examples on how to use it to prevent confusion. > IIRC equinox.fwkadmin handles that cleanly but you want to check that it is the > case. I looked at the code. Here are a few comments: - Does anything need to be done on uninstall? - The service is obtained every time. Why not cache it for the duration of the installation? - The service is never released We've taken a new direction with the Virgo-p2 integration. Therefore we won't need that change anymore and have decided that we can focus on topics that are aligned and will benefit the p2 community more. If you think that this enhancement is still useful and beneficial to the community I'd be more than happy to work it through, otherwise feel free to close the bug. (In reply to comment #5) > We've taken a new direction with the Virgo-p2 integration. Therefore we won't > need that change anymore and have decided that we can focus on topics that are > aligned and will benefit the p2 community more. I'm dying to know more about that :) > If you think that this enhancement is still useful and beneficial to the > community I'd be more than happy to work it through, otherwise feel free to > close the bug. At this point, I'll close this bug as wont fix. We can always reopen it later if needed |