Community
Participate
Working Groups
I would like to extend the RSECoreRegistry to accept system types from other source than the system type extension point only. Contributors willing to contribute system types dynamically, can register IRSESystemTypeProvider implementations via an additional extension point. The IRSESystemTypeProvider does have exactly one method: IRSESystemType[] getSystemTypesForRegistration(); System type contributions from the system type extension point have higher priority and will be read always before the IRSESystemTypeProvider will be called. System Types from the IRSESystemTypeProvider conflicting with a contributed system type (having the same id) will be not accepted and are skipped. The IRSESystemTypeProvider is responsible that calls to IRSESystemType.getProperty(...) are correctly mapped for the 3 public system type properties as defined in IRSESystemTypeConstants. From RSE point of view, absolutly nothing will change from API point of view, RSECoreRegistry.getDefault().getSytemTypes() is returning the full list of registered system types, with or without this extension. The purpose of this extension is to allow adaptors of RSE to generate RSE system types dynamically from existing similar objects in their existing product. It decreases the administrative effort to initial jump on top of RSE and helps maintaining existing contributions to the adapted product. Furthermore it reduces the complexity of contributing to the adapted products which will definitly reduces the possible sources of errors and frustration which in turn is essential for the acceptance level of RSE itself (for adaptors) and RSE based products (for contributors). In our specific case we want to keep the impact of switching our product to RSE for existing internal and external contributions at absolute minimum. Being able to contribute system types dynamically keeps our existing contributor base happy and their contributions working for our product prior the switch to RSE and for our products after the switch to RSE. It is not required for them to maintain multiple source bases to support the full range of product versions still being in maintenance. PS: This very small impact extension solves basically the bugzillas 170918 and 161193 ...
Kushal and Dave -- The registry is mostly yours. On the face of it this sounds really good. What do you think?
I basically like the idea of contributing system types dynamically, although I wonder subsystems would register against a dynamically contributed system types. For me, it looks like this proposal calls for a change to dyanmically register subsystemConfigurations as well. Like with all dynamic contribution, I'm wondering whether an API might be more applicable than an extension point. There might be some kind of generic "earlyStartup" extension point, which is called just before RSE uses any system types. This code could then call RSE API to inject the new systemTypes (e.g. SystemRegistry.addSystemType(...). That much for discussion - I'm not convinced that such API is better than an extension point in this case, because of timing considerations (systemTypes need to be available VERY early). I think that Eclipse Platform also has some examples where they allow both static and dynamic contribution of some elements, this should perhaps be checked. If we go with the extension point, I'd recommend extending the current "org.eclipse.rse.core.systemTypes" extension point rather than defining a new one. The current extension point could contain a sequence of (optional) "systemType" tags AND a sequence of (optional) "systemTypeProvider" or "systemTypeFactory" tags.
Comment to extension point vs. API: I think an extension point is better than API. API is basically a "push" system. Some one planing to contribute generated system types, would need to enforce the plugin activation to get ever a chance to call the API. That is IMHO against Eclipse concepts and is furthermore badly effecting Eclipse startup as far to much plugins will get activated very early. Using an extension point is a "pull" system. The plugin activation of the contributors is delayed to the time the extension point provider is instanciating the classes. API and extension point are not mutual exclusive, but API is required only if the list of system types should be modifyable after the initialization. This is not the scope of the proposed extension, the list of known system types is still static after the initialization. The proposed extension only increases the sources the initialization process is getting the system types from. Once registered it cannot be unregistered again and new ones cannot appear.
(In reply to comment #3) > Extension point vs. API: You found the arguments I was looking for. I totally agree. How do you see the need for dynamic contribution of subsystemConfigurations? Or could it be sufficient to introduce a concept of systemType X is "compatible" with systemType Y, or subsystemConfiguration registering itself against String patterns of systemType?
I think it would be enough if the id requested for subsystem registration (bugzilla #162081") could take a pattern like "com.windriver.ide.*". It would gracefully solve it :).
A little caveat with the dynamic approach is that 3rd parties, who want to register their own new subsystem against a systemType that is being dynamically provided, cannot easily find out the id they need to contribute against. Any ideas how to address this? With statically provided system types, 3rd parties can get an installed version of the product, look at the IDs being present in the plugin.xml's, and write their own contributions against them. In the long run, I guess that such 3rd party additions of subsystems would probably take a more service-oriented or property-oriented approach rather than registering against a well-known systemType id. They could, for instance, register against "any systemType that has tcp/ip and a shell subsystem and a /proc filesystem compatible with linux". This is part of the initiative to make RSE more service oriented (bug 150498), but it may take some time until we are there (and we'll want dynamic systemTypes before that).
Well, we could be very programatic: Warnings are printed to the error log if the registration of a system type fails because of non-unique id in example. It would be no deal to print an Information message to the error log if an system type has been successfully registered (containing the name and the id). 3rd parties can adjust the RSE logging level to include the information messages and can get the id's from there.
Contribution has been commited as proposed.
Closing [api] bugs that have apparently been fixed in the code.
[target cleanup] 2.0 M5 was the original target milestone for this bug
