Home » Eclipse Projects » Eclipse 4 » Dependency Injection in eclipse plugins (not RCP apps)
Dependency Injection in eclipse plugins (not RCP apps) [message #1033388] |
Thu, 04 April 2013 03:28  |
Eclipse User |
|
|
|
I'm struggling to understand how to use Dependency Injection features in regular eclipse plugins. All of the tutorials out there only mention how to do this in RCP apps, and i seem to misunderstand something fundamentally here.
Here's an example:
1. I have some service POJO class, annotated with @Creatable
2. I want to inject this service into an org.eclipse.core.runtime.jobs.Job, using the @Inject annotation
When i only use these 2 annotations, no service is being injected, and the service is null at runtime.
However, when i implicitly call "ContextInjectionFactory.inject(this, context);" inside the constructor of the Job class, the service is being injected.
Is this the regular way to do this in eclipse plugins? I would have assumed that the Job subclasses are managed by the eclipse context, hence i don't need to manually inject the dependencies.
Any info on that would be greatly appreciated.
|
|
|
Re: Dependency Injection in eclipse plugins (not RCP apps) [message #1033399 is a reply to message #1033388] |
Thu, 04 April 2013 03:41   |
Eclipse User |
|
|
|
DI only works if the instance of the object is created using CIF#make
Tom
On 04.04.13 09:28, Robert Gruendler wrote:
> I'm struggling to understand how to use Dependency Injection features in
> regular eclipse plugins. All of the tutorials out there only mention how
> to do this in RCP apps, and i seem to misunderstand something
> fundamentally here.
>
> Here's an example:
>
> 1. I have some service POJO class, annotated with @Creatable
> 2. I want to inject this service into an
> org.eclipse.core.runtime.jobs.Job, using the @Inject annotation
>
> When i only use these 2 annotations, no service is being injected, and
> the service is null at runtime.
>
> However, when i implicitly call "ContextInjectionFactory.inject(this,
> context);" inside the constructor of the Job class, the service is being
> injected.
>
> Is this the regular way to do this in eclipse plugins? I would have
> assumed that the Job subclasses are managed by the eclipse context,
> hence i don't need to manually inject the dependencies.
>
> Any info on that would be greatly appreciated.
>
>
|
|
| | | | | | | | |
Re: Dependency Injection in eclipse plugins (not RCP apps) [message #1754652 is a reply to message #1033388] |
Tue, 21 February 2017 05:26   |
Eclipse User |
|
|
|
Hi all,
I am digging up this old, dusty thread, because I had a discussion the other day about whether we could start migrating to e4. The problem for us is that we do not develop an RCP but an IDE. So we do not only have views, editors, commands, menu items and the like, but also project natures, builders, common navigator extensions, decorators, property pages etc. etc..
It is clear that for the former stuff, we can create e4-injected POJOs and enhance the application model. But for the latter, which Tom called "old stuff" above , we do not see a clear strategy or best practice on how to do it.
What is/was the thought behind e4 concerning those topics? Was e4 only planned as a an overhaul of the UI part and having all those nice things like DI, the event broker etc. only there?
Because, for any further development of Eclipse and its plug-ins it seems that we are stuck in some kind of middle world between the e4-ified UI world and the legacy-e3 "old stuff" world. So people do not have to learn e3 or e4; they need to learn both and understand when to use either.
So, short questions:
- are there any plans on how Eclipse will move forward regarding the "old stuff"?
- are there any best practices on how to deal with non-UI "old" stuff (builders, natures, adapter factories, team providers, ...) so E4 DI can be used there as well (and because it is not possible out of the box: are there best practices how to enable this with some boiler plate code)?
Any pointers (maybe even to existing documentation I might have missed) are very welcome.
Cheers,
Stefan
|
|
| |
Re: Dependency Injection in eclipse plugins (not RCP apps) [message #1755423 is a reply to message #1755393] |
Fri, 03 March 2017 03:50   |
Eclipse User |
|
|
|
Hi Tom,
I think I understand the background (E4 = RCP/application framework, strive to be (more) independent of SWT ...).
But on the other hand, E4 also introduces a lot more interesting and modern technologies (DI, EventBus, ...) and not to have them in the "core logic" feels like a loss.
This is where my question pointed: Currently new developers have to learn about extension points, OSGi services, and E4 application model enhancements via fragments.
And only in the latter, we are able to use e4 DI. So I have to train new developers (who develop an IDE, not plain RCP) that there is shiny new E4, but also extension points. I have to train them about when to use what and that at the one instance they can (and should) use E4 DI, but in the other instances they can't (or need to add bridge logic* to be able to).
*) and the other question was: are there best practices on how to do it, or should it not be done and we should stick to the old ways?
Best
Stefan
|
|
|
Re: Dependency Injection in eclipse plugins (not RCP apps) [message #1755426 is a reply to message #1755423] |
Fri, 03 March 2017 04:12  |
Eclipse User |
|
|
|
Well the main thing is apparently that the IDE is still based on Eclipse 3.x and running on the compat layer. In my migration attempts I always try to work around extension points and find a way to use OSGi DS as replacement. While extension points where good in the past (I don't want to blame them or say they are bad), there are better possibilities nowadays with OSGi DS (yes I am a fan of that technology).
For preferences I created some small solution based on OSGi DS a while ago, so I can get rid of these extension points also: https://github.com/fipro78/e4-preferences
With Oxygen it will be possible to provide programmatical core expressions instead of the extension points versions (think they are coming with M6).
I'm not sure about everything and all the states and plans, but in my opinion in the long term there should be replacements for all extension points. But that is just my opinion.
|
|
|
Goto Forum:
Current Time: Wed Jul 23 18:02:39 EDT 2025
Powered by FUDForum. Page generated in 0.06010 seconds
|