Announcement Announcement Module

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
Spring Dynamic Modules v2 moving to Eclipse Gemini project Page Title Module
Move Remove Collapse
This is a sticky topic.
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Dynamic Modules v2 moving to Eclipse Gemini project

    Hi everyone,

    As part of the newly Eclipse Gemini project, Spring Dynamic Modules v2 will be moving to Quoting from Adrian's Colyer blog post:
    Gemini Blueprint Service – this is a big deal! Those of you who have been following developments in the OSGi world will know that since we started the Spring Dynamic Modules project almost 4 years ago (then called Spring OSGi) it has grown into a very popular foundation for enterprise application development on the OSGi Service Platform. Through the OSGi Alliance Enterprise Expert Group, we worked to create a standard based on the Spring Dynamic Modules programming model, and this was released as part of the OSGi R4.2 Compendium Specification as the "Blueprint Service". Spring Dynamic Modules v2 is the Reference Implementation for the Blueprint Service specification. We're still working through the details, but the Spring Dynamic Modules v2 codebase will be moving to as the Gemini Blueprint Service project, where it will continue to be developed alongside the other enterprise projects and will track the evolution of the Blueprint Specification in future OSGi Alliance updates.
    [The project] will be dual-licensed under both the EPL and the Apache License.
    More information can be found at:

    Eclipse RT:
    Eclipse Gemini proposal:
    Eclipse Gemini FAQ:
    Details on Gemini Blueprint Service:
    Adrian Colyer's blog post: announcement:

    As Adrian mentioned, while the transition details remain to be settled, we're aiming for as little disruption as possible.

    If you have any questions, remarks or feedback, let us know.
    Last edited by Costin Leau; Nov 24th, 2009, 12:06 PM. Reason: added more links

  • #2
    The only question I have with regard to this move is concerning the Spring-DM style of declarative services. As I understand it, Spring-DM will become the Gemini Blueprint Service, implying that this is an implementation of RFC-124. Fair enough...Spring-DM *is* the RI for RFC-124, so that fits. However...

    Spring-DM also has it's own model that preceded RFC-124. As this will no longer be under the Spring umbrella, will the new project maintain backward compatibility with Spring-DM's model? Specifically, will we still be able to use Spring-DM namespace and will be still be able to mix-n-match the Spring-DM namespace with the blueprint namespace and with Spring's other namespaces?

    The blueprint service specification by itself is great. But Spring-DM brought more to the table than what the core specification defines and I'd not like Gemini Blueprint to be reduced to only following the specification only.


    • #3
      Hi Craig,

      The move to Gemini will not affect the current functionality of Spring DM. Spring DM v2 will not be restricted to RFC-124 just because it will move to, quite the opposite: we aim to keep and enrich the current functionality.


      • #4
        Thanks, Costin. That's the answer that I had anticipated. But I had seen nothing that expressly states this, so I wanted to make sure.

        BTW, great job and am looking forward to working with the Gemini Blueprint Service.