Re: [equinox-dev] Extension registry evolution

["Boris Bokowski" <bokowski@xxxxxxxxx>]

On Mon, Sep 29, 2008 at 2:51 PM, Oleg Besedin <obesedin@xxxxxxxxxx> 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.

Looks too static to me. I don't want to prescribe how the third party
constructor looks like, I just want to list what kinds of services
they can expect to be getting through constructor injection. So for
example one view might only need the parent composite, and another
might need the parent composite, the adapter manager, and the
selection service.

Jeff wrote:
> I wonder as well if dynamic context is on the table?  That is supplying objects in the call the createExecutableExtension call.

Yes, that would be very important to us because otherwise we wouldn't
be able to pass the parent composite.

Jeff wrote:
> 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?

Maybe I am missing something, but to me a solution for this seems to
be to make the mechanism for doing the injection pluggable. What I
mean by this is that if I have annotations suitable for Spring (or
Guice), as someone contributing an extension I should be able to
specify "use the Spring (or Guice) DI framework for instantiating my
object" - this woud keep us out of the business of having to define
those annotations as well.

Boris