Spring with Eclipse RCP anyone?

[cptechno]

Hi,

I'm interested to integrate Spring into Eclipse RCP so that the actions can be wired up automagically by Spring.

I would like to know if anyone tried this?
Or else, at least, is there any pointers for my further exploration?

TIA,
Raymond

[Martin Kersten]

I have considered to do so too. The problem is, everything in Eclipse is a contribution. So everything should be specified by the plugin.xml. 'Contributing' actions or anything like that, without using plugin.xml would violate the 'Everything is a contribution' rule(?).

I end up to specify only the domain related parts using Spring (Model and some controllers). I am also using a custom dependency injection solution (simply using marker interfaces) for injecting dependencies of contributed elements. Works well.

If you make further progress, please drop me a note.


Cheers,

Martin (Kersten)

[Keith Donald]

Martin,

I'd be interested in seeing your approach here. Could you by chance send me or post a sample of you using Eclipse RCP with Spring to connect Eclipse Actions and UI objects to middle tier services wired up using Spring?

[Martin Kersten]

I've talked about the domain related code. You can think about it, as the core you would write if you have to provide both, a Swing and a SWT GUI. You know all the domain-logic (meaning, model, commands, undo/redo, selection etc.) is wired up using Spring. There is no Eclipse related stuff configured using Spring. Eclipse's RCP code is than used to present the model and trigger the domain-logic related actions.

For example, the logic of an action is Eclipse RCP independent and therefore is part of the Spring stuff. An contributed action (contributed using plugin.xml) simply warps those domain actions, being able to trigger the action and/or provide dialogs/wizards to configure the action.

So you may think about the Eclipse RCP as a diffrent world triggering domain-behaviour and reacting to the domain-model.

It worked best to seperate both worlds using two diffrent projects. One is the client.domain (plugin-)project and the other is the client.ui plugin providing ui and connectors like content-provider.

Testing the client.domain stuff is done using plain jUnit tests (no Plugin-jUnit tests). And it should also do not require any Eclipse plug-ins. It helped alot to speed development. So the client.ui and client.domain are clearly seperated.

[Keith Donald]

I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.

I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.

Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!

[Martin Kersten]

I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.

I didn't evaluated it in depth.

I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.

It's quite simple (like any MVC stuff). First you add some logic to the ui layer. Remove the ui-dependencies as much as possible and let it drip down to the model/controller part of the domain-layer. Thats all. There isn't much fuzz about it.

Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!

There really isn't much to do. Mostly content-provider, actions and dialog logic are important. Also some high-level business logic needs to be utilized by the UI stuff. It's quite normal TDD going on.

If you have a question or anything you are fighting with, just ask me a certain question but in general it's like programming an UI application and think the way:"If I am also writing a Swing application, what logic would I like to reuse." That's it. Nothing more. Well beside having a undo/redo stuff etc. But this is also normal domain-layer stuff - so nothing to be excited about.

[cptechno]

So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?

This method is good, just I want to enable IoC on these "contributions" for Eclipse too.

I did looked a bit at Eclipse's source code. It seems that only Eclipse's WorkbenchAdvisor can be a customized implementation; others are not, including the factory classes for instantiating Views, Perspectives, Actions, etc.

If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.

Any ideas on this one?

Thanks again,
cptechno

[Martin Kersten]

So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?

It looks like. But providing aid for doing so, is much productive.

This method is good, just I want to enable IoC on these "contributions" for Eclipse too.

I use dependency injection using a context. The context is bound to the plugin class (and hidden).

So it ends up:

MyPlugin.injectDependencies(Object);

The context used by MyPlugin to inject the dependencies is configured using Spring. That's how everything is connected. If a view is created it injects it dependency on it's own (same for action, providers etc.) or if a contribution to an extension-point definied by MyPlugin is instanciated/initialized it gets its dependencies injected transparently by MyPlugin.

Thats how I tie all code together.

If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.

Maybe a factory can be seen like the dependency injection I use. You know creating a two parted solution. For example: you may define a view within Spring, setting the properties and also contribute a view using plugin.xml. Since the view is extended using a Spring RCP abstract view, it will look for a bean-definition and automatically set the properties like specified. For the user of this view, it would be absolutly transparent how the properties got injected.

Maybe the id's should be in sync meaning contributing the view: 'org.spring.view.MyView' and the corresponding context item being 'org.spring.view.MyView' (ergo the same). This can be also done with labels etc. Just store the values within such a Spring RCP definition object and on creation inject the properties.

This comes by the cost using additional JFace / SWT components - I think some are not intended to be subclassed anyway, so a property-injection facility must be provided anyway.

I guess this solution may be an great step forward compared to my dependency injection which also work great, anyway.

The above idea is very promessing. I guess I would like to join your subproject and provide some contribution and also comments and stuff. So I you like, I would like to join your project as a minior developer. (since the outcome of your affords seams to provide some value for me :-) )

[cptechno]

I use dependency injection using a context. The context is bound to the plugin class (and hidden).

So it ends up:

MyPlugin.injectDependencies(Object);

This should be what I'm looking for. However:

- (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?
- If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.

Thanks again,
cptechno

[Martin Kersten]

- (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?

You can only do this when the plugin defines the extension-point. The plugin defining the extension-point is responsible to create and instanciate every contribution to the point.

- If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.

Check out the plugin loading mechanisms. Like view, action etc. It's quite ugly code (if they havn't changed it yet). But you will learn much.


Can you give me an example of what you are planing /wanting to do. You know just a scenario like the RCP should be able to do this and that. I was also thinking about the way the components are created... .

Views by the way has some kind of init() methods. Therefore injecting dependencies there is not much of a problem. And ViewPart(s) are intended to be subclassed.