Re: [equinox-dev] Extension registry evolution

[Jeff McAffer]

Oleg Besedin wrote: => Single context object <= > I don't like that clients cannot provide more than just one single > "context" object. Good point. I did this for simplicity as having only one argument eliminates the need to match constructor arguments. If we were to support multiple arguments we'd have to add a new construct to the extension point schema - something like <constructor>         <argument position = "1" name = "name_of the_attribute_from_plugin_xml"/>         <argument position = "2" name = "name_of the_attribute_from_plugin_xml"/>         ... </constructor> This is probably worth supporting as an option. I didn't follow the context object discussion it seems like this is a better way to do the initData stuff.  correct?  That is cool.  I wonder as well if dynamic context is on the table?  That is supplying objects in the call the createExecutableExtension call. => Annotations and VM support <= Annotations would be really nice to use. As an example take be the topic above ("single context object"): annotations could have been used to tie constructor arguments to the XML attributes.   However, Eclipse SDK runs on 1.4 and the position of the extension registry in the Eclipse stack does not give us much freedom. We'll have to support pre-1.5 VMs at least in the 3.x stream, there is no choice. As such any functionality based on annotations would have to be optional. Is there [easy] some way we can support annotations if they are there (and we are on an appropriate VM) but otherwise allow people to work without htem? - the extension registry: while it might not look like a conventional DI framework, in spirit it is very similar. The functionality gets obscured by registry artifacts as pieces that gets injected are IConfigurationElements / IExtensions. With this enhancement the actual Java typed objects will be injected using method/field injection; and an optional "context" elements will be injected via constructors.   I entered a bug today to talk about linking the extension lifecycle with that of services (DS) and more of the bundle lifecycle.  This would go a long way IMHO towards making extensions and services intereact better.  That and making it easeier to lookup and inject services into createExecutableExtension and to contribute extensions that are in fact services (e.g., make it easy to use an IExecutableExtensionFactory) Jeff

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev