Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion

[Luan O'C. <lua...@gm...>]

Yes please, let's design modularity in from the start, even if it is
implemented fully now.

2008/7/7 Kevin Day <ke...@tr...>:
> Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox
> project is the baseline OSGi implementation).
>
> 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.
>
> 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).
>
> 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 :-)
> ).
>
>
> 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.
>
> - K
>
> ----------------------- Original Message -----------------------
>
> From: Peter Karich <pe...@ya...>
> To: spr...@li...
> Cc:
> Date: Fri, 04 Jul 2008 22:22:50 +0200
> Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas
> for    theDesktopversion
>
> Hi Lieven,
>
> like you, I think that almost all people will use springRC as one bundle.
> So it could be that no splitting is necessary (only the traditional way
> of jar bundles of course)
> But maybe I missed the point you are talking about.
> I don't know a lot of OSGi, but is it possible with this library to load
> plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your
> program or to offer additional features)
>
> This would be great for SpringRC and then my vote will be pro OSGi ;-)
>
> Regards,
> Peter.
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/com munity/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>