Community
Participate
Working Groups
I would like to suggest to move the @Service annotation from e(fx)clipse to the platform. https://wiki.eclipse.org/Efxclipse/Runtime/Recipes#Injection_of_OSGi-Services IMHO it is a very useful annotation to get OSGi services injected in a DS comparable way.
@Tom Could you please link to the sources in e(fx)clipse? We should also discuss where to put the necessary implementation classes.
As per discussion in Bug 510292 I would like to discuss in this ticket where the @Service annotation should be put to. I see two options: - org.eclipse.e4.core.di.annotations The implementation will then be in org.eclipse.e4.core.di. - org.eclipse.e4.core.di.extensions The implementation will then be in org.eclipse.e4.core.di.extensions.supplier (if Bug 463613 is fixed with the patch I provided). I'm unsure where to put it actually. There are good arguments for and against any of these options. core.di.annotations because @Service would be a good candidate for a core annotation as working with services is (or IMHO should be) a common practice. core.di.extensions because @Service is resolved by using an ExtendedObjectSupplier. So injection with @Service only works in combination with @Inject. Therefore it is an extension and not a core annotation like @CanExecute or @Execute. Any thoughts?
I am only +1 if the annotation is actually used withing the Platform.
(In reply to Dani Megert from comment #3) > I am only +1 if the annotation is actually used withing the Platform. Hm, that would be a hard one as of now. AFAIK we don't have competing services in the platform and therefore no actual need for it on that level. From my point of view that annotation increases the usability of OSGi DS in an Eclipse RCP application, as it provides functionality to retrieve multiple services of a type and with its newest addition even filters, which we don't support with the default injection mechanisms. So it is intended to be used to connect the UI layer with the OSGi layer, by avoiding that users have to use low-level OSGi API to consume services. In the end it could even help on getting rid of more Activators that are currently used to retrieve services.
(In reply to Dani Megert from comment #3) > I am only +1 if the annotation is actually used withing the Platform. Having more control about the injection of OSGi services is a very common requirement in RCP applications. We usually use the "low-level" OSGi API for that in our RCP applications. +1 for adding this to the DI framework.
New Gerrit change created: https://git.eclipse.org/r/90682
Gerrit change https://git.eclipse.org/r/90682 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=cd9a6baa35098e9888da8a59d1ff27a779e29cb0
Fixed with applied patch
