Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
|
From: Kevin D. <ke...@tr...> - 2008-07-07 16:15:09
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.</DIV>
<DIV> </DIV>
<DIV>Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).</DIV>
<DIV> </DIV>
<DIV>Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Peter Karich <A href="mailto:pe...@ya..."><FONT color=#0000ff><pe...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Fri, 04 Jul 2008 22:22:50 +0200</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi Lieven,<BR><BR>like you, I think that almost all people will use springRC as one bundle.<BR>So it could be that no splitting is necessary (only the traditional way <BR>of jar bundles of course)<BR>But maybe I missed the point you are talking about.<BR>I don't know a lot of OSGi, but is it possible with this library to load <BR>plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your <BR>program or to offer additional features)<BR><BR>This would be great for SpringRC and then my vote will be pro OSGi ;-)<BR><BR>Regards,<BR>Peter.<BR><BR><BR>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at <A href="http://www.sourceforge.net/community/cca08"><FONT color=#0000ff>http://www.sourceforge.net/com
munity/cca08</FONT></A><BR>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR><A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR></DIV></FONT></BODY></HTML>
|
