Re: [equinox-dev] Extension registry evolution

[Oleg Besedin <obesedin@xxxxxxxxxx>]

Thank you for the comments, lots of good points. 

=> IRegistryObject <=

> (2) IRegistryObject is odd - can you not split
this into two
> interfaces that we would recommend are being
used whenever objects
> need to be initialized, or disposed?

Yes, this makes sense, let's split it into IDisposable
and IInitializable. 

On the subject of using reflection instead of the
IRegistryObject:

+ it would remove dependency on container code [as
pointed by Heiko]
- it generally makes code harder to read [as pointed
by Gunnar]

Both are good arguments. I think that if we put IDisposable
and IInitializable into "org.eclipse.equinox.common" it might
help with the arguments of having container-dependent code. 

=> Existing DI frameworks <=

> What about existing dependency injection frameworks?
... Wouldn't it
> be good if clients could specify which dependency
injection mechanism
> they would like to be used?

One problem with the current DI frameworks is that
they are complicated to use (some are better than others). Moreover, frameworks
are different enough in the injection styles, bootstrapping, multiplicity
and concurrency support that if we try to provide a common meta-DI framework,
it will end up being something really complicated. Which would be the opposite
of the intention here - providing a simple to use mechanism for simple
everyday tasks.

I did play a bit with the idea of having a DI framework
added on top of the registry. On a design level that seemed to be overdone
as the extension registry in essence is a DI framework that injects data
from extensions into extension points. On an implementation level, from
about half dozen open-source frameworks I looked at, none seemed to be
a good fit. There were multiple reasons, most important being ease of use,
support for pre-1.5 VMs, ability to work with OSGi bundles as containers,
and active community.

So, interesting idea, but I am not sure how practical
it is.

> In Riena we have a simple approach for injecting
extensions into target objects. This is similar to DI but not for services
but for data.

Yes, thank you, I'll look into this.

=> 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.

=> 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.

=> Timeline; E4 <=

> Is there any progress in relation to e4? I understand
that this is a work item on the e4 list.

I think that sometime before the end of 3.5M6 we'll
look at what's available and how stable that code is. Personally, I'd expect
some of the enhancements to get into 3.5, but not all. As for the relation
to E4's dependency injection item - yes, I'd consider this to be one of
the aspects of it. There are two mechanisms in Eclipse that could use improved
DI support: extension registry and OSGi services. I don't think that either
one of them is going to go away any time soon. Rather both have their roles.
For the dependency injection:

- 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.  

- for the OSGi services I believe that Declarative
Services would be the best fit in terms of adding DI mechanism. From the
mailing lists it seems that there is a fair amount of activity both on
PDE tooling support for DS and on the DS itself.

Thanks,
Oleg