Community
Participate
Working Groups
In bug #221513, we enable the classic update activity when we discover there is no self profile. It would be nice to disable the p2 UI in this case, or we'll have duplicate Software Updates contributions on the help menu. I figured Tim would know the best way to do this? Do we need another activity for p2 support or is there a better way to disable it? Note this only affects builds that contain p2 but are not p2-ized.
An activity seems like the best solution for this. I guess programmatically set the activities to enable the classic update or the p2 UI and disable the other activity according the existence of the self-profile.
activities would have been the way to go, but after further discussion, we're not going to enable classic update when a "non p2-ized p2" is running.
Sorry, I did not follow/see the original discussion. Are there any cases where the p2 UI needs to be hidden? It might be good to have the possibility in case there is some critical error/issue where p2 is not working for some case. the advice woul dbe to disable it and run the UM UI. Or is this something different?
The context where this came up was in an install that is not p2-enabled (no p2 dir, bundles.info, etc), but contains the p2 bundles. For example, if you installed p2 bundles into Eclipse 3.3. This case came up briefly when we were integrating with the SDK, and we had the non p2-enabled zips that contains p2 bundles. The problem here is that p2 is completely broken - there is no "self" profile and it can't reason about the running system. The thinking was that we could magically make the p2 UI disappear in this case, and bring back classic UM. There are quite a few details to getting this right, and we decided it's not worth it to handle this scenario gracefully. If your platform is not p2-enabled (no p2 profile or metadata), then don't install the p2 plugins. If the p2 plugins are not installed, UM will automatically reappear (since it's hidden by an activity defined in p2 UI bundle). The case of getting rid of p2 in case of critical errors/issues is actually more complicated, because eclipse.ini/config.ini, etc are configured for p2 and would have to be modified to get back classic UM behavior. In this case the current advice is to follow steps in http://wiki.eclipse.org/Equinox_p2_Removal.
thakns for the detail John. for the UI disablement I was thinking of cases where p2 itself was fine but there was something in the UI/workflow that was messed up and so the user wanted to install using the UM UI. the platform.xml synchronizer etc would kick in to keep p2 happy etc. That feels pretty fringe so we may not need to worry about it.
