Re: Thoughts about DOSGI 1.3.2 release
FYI: https://issues.apache.org/jira/browse/DOSGI-115 The proposed fix will probably work with Gemini straight away :-) Sergey On 28/05/12 18:45, Sergey Beryozkin wrote: On 28/05/12 18:35, David Bosschaert wrote: 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. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries & Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkin 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 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 -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Thoughts about DOSGI 1.3.2 release
On 28/05/12 18:35, David Bosschaert wrote: 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. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries & Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkin 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 Beryozkinwrote: 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
Re: Thoughts about DOSGI 1.3.2 release
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 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 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 >>> >
Re: Thoughts about DOSGI 1.3.2 release
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 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
Re: Thoughts about DOSGI 1.3.2 release
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? Cheers, David On 28 May 2012 17:34, Sergey Beryozkin 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 >
Thoughts about DOSGI 1.3.2 release
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
java2ws
Dear cxf Team I am using your java2ws plugin in our project and we are very happy with it. Nether less, we realised a problem, which occurred while converting form wsdl to C#. For integrating a new feature in the project, I would need for every class a targetNamespace, which represents its original package namespace. Is there any option/configuration I possibly missed for the plugin? Otherwise is there any possibility to integrate this new functionality into the plugin? Is there any interest at all to have such a feature available? Thank you Best regards François Thillen
