Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
How Spring DM (greatly) influenced the upcoming OSGi 4.2 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How Spring DM (greatly) influenced the upcoming OSGi 4.2

    Hi,
    The ED (Early Draft) of the upcoming OSGi platform is publicly available since yesterday :
    It can be downloaded here.
    Now, this draft brings in some interesting new stuff, but what really caught my eye was the RFC 124 section (page 216), entitled "A Component Model for OSGi" from which I quote:

    In 2006 SpringSource (formerly known as Interface21), the company behind the Spring Framework (“Spring”),
    identified a complementary relationship between the application assembly and configuration features supported
    by Spring, and the modularity and versioning features of OSGi. Spring is primarily used to build enterprise Java
    applications. In this marketplace there is a need for a solution to versioning, simultaneous deployment of more
    than one version of a library, a better basis for dividing an application into modules, and a more flexible runtime
    and deployment model. OSGi provides a proven solution to these problems. The question became, how can
    enterprise application developers take advantage of OSGi (build enterprise applications as a set of OSGi bundles)
    when developing Spring applications?
    In response to this challenge, the Spring Dynamic Modules project was born (formerly known as the Spring-OSGi
    project). Spring Dynamic Modules enables the use of Spring to configure both the internals of a bundle and also
    references between bundles. Even with little promotion the project quickly gathered a lot of attention. As of
    September 2007 there are over 800 users subscribed to the project’s active discussion group. Enterprise
    developers have responded extremely positively to the direction being taken by the project. The Spring Dynamic
    Modules project is led by SpringSource, with committers from Oracle and BEA also active. The design of Spring
    Dynamic Modules has been influenced by discussion (both face-to-face and in the discussion group) with key
    personnel in the OSGi Alliance and from the equinox, Felix, and Knopflerfish OSGi implementations.
    This sections then goes on and on, for 73 pages, but, it is mainly the specs for a slightly modified version of Spring/Spring DM declarative management of beans (the sole difference that I was able to catch was the use of different namespaces and the <component> element which supersedes the familiar <bean>.

    Heck ! these are such great news ! I mean OSGi development which was made much easier via Spring DM will now get standardized !

    In the meantime, since OSGi containers will have to implement this RFC thing, what will happen to Spring DM ?
    Maybe OSGi containers would use it (combined with Spring) to effectively and easily implement this RFC ?
    Or will it continue to exist on it's own relying on it's "inertia-free" status to continue to drive the evolution ?

    Cheers,
    Jawher

  • #2
    In the meantime, since OSGi containers will have to implement this RFC thing, what will happen to Spring DM ?
    Maybe OSGi containers would use it (combined with Spring) to effectively and easily implement this RFC ?
    Or will it continue to exist on it's own relying on it's "inertia-free" status to continue to drive the evolution ?
    Good questions - Spring-DM will become the RI. We haven't sorted out the technical details, but it's likely it's going to be platform agnostic so one could just take out the implementation and use whatever 4.2 platform it likes.
    However, since it's a spec, it's entirely possible for other implementations to become available.
    As for what happens after the RI implementation, I think it's too early to comment right now.

    Comment

    Working...
    X