At tonight's Philadelphia Spring Users Group meeting, Rob Harrop
presented SpringSource dmServer. (The product looks great by the
way.)
During the Q&A, Rob was asked to clarify SpringSource's policy on how
new features are targeted to the Spring DM roadmap versus the GPLv3 /
commercial dmServer roadmap. My understanding of his response is:
- DM is feature complete and no new features will be worked on
- Parts of DM will be incorporated in to future versions of the OSGi
specification
- Other parts will be maintained, but without any new development
This was quite surprising to me, considering the activity in JIRA and
the forums, and all the hard work folks like Costin and Andy and
others have put in. Could one of the core committers comment on the
future of DM? Specifically, what's the future of the integration
testing support and the web support? As far as I know, neither of
these are candidates for inclusion in the specification but a lot of
us are building on them.
Also, please keep in mind that I may have misinterpreted Rob's
response.
The OSGi RFC 124, aka "OSGi Blueprint", is the standard that has come out of Spring/DM. Adrian and others are working very hard on closing it down and we're in the end game on that front. Spring/DM and Blueprint will converge, but backward compatibility, as with all Spring systems, will be maintained as much as possible. Blueprint has a different XSD than Spring/DM, but both will be supported.
Sorry, this is just a quick note and I'll let Adrian and/or others fill in the other details. But things are still being worked on, developed and with Blueprint, graduated into an industry wide standard for an enterprise class OSGi component model.
On Oct 21, 2008, at 7:55 PM, mpilqu...@gmail.com wrote:
> At tonight's Philadelphia Spring Users Group meeting, Rob Harrop > presented SpringSource dmServer. (The product looks great by the > way.)
> During the Q&A, Rob was asked to clarify SpringSource's policy on how > new features are targeted to the Spring DM roadmap versus the GPLv3 / > commercial dmServer roadmap. My understanding of his response is: > - DM is feature complete and no new features will be worked on > - Parts of DM will be incorporated in to future versions of the OSGi > specification > - Other parts will be maintained, but without any new development
> This was quite surprising to me, considering the activity in JIRA and > the forums, and all the hard work folks like Costin and Andy and > others have put in. Could one of the core committers comment on the > future of DM? Specifically, what's the future of the integration > testing support and the web support? As far as I know, neither of > these are candidates for inclusion in the specification but a lot of > us are building on them.
> Also, please keep in mind that I may have misinterpreted Rob's > response.
We're working on two fronts in Spring DM at the moment. Firstly on a 1.2 release that will fill in the long-promised configuration administration support, making the core programming model feature complete. Secondly, we have a 2.0 branch created in which work is going on in parallel.
The 2.0 branch is where we are implementing the OSGi Blueprint Service (RFC 124) that will be part of OSGi R4.2. The Spring DM project will be the RI for this forthcoming specification (which is essentially a standardization of Spring DM + the core Spring beans support). We're implementing it in such a way that all of the Spring features over and above the specification will still be available to you even when you choose to use the standards-based namespace. The existing Spring DM namespaces will still be supported for backwards compatibility, but following the release of Spring DM 2.0 we would expect the Blueprint Service schema and interfaces to be the default choice for new projects.
The Blueprint Service will then also form the core of the recommended programming model for the SpringSource dm Server at that point in time.
So in summary, the future of Spring DM is to move towards becoming an RI for the standardization of the existing DM model, as the OSGi Blueprint Service. The Spring DM project provides an open source (and soon standards-based) programming model for use on any OSGi Service Platform.
The SpringSource dm Server will move to using Spring DM (the Blueprint Service) as the recommended programming model, adding on top of that OSGi-based deployment and administration, support for different styles of applications (web, batch, integration etc.), provisioning, and the ability to use a wide range of existing enterprise Java libraries with a lot less pain than you would typically experience on a "vanilla" OSGi Service Platform.
On Tue, Oct 21, 2008 at 08:46:16PM -0700, Hal Hildebrand wrote:
> The OSGi RFC 124, aka "OSGi Blueprint", is the standard that has come > out of Spring/DM. Adrian and others are working very hard on closing > it down and we're in the end game on that front. Spring/DM and > Blueprint will converge, but backward compatibility, as with all > Spring systems, will be maintained as much as possible. Blueprint has > a different XSD than Spring/DM, but both will be supported.
> Sorry, this is just a quick note and I'll let Adrian and/or others > fill in the other details. But things are still being worked on, > developed and with Blueprint, graduated into an industry wide standard > for an enterprise class OSGi component model.
> On Oct 21, 2008, at 7:55 PM, mpilqu...@gmail.com wrote:
> > Hi all,
> > At tonight's Philadelphia Spring Users Group meeting, Rob Harrop > > presented SpringSource dmServer. (The product looks great by the > > way.)
> > During the Q&A, Rob was asked to clarify SpringSource's policy on how > > new features are targeted to the Spring DM roadmap versus the GPLv3 / > > commercial dmServer roadmap. My understanding of his response is: > > - DM is feature complete and no new features will be worked on > > - Parts of DM will be incorporated in to future versions of the OSGi > > specification > > - Other parts will be maintained, but without any new development
> > This was quite surprising to me, considering the activity in JIRA and > > the forums, and all the hard work folks like Costin and Andy and > > others have put in. Could one of the core committers comment on the > > future of DM? Specifically, what's the future of the integration > > testing support and the web support? As far as I know, neither of > > these are candidates for inclusion in the specification but a lot of > > us are building on them.
> > Also, please keep in mind that I may have misinterpreted Rob's > > response.
Registered in England and Wales: No. 5187766 Registered Office: A2 Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
E-mails should be checked by the recipient to ensure that there are no viruses and Interface21 does not accept any responsibility if this is not done. Any views or opinions presented are solely those of the author and do not necessarily represent those of Interface21.
I realise I didn't address the two key areas of web integration support and the testing framework.
* We will maintain a testing framework in the Spring DM project. It's a vital piece of the overall puzzle. The test framework as it is now will probably see some enhancement to support Java 5 (JUnit 4 etc.). The testing framework is indeed *not* something that will be part of the Blueprint Specification.
* We will maintain the existing web support in Spring DM, but are not planning to take this any further in terms of significant new features etc. We're running into a law of diminishing returns there in terms of how good an experience we can deliver on a vanilla OSGi Service Platform. This was one of the motivations for creating the dm Server in the first place - to provide the best environment we could for OSGi-based enterprise applications and there are many issues that we can resolve much more easily in the dm Server world. [The SpringSource dm Server is of course also freely available in open source].
On Wed, Oct 22, 2008 at 09:52:51AM +0100, Adrian Colyer wrote:
> We're working on two fronts in Spring DM at the moment. Firstly on a 1.2 > release that will fill in the long-promised configuration administration > support, making the core programming model feature complete. Secondly, we > have a 2.0 branch created in which work is going on in parallel.
> The 2.0 branch is where we are implementing the OSGi Blueprint Service (RFC > 124) that will be part of OSGi R4.2. The Spring DM project will be the RI > for this forthcoming specification (which is essentially a standardization > of Spring DM + the core Spring beans support). We're implementing it in such > a way that all of the Spring features over and above the specification will > still be available to you even when you choose to use the standards-based > namespace. The existing Spring DM namespaces will still be supported for > backwards compatibility, but following the release of Spring DM 2.0 we would > expect the Blueprint Service schema and interfaces to be the default choice > for new projects.
> The Blueprint Service will then also form the core of the recommended > programming model for the SpringSource dm Server at that point in time.
> So in summary, the future of Spring DM is to move towards becoming an RI for > the standardization of the existing DM model, as the OSGi Blueprint Service. > The Spring DM project provides an open source (and soon standards-based) > programming model for use on any OSGi Service Platform.
> The SpringSource dm Server will move to using Spring DM (the Blueprint > Service) as the recommended programming model, adding on top of that > OSGi-based deployment and administration, support for different styles of > applications (web, batch, integration etc.), provisioning, and the ability > to use a wide range of existing enterprise Java libraries with a lot less > pain than you would typically experience on a "vanilla" OSGi Service > Platform.
> Regards, Adrian.
> On Tue, Oct 21, 2008 at 08:46:16PM -0700, Hal Hildebrand wrote:
> > The OSGi RFC 124, aka "OSGi Blueprint", is the standard that has come > > out of Spring/DM. Adrian and others are working very hard on closing > > it down and we're in the end game on that front. Spring/DM and > > Blueprint will converge, but backward compatibility, as with all > > Spring systems, will be maintained as much as possible. Blueprint has > > a different XSD than Spring/DM, but both will be supported.
> > Sorry, this is just a quick note and I'll let Adrian and/or others > > fill in the other details. But things are still being worked on, > > developed and with Blueprint, graduated into an industry wide standard > > for an enterprise class OSGi component model.
> > On Oct 21, 2008, at 7:55 PM, mpilqu...@gmail.com wrote:
> > > Hi all,
> > > At tonight's Philadelphia Spring Users Group meeting, Rob Harrop > > > presented SpringSource dmServer. (The product looks great by the > > > way.)
> > > During the Q&A, Rob was asked to clarify SpringSource's policy on how > > > new features are targeted to the Spring DM roadmap versus the GPLv3 / > > > commercial dmServer roadmap. My understanding of his response is: > > > - DM is feature complete and no new features will be worked on > > > - Parts of DM will be incorporated in to future versions of the OSGi > > > specification > > > - Other parts will be maintained, but without any new development
> > > This was quite surprising to me, considering the activity in JIRA and > > > the forums, and all the hard work folks like Costin and Andy and > > > others have put in. Could one of the core committers comment on the > > > future of DM? Specifically, what's the future of the integration > > > testing support and the web support? As far as I know, neither of > > > these are candidates for inclusion in the specification but a lot of > > > us are building on them.
> > > Also, please keep in mind that I may have misinterpreted Rob's > > > response.
> Registered in England and Wales: No. 5187766 Registered Office: A2 > Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
> E-mails should be checked by the recipient to ensure that there are no > viruses and Interface21 does not accept any responsibility if this is > not done. Any views or opinions presented are solely those of the > author and do not necessarily represent those of Interface21.
Registered in England and Wales: No. 5187766 Registered Office: A2 Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
E-mails should be checked by the recipient to ensure that there are no viruses and Interface21 does not accept any responsibility if this is not done. Any views or opinions presented are solely those of the author and do not necessarily represent those of Interface21.
> I realise I didn't address the two key areas of web integration support and > the testing framework.
> * We will maintain a testing framework in the Spring DM project. It's a > vital piece of the overall puzzle. The test framework as it is now will > probably see some enhancement to support Java 5 (JUnit 4 etc.). The testing > framework is indeed *not* something that will be part of the Blueprint > Specification.
> * We will maintain the existing web support in Spring DM, but are not > planning to take this any further in terms of significant new features etc. > We're running into a law of diminishing returns there in terms of how good > an experience we can deliver on a vanilla OSGi Service Platform. This was > one of the motivations for creating the dm Server in the first place - to > provide the best environment we could for OSGi-based enterprise > applications > and there are many issues that we can resolve much more easily in the dm > Server world. [The SpringSource dm Server is of course also freely > available > in open source].
> Regards, Adrian.
> On Wed, Oct 22, 2008 at 09:52:51AM +0100, Adrian Colyer wrote:
> > We're working on two fronts in Spring DM at the moment. Firstly on a 1.2 > > release that will fill in the long-promised configuration administration > > support, making the core programming model feature complete. Secondly, we > > have a 2.0 branch created in which work is going on in parallel.
> > The 2.0 branch is where we are implementing the OSGi Blueprint Service > (RFC > > 124) that will be part of OSGi R4.2. The Spring DM project will be the RI > > for this forthcoming specification (which is essentially a > standardization > > of Spring DM + the core Spring beans support). We're implementing it in > such > > a way that all of the Spring features over and above the specification > will > > still be available to you even when you choose to use the standards-based > > namespace. The existing Spring DM namespaces will still be supported for > > backwards compatibility, but following the release of Spring DM 2.0 we > would > > expect the Blueprint Service schema and interfaces to be the default > choice > > for new projects.
> > The Blueprint Service will then also form the core of the recommended > > programming model for the SpringSource dm Server at that point in time.
> > So in summary, the future of Spring DM is to move towards becoming an RI > for > > the standardization of the existing DM model, as the OSGi Blueprint > Service. > > The Spring DM project provides an open source (and soon standards-based) > > programming model for use on any OSGi Service Platform.
> > The SpringSource dm Server will move to using Spring DM (the Blueprint > > Service) as the recommended programming model, adding on top of that > > OSGi-based deployment and administration, support for different styles of > > applications (web, batch, integration etc.), provisioning, and the > ability > > to use a wide range of existing enterprise Java libraries with a lot less > > pain than you would typically experience on a "vanilla" OSGi Service > > Platform.
> > Regards, Adrian.
> > On Tue, Oct 21, 2008 at 08:46:16PM -0700, Hal Hildebrand wrote:
> > > The OSGi RFC 124, aka "OSGi Blueprint", is the standard that has come > > > out of Spring/DM. Adrian and others are working very hard on closing > > > it down and we're in the end game on that front. Spring/DM and > > > Blueprint will converge, but backward compatibility, as with all > > > Spring systems, will be maintained as much as possible. Blueprint has > > > a different XSD than Spring/DM, but both will be supported.
> > > Sorry, this is just a quick note and I'll let Adrian and/or others > > > fill in the other details. But things are still being worked on, > > > developed and with Blueprint, graduated into an industry wide standard > > > for an enterprise class OSGi component model.
> > > On Oct 21, 2008, at 7:55 PM, mpilqu...@gmail.com wrote:
> > > > Hi all,
> > > > At tonight's Philadelphia Spring Users Group meeting, Rob Harrop > > > > presented SpringSource dmServer. (The product looks great by the > > > > way.)
> > > > During the Q&A, Rob was asked to clarify SpringSource's policy on how > > > > new features are targeted to the Spring DM roadmap versus the GPLv3 / > > > > commercial dmServer roadmap. My understanding of his response is: > > > > - DM is feature complete and no new features will be worked on > > > > - Parts of DM will be incorporated in to future versions of the OSGi > > > > specification > > > > - Other parts will be maintained, but without any new development
> > > > This was quite surprising to me, considering the activity in JIRA and > > > > the forums, and all the hard work folks like Costin and Andy and > > > > others have put in. Could one of the core committers comment on the > > > > future of DM? Specifically, what's the future of the integration > > > > testing support and the web support? As far as I know, neither of > > > > these are candidates for inclusion in the specification but a lot of > > > > us are building on them.
> > > > Also, please keep in mind that I may have misinterpreted Rob's > > > > response.
> > Registered in England and Wales: No. 5187766 Registered Office: A2 > > Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
> > E-mails should be checked by the recipient to ensure that there are no > > viruses and Interface21 does not accept any responsibility if this is > > not done. Any views or opinions presented are solely those of the > > author and do not necessarily represent those of Interface21.
> Registered in England and Wales: No. 5187766 Registered Office: A2 > Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
> E-mails should be checked by the recipient to ensure that there are no > viruses and Interface21 does not accept any responsibility if this is > not done. Any views or opinions presented are solely those of the > author and do not necessarily represent those of Interface21.
About the roadmap of the Spring Dynamic Modules, is it possible to have an estimation date of the first milestone / release of the version 2 of the tool and of the release of OSGi 4.2?
|
