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

[Jim M. <jim...@sp...>]

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