Re: [Springframework-rcp-dev] [Spring Desktop] ideasfor theDesktopversion

[Rogan D. <li...@da...>]

Lieven Doclo wrote:
> Hello Peter,
> 
> Indeed, plugin functionality would be great. But I still don't know whether 
> OSGi is the way to go there... Perhaps we can find a more KISS method to 
> do this...
> 
> This weekend I did some research and I've looked at the current applications 
> of OSGi and where it might fit into Spring Desktop. The main problem I would 
> have with using OSGi in Spring Desktop's main architecture (for whatever 
> reason) is that I would not want a user to be obligated to use OSGi just 
> to create a straight-forward application. The advantages are also clear (better 
> incremental development, upgrade parts of your app on the fly,...), but don't 
> outweigh my doubts at the moment. 
> 
> If someone can show me an example where a framework uses OSGi transparently 
> (the user doesn't know OSGi is used and isn't obligated to use OSGi when 
> he uses the framework), I'm all ears. But I don't think this is possible. 
> One way or another, OSGi will pop his head up and bother the average Joe 
> programmer who just wants to make his address book in Spring Desktop... What 
> I want to say here, it's great to consider enterprise level features such 
> as OSGi (and features like that should be considered and eventually foreseen), 
> but when you're burdening the smaller applications with these features you'll 
> lose a lot of the current RCP users...
> 
> Greetz,
> 
> Lieven

I don't think that there necessarily has to be a huge amount of 
dependency on OSGi to allow Spring Desktop to support it.

With reference to the current SRCP, it seems to me that there would need 
to be a certain amount of OSGi-aware classes that would allow for 
modules to appear and disappear, but that the core would not necessarily 
need rewriting.

e.g. there would need to be a different way of managing 
commands/actions, than the current commands-context.xml. So, an 
equivalent, but OSGi-aware implementation might allow for actions to be 
registered and deregistered.

If the app designer wants to use OSGi, choose the OSGi-aware 
implementations of classes, much like we have a variety of 
ApplicationPageFactories supporting SDI/MDI interfaces currently.

Rogan