Why Spring RCP when there is Eclipse RCP (golden hammer?)

[mmc]

Hi, I am looking at Spring with great interest for new projects (not worked with it before - but I think I am going to). I also like the idea that Spring tend not to reinvent the wheel but wraps existing tecnologies like Hibernate etc.

However, I fail to understand why Spring Rich Client Project exist at all. Why reinvent RCP where Eclipse RCP already exist (and Eclipse RCP is great and free!)? I doubt that Spring RCP will ever be able to beat Eclipse RCP in features or momentum.... Personally I think it would be far more interesting, if Spring RCP would simply make it easier to use Spring and Eclipse RCP/plugins together (something I unfortunately can't find any information about).

Sorry for the harsh comment, but I think a good explanation for the existence/scope of Spring RCP would be useful - in case I am wrong about it being a golden hammer. Feel free to tell me if I am wrong (so I can learn something).

[oliverhutchison]

Personally I think it would be far more interesting, if Spring RCP would simply make it easier to use Spring and Eclipse RCP/plugins together (something I unfortunately can't find any information about).

Actually there's been a discussion on the forum about this: http://forum.springframework.org/viewtopic.php?t=305.

I think a good explanation for the existence/scope of Spring RCP would be useful - in case I am wrong about it being a golden hammer. Feel free to tell me if I am wrong (so I can learn something).

There's a good summary of what Spring Rich is all about on the website at
http://www.springframework.org/spring-rcp.html.

Also from Keith's blog:

The 'rcp' acronym often gets confused and associated with eclipse's "rich client platform"; Spring rich client's focus is on the enterprise 'thick client' app space, not so much IDE-type apps. So we want to clearly differentiate ourselves from a platform like eclipse or netbeans (while there is some overlap, we don't aim to compete with them; probably the project we are mostly closely aligned with in terms of goals/focus is the very new JDNC initiative launched by Sun, our main differentiator being we're nicely integrated with the rest of Spring and follow a similar programming model...)

Ollie

[Keith Donald]

mmc - slightly updated repost from the architecture discussion on eclipse rcp integration...

----

We should work to integrate with eclipse's rich client platform certainly. I would be doing this now myself if I built apps with Eclipse for a living. Currently, however, I and my customers prefer Swing solutions at this point, and Spring Rich adds a lot of value there.

I think what we've focused on in spring rich thus far is not reinvention, but innovation, and innovation that builds on standard Swing, not JFace/AWT. Swing needs simplification through appropriate, higher-level OO abstractions, and needs it bad. And many people still view Swing as "the" widget toolkit to build platform independent desktop apps in Java.

To date we've done a lot of cool things integrating Spring's IoC container into a Swing-app environment. The result? It's a lot easier to write a clean, concisely coded (and well-layered) Swing app, where it was quite easy to write a ugly, lengthy coded one before.

I should point out a good many of the issues we're addressing in rich client, for example: data validation, UI-to-domain model binding, and command/request workflow aren't really addressed by Eclipse's base RCP platform. There is a definite "enterprise/j2ee app" focus in spring rich client.

With all this said I definitely would LOVE to see Eclipse RCP integration on top of Spring, leveraging existing complimentary libraries of spring rich (such as the data binding stuff). You're right, we could likely never compete directly with Eclipse's view/perspective/docking capabilities (nor would we to, that's not our focus. Note, however, we would want to integrate best-of-breed Swing-based docking frameworks with our project [just like as we would want to provide eclipse RCP integration].)

A major point is I wouldn't want to force spring rich users to HAVE to use eclipse's platform: in many cases it's just not necessary (particularly when a team already knows Swing, cares about platform independence, and doesn't want the complexity of the eclipse plugin model - yet another thing to configure...)

Keith

[Martin Kersten]

where Eclipse RCP already exist (and Eclipse RCP is great and free!)?

Eclipse RCP isn't that great. There will be some more releases needed. But Eclipse RCP shouldn't compared to Swing either. I am using Eclipse/Eclipse RCP only for ages, so I think I may have the nerve to state this out. If you dig in the code of Eclipse you see many old-school stuff. But they are getting better with every release.

It would be great to have databinding caps for eclipse. Currently I am using Spring for the domain layer and Eclipse RCP for the presentation layer. Works really well over here. It also encorages you to do a clean layer seperation. And yes its a bigger then a form client. (>1MB Source+1.5MB Test).

[mmc]

Well, I still think that Eclipse RCP is great (SWT is not as OO-beautiful as Swing but it is generally faster and integrates better with the underlaying native platform).

However I would be very interested in hearing more about your architecture/experience (i.e. using Spring for a Eclipse RCP app). I am considering to do the same but unfortunately haven't had experice with Spring (yet - I want to in the future).

[Martin Kersten]

Using Spring and Eclipse in conjunction all comes down to the domain layer and presentation layer.

The presentation layer is made of Eclipse RCP and the domain layer is ordinary Spring stuff. But being quite happy not much Spring is needed anyways, depending on how the domain is structured.

The spring context is mostly created by the eclipse plugin-class. (on startup). It is really straight forward. There should be some Spring RCP stuff usefull for such a scenario, but I will wait until there is a release canidate.