I can understand that it's a significant refactoring. If you stay within the pure Blueprint model (within the spec) you shouldn't get bound to Aries. Eclipse Gemini also has an implementation.
Cheers, David On 28 May 2012 18:17, Sergey Beryozkin <[email protected]> wrote: > Hi David > > On 28/05/12 18:09, David Bosschaert wrote: >> >> Sounds good, Sergey. I'm all for releasing frequently. >> >> One of the things that I think would be good to tackle is to migrate >> to OSGi Blueprint (from of the current Spring-based approach). Is that >> something that you were thinking of looking at? >> > Not really. Some users would like to use Blueprint but not be bound to > Aries. So for me it's a DOSGI 1.4 level issue which will require a > significant time investment. > > Cheers, Sergey > >> Cheers, >> >> David >> >> On 28 May 2012 17:34, Sergey Beryozkin<[email protected]> wrote: >>> >>> Hi >>> >>> I'm thinking of starting working toward releasing DOSGI 1.3.2. >>> I think I'll spend the next 2 or months on fixing few issues I can find >>> some >>> time for, given that there's a lot of other CXF/etc work that needs to be >>> taken care of. >>> I'd like to suggest that the next release will be 1.3.2 as opposed to >>> 1.4.0. >>> Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, >>> giving >>> that a minimal bundle in CXF 2.6.x has gone. >>> >>> It seems that there are still quite a few issues there that are important >>> to >>> be fixed for the base/simple DOSGI applications to work reliably and >>> given >>> that 2.5.x branch is still relatively 'young', I'd probably prefer to >>> stay >>> on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI >>> 1.3.3), simply to make the most of the limited time that I will be able >>> to >>> spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by >>> that time many of the 'basic' DOSGI features have been fixed... >>> >>> Thanks, Sergey >>> >
