Re: [Springframework-rcp-dev] [Spring Desktop] Modularity

[Claudio R. <cla...@li...>]

Jim Moore <moore.jim <at> gmail.com> writes:

> 
> Short summary of the modularity discussion...First premise: Modularity is
good.Second premise: OSGi help with modularity.Therefore Spring Desktop needs
modularity from a "good design" standpoint, but it's debatable the extent of the
benefits OSGi would give relative to the additional complexity (technical and
conceptual).There's no reason to over-burden either development of the
framework, or what people have to learn to use it.  The beautiful thing about
Spring DM for the end-user is that it lets you develop your application as a
"normal Spring app" (ie, using DI) and not worry about if it's running in an SE
or OSGi environment.  If they know and want to use OSGi, then they create and
consume bundles as normal Spring app-contexts with additional meta-data,
otherwise they simply do things the "old" way.On the framework side, as long as
we do good, disciplined design (e.g., highly cohesive packages with absolutely
no cycles between them, no static singletons, etc) then there's nothing that
would prevent us from going for the traditional library modularity approach we
all know and love, then upgrade to OSGi when we're feeling more comfortable with
the technology.  At first, no OSGi.  Later someone can start maintaining the
OSGi meta-data so end-users that want to use Spring Desktop in an OSGi
environment can do so easily.  Then, after we've seen/experienced exactly how
the technology is being used, we can start adding the cool features of OSGi for
those that want to take advantage of them.  (This is the path that all the core
Spring libraries are taking.
>  )We should go for the simplest solution first, which in this case is a highly
modular library (at the package level, not necessarily the src code level) with
no OSGi use.  When we get to things people are begging for that can't be done
except with OSGi, we'll start doing so.  But let's get the basics in there
first. -Jim Moore

Hi All,

sorry for not answering I was on holiday.

My thoughts on the OSGI stuff is that modularity is very important for the
framework. In our application we often have the need to modularize the
application. We have a customizable software for different customers. Customers
may have different or custom modules that can interact with other modules. An
easy example to think of is the administration module of the software.
(Administration module may depends on other modules but none of the other
modules depends on the administration) 

At the moment we have developed a simple module system for the current codebase
on spring rich. Every module has it's own spring-context. This module context
has the spring-rich application context as the parent. 

Every module has its own resources, actions and bindings. This resources will
then be injected to the main application context. It works, but it's a very
simple implementation and lot of nice features are missing (load/unload modules)
but it allows us to have a nice granularity on our code and the dependency's
between the modules are clearly defined.

Most problems we had during implementing this simple module feature for
spring-rich where the static methods on the application context. Something like
the whiteboard pattern (or Spring-DO magic) would have made our live much more
easier. 

I would like to see the possibility to handle this kind of scenario with 
Spring-Desktop.

But for all this I don't think that OSGI is needed from the beginning on. OSGI
would be a huge hurdle for developers when they start with Spring-Desktop, as
the framework is already complex, without the OSGI stuff in there.

As Jim said, let's focus on cohesive packages ,not having cycles dependencies
between them and no static singletons .... 

just my two cents...


Claudio