Community
Participate
Working Groups
Currently, only RSESystemTypeAdapter#isEnabled() can be used to check whether a given system type is currently enabled. The problem with this is, that it binds enablement info to plugins that live in the UI space only. I think that also plain non-UI plugins should be able to filter out system types which are statically configured but not currently enabled. In order to support this, IRSESystemType#isEnabled() should be provided instead of RSESystemTypeAdapter#isEnabled(). This is also a prerequisite for moving the SystemRegistry implementation into non-UI as per bug 215820. Note that extenders who provide their own implementations by subclassing AbstractRSESystemType may want to use this functionality to also change enablement based on available licensing and the like.
Created attachment 89520 [details] Patch making the change Attached patch makes the requested change. I think it is important that the notion of whether a system type is enabled or not is always consistent. There should not be a difference between "enabled for non-UI plugins" versus "enabled for UI visibility". Therefore, this is a breaking API change: extenders which used to provide their own subclass of RSESystemType along with their own subclass of RSESystemTypeAdapter and their own isEnabled() method would return proper enablement only to UI plugins, but not to non-UI plugins querying the IRSESystemType directly. Such clients need to move the code that they used to have in their RSESystemTypeAdapter subclass into their AbstractRSESystemType subclass instead. In order to force them make this change, RSESystemTypeAdapter#isEnabled() has been marked final in this patch, such that extenders who used to override the method are notified of the required change by means of a compiler error.
Patch committed, please review: [218655][api] Provide SystemType enablement info in non-UI IRSESystemType AbstractRSESystemType RSESystemTypeAdapter SystemPreferencesManager Note that I can back out the change if requested.
