Re: [DISCUSS] CXF 3.5.x and beyond
Hi Andriy, >From what I looked at last time, it seems it's difficult to decouple these osgi/karaf integration code from cxf core and create a new project to put it into a separate repository. IMO, we can create a branch before we remove these integration codes, and later we can look at this branch to restore the osgi/integration code when osgi jakarta support is available. Your thoughts? Thanks, Jim On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko wrote: > Hey guys, > > Thanks a lot for bringing the clarity on possible timelines. @Jim, how do > you want > to proceed with that? Do you think it is good idea to move off Apache > Karaf integration > into separate repository altogether (we discussed that a few times as > well)? Should we > preserve the OSGi-related hooks but replace them with "dummy" > implementation (like HTTP > transport for example)? @Colm, @Freeman what do you think? (assuming the > goal is to put > this chunk of codebase aside and bring it back when time comes). > > Thanks! > > Best Regards, > Andriy Redko > > > > Thanks for the informative input, Freeman. > > IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good > > chance to do this job. When OSGI/Karaf jakarta release is ready, > > We can look at bringing this back with more improvement and refactor work > > to make it loosely coupled with core code. > > > On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang > wrote: > > >> Hi Jim, > > >> Sorry for the late reply, just back from vacation. > >> About the OSGi part, the main problem is that the OSGi R9 spec which > will > >> support Jakarta namespace is in progress and isn't released yet(and I > don't > >> think there is a concrete release date for OSGi R9 spec in the new > future). > >> Before OSGi R9 spec gets released and adopted by OSGi implementations > like > >> Felix/Equinox, I don't think there is much we can do in CXF or even in > >> Karaf about this part. > >> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit > >> seems the only option we have so far, and I'm +1 for this way > now(Since we > >> don't know how long we need to wait for the proper OSGi spec released > and > >> upstream projects can support it). > >> Just my 2 cents. > >> Best Regards > >> Freeman > >> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: > >>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman > >>> about this topic several months ago and got to know > >>> there won't be Jakarta namespace support work in the future. I don't > know > >>> if this has changed. > >>> Freeman, do you have some update on this ? > > >>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote: > Hey Jim, > > I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real > blockers. For Swagger 1.x, we could > go ahead and drop the support altogether, this is quite isolated > feature. OSGi and Karaf are not, those > penetrated very deep into core. What worries me, if we drop everything > OSGi/Karaf related from 4.0.0, we > may need to bring it back some time in the future (with OSGi R9 [4] > fe) > and that is going to be quite > difficult. From other side, this is probably the only option to have > 4.0.0 milestone out (we excluded some > modules from the build right now but that is more like a temporary > hack > which we should not release upon, > even alphas). What do you think guys? > Best Regards, > Andriy Redko > [1] https://issues.apache.org/jira/browse/CXF-8714 > [2] https://issues.apache.org/jira/browse/CXF-8723 > [3] https://issues.apache.org/jira/browse/CXF-8722 > [4] https://github.com/osgi/osgi/milestone/5 > JM> After we merged the jakarta branch to default branch main branch, > do we > JM> need to create some > JM> plan to do a future 4.x release? > JM> There are a couple of to-do things under > JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, > JM> and for some of them we can't do more things because of the jakarta > JM> dependency missing. It seems that some of the dependencies won't > JM> have the jakarta namespace artifact released in the near future. > Should we > JM> have some milestone/alpha release > JM> before all these dependencies are available ? And if we want to > do a > JM> milestone release, what do you think we should have in > JM> this 4.0.0-M1 release ? > JM> Thanks, > JM> Jim > JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma > wrote: > >> Thanks Andriy too for driving this and moving forward ! > > >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko > wrote: > >>> Hey guys, > > >>> The Jakarta branch [1] just went into master, HUGE THANKS everyone > for > >>> tremendous effort! Please > >>> note, it is still work in progress, the things to be done are > tracked > >>> under [2], feel free to > >>> add more items or pick t
Re: [DISCUSS] CXF 3.5.x and beyond
Thanks for the update, Andiry. You already did a lot of work on third party jakarta support ! Just to understand the CXF Jakarta support work status, are these issues we can start without waiting for the dependency release ? https://issues.apache.org/jira/browse/CXF-8716 https://issues.apache.org/jira/browse/CXF-8717 https://issues.apache.org/jira/browse/CXF-8719 On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko wrote: > Hi Jim, > > Yeah, we may need some time, I am also finalizing work on the Wiremock ( > https://github.com/wiremock/wiremock/pull/1942), > we use it in tests extensively. One of the largest efforts is migration to > Jetty 11, I have started on that already but > have difficulties with WebSockets migration, it needs rework and that is > my focus at the moment. The Swagger 1.x we have > to drop I believe, I don't see roadmap on Jakarta support there. > > Thanks! > > Best Regards, > Andriy Redko > > JM> Hi Andriy, > JM> It looks like we still have to wait for the other dependency jakarta > JM> support available, like brave's new release to include this change : > JM> https://github.com/openzipkin/brave/pull/1344. Do you see any other > JM> dependencies that haven't been released yet except OSGI and Karaf ? > > JM> Thanks, > JM> Jim > > > JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma wrote: > > >> Thanks for the informative input, Freeman. > >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good > >> chance to do this job. When OSGI/Karaf jakarta release is ready, > >> We can look at bringing this back with more improvement and refactor > work > >> to make it loosely coupled with core code. > >> > >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang > >> wrote: > >> > >>> Hi Jim, > >>> > >>> Sorry for the late reply, just back from vacation. > >>> > >>> About the OSGi part, the main problem is that the OSGi R9 spec which > will > >>> support Jakarta namespace is in progress and isn't released yet(and I > don't > >>> think there is a concrete release date for OSGi R9 spec in the new > future). > >>> Before OSGi R9 spec gets released and adopted by OSGi implementations > like > >>> Felix/Equinox, I don't think there is much we can do in CXF or even in > >>> Karaf about this part. > >>> > >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit > >>> seems the only option we have so far, and I'm +1 for this way > now(Since we > >>> don't know how long we need to wait for the proper OSGi spec released > and > >>> upstream projects can support it). > >>> > >>> Just my 2 cents. > >>> Best Regards > >>> Freeman > >>> > >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: > >>> > For OSGI and Karaf Jakarta native, I remembered I talked with Freeman > about this topic several months ago and got to know > there won't be Jakarta namespace support work in the future. I don't > know if this has changed. > Freeman, do you have some update on this ? > > > On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko > wrote: > > > Hey Jim, > > > > I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real > > blockers. For Swagger 1.x, we could > > go ahead and drop the support altogether, this is quite isolated > > feature. OSGi and Karaf are not, those > > penetrated very deep into core. What worries me, if we drop > everything > > OSGi/Karaf related from 4.0.0, we > > may need to bring it back some time in the future (with OSGi R9 [4] > fe) > > and that is going to be quite > > difficult. From other side, this is probably the only option to have > > 4.0.0 milestone out (we excluded some > > modules from the build right now but that is more like a temporary > hack > > which we should not release upon, > > even alphas). What do you think guys? > > > > Best Regards, > > Andriy Redko > > > > [1] https://issues.apache.org/jira/browse/CXF-8714 > > [2] https://issues.apache.org/jira/browse/CXF-8723 > > [3] https://issues.apache.org/jira/browse/CXF-8722 > > [4] https://github.com/osgi/osgi/milestone/5 > > > > JM> After we merged the jakarta branch to default branch main branch, > > do we > > JM> need to create some > > JM> plan to do a future 4.x release? > > > > JM> There are a couple of to-do things under > > JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, > > JM> and for some of them we can't do more things because of the > jakarta > > JM> dependency missing. It seems that some of the dependencies won't > > JM> have the jakarta namespace artifact released in the near future. > > Should we > > JM> have some milestone/alpha release > > JM> before all these dependencies are available ? And if we want to > do > > a > > JM> milestone release, what do you think we should have in > > JM> this 4.0.0-M1 release ? > > > > > > JM> Thanks, > > JM> Jim > >
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Jim, It sounds easier, requiring less efforts, I agree. Colm, Freeman, are you on board with this approach guys? Thanks! Best Regards, Andriy Redko JM> Hi Andriy, JM> From what I looked at last time, it seems it's difficult to decouple these JM> osgi/karaf integration code from cxf core JM> and create a new project to put it into a separate repository. IMO, we can JM> create a branch before we JM> remove these integration codes, and later we can look at this branch to JM> restore the osgi/integration code when JM> osgi jakarta support is available. Your thoughts? JM> Thanks, JM> Jim JM> On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko wrote: >> Hey guys, >> >> Thanks a lot for bringing the clarity on possible timelines. @Jim, how do >> you want >> to proceed with that? Do you think it is good idea to move off Apache >> Karaf integration >> into separate repository altogether (we discussed that a few times as >> well)? Should we >> preserve the OSGi-related hooks but replace them with "dummy" >> implementation (like HTTP >> transport for example)? @Colm, @Freeman what do you think? (assuming the >> goal is to put >> this chunk of codebase aside and bring it back when time comes). >> >> Thanks! >> >> Best Regards, >> Andriy Redko >> >> >> > Thanks for the informative input, Freeman. >> > IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good >> > chance to do this job. When OSGI/Karaf jakarta release is ready, >> > We can look at bringing this back with more improvement and refactor work >> > to make it loosely coupled with core code. >> >> > On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >> wrote: >> >> >> Hi Jim, >> >> >> Sorry for the late reply, just back from vacation. >> >> About the OSGi part, the main problem is that the OSGi R9 spec which >> will >> >> support Jakarta namespace is in progress and isn't released yet(and I >> don't >> >> think there is a concrete release date for OSGi R9 spec in the new >> future). >> >> Before OSGi R9 spec gets released and adopted by OSGi implementations >> like >> >> Felix/Equinox, I don't think there is much we can do in CXF or even in >> >> Karaf about this part. >> >> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >> >> seems the only option we have so far, and I'm +1 for this way >> now(Since we >> >> don't know how long we need to wait for the proper OSGi spec released >> and >> >> upstream projects can support it). >> >> Just my 2 cents. >> >> Best Regards >> >> Freeman >> >> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >> >>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >> >>> about this topic several months ago and got to know >> >>> there won't be Jakarta namespace support work in the future. I don't >> know >> >>> if this has changed. >> >>> Freeman, do you have some update on this ? >> >> >>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote: >> Hey Jim, >> >> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >> blockers. For Swagger 1.x, we could >> go ahead and drop the support altogether, this is quite isolated >> feature. OSGi and Karaf are not, those >> penetrated very deep into core. What worries me, if we drop everything >> OSGi/Karaf related from 4.0.0, we >> may need to bring it back some time in the future (with OSGi R9 [4] >> fe) >> and that is going to be quite >> difficult. From other side, this is probably the only option to have >> 4.0.0 milestone out (we excluded some >> modules from the build right now but that is more like a temporary >> hack >> which we should not release upon, >> even alphas). What do you think guys? >> Best Regards, >> Andriy Redko >> [1] https://issues.apache.org/jira/browse/CXF-8714 >> [2] https://issues.apache.org/jira/browse/CXF-8723 >> [3] https://issues.apache.org/jira/browse/CXF-8722 >> [4] https://github.com/osgi/osgi/milestone/5 >> JM> After we merged the jakarta branch to default branch main branch, >> do we >> JM> need to create some >> JM> plan to do a future 4.x release? >> JM> There are a couple of to-do things under >> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >> JM> and for some of them we can't do more things because of the jakarta >> JM> dependency missing. It seems that some of the dependencies won't >> JM> have the jakarta namespace artifact released in the near future. >> Should we >> JM> have some milestone/alpha release >> JM> before all these dependencies are available ? And if we want to >> do a >> JM> milestone release, what do you think we should have in >> JM> this 4.0.0-M1 release ? >> JM> Thanks, >> JM> Jim >> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma >> wrote: >> >> Thanks Andriy too for driving this and moving forward ! >> >> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko >>
Re: [DISCUSS] CXF 3.5.x and beyond
+1 for this way, it's much easier. Thanks! Freeman On Fri, Sep 9, 2022 at 3:55 PM Andriy Redko wrote: > Hi Jim, > > It sounds easier, requiring less efforts, I agree. > Colm, Freeman, are you on board with this approach guys? > Thanks! > > Best Regards, > Andriy Redko > > JM> Hi Andriy, > JM> From what I looked at last time, it seems it's difficult to decouple > these > JM> osgi/karaf integration code from cxf core > JM> and create a new project to put it into a separate repository. IMO, we > can > JM> create a branch before we > JM> remove these integration codes, and later we can look at this branch to > JM> restore the osgi/integration code when > JM> osgi jakarta support is available. Your thoughts? > > JM> Thanks, > JM> Jim > > JM> On Thu, Sep 8, 2022 at 7:57 PM Andriy Redko wrote: > > >> Hey guys, > >> > >> Thanks a lot for bringing the clarity on possible timelines. @Jim, how > do > >> you want > >> to proceed with that? Do you think it is good idea to move off Apache > >> Karaf integration > >> into separate repository altogether (we discussed that a few times as > >> well)? Should we > >> preserve the OSGi-related hooks but replace them with "dummy" > >> implementation (like HTTP > >> transport for example)? @Colm, @Freeman what do you think? (assuming the > >> goal is to put > >> this chunk of codebase aside and bring it back when time comes). > >> > >> Thanks! > >> > >> Best Regards, > >> Andriy Redko > >> > >> > >> > Thanks for the informative input, Freeman. > >> > IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a > good > >> > chance to do this job. When OSGI/Karaf jakarta release is ready, > >> > We can look at bringing this back with more improvement and refactor > work > >> > to make it loosely coupled with core code. > >> > >> > On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang > >> wrote: > >> > >> >> Hi Jim, > >> > >> >> Sorry for the late reply, just back from vacation. > >> >> About the OSGi part, the main problem is that the OSGi R9 spec which > >> will > >> >> support Jakarta namespace is in progress and isn't released yet(and I > >> don't > >> >> think there is a concrete release date for OSGi R9 spec in the new > >> future). > >> >> Before OSGi R9 spec gets released and adopted by OSGi implementations > >> like > >> >> Felix/Equinox, I don't think there is much we can do in CXF or even > in > >> >> Karaf about this part. > >> >> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit > >> >> seems the only option we have so far, and I'm +1 for this way > >> now(Since we > >> >> don't know how long we need to wait for the proper OSGi spec released > >> and > >> >> upstream projects can support it). > >> >> Just my 2 cents. > >> >> Best Regards > >> >> Freeman > >> >> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma > wrote: > >> >>> For OSGI and Karaf Jakarta native, I remembered I talked with > Freeman > >> >>> about this topic several months ago and got to know > >> >>> there won't be Jakarta namespace support work in the future. I don't > >> know > >> >>> if this has changed. > >> >>> Freeman, do you have some update on this ? > >> > >> >>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko > wrote: > >> Hey Jim, > >> > >> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real > >> blockers. For Swagger 1.x, we could > >> go ahead and drop the support altogether, this is quite isolated > >> feature. OSGi and Karaf are not, those > >> penetrated very deep into core. What worries me, if we drop > everything > >> OSGi/Karaf related from 4.0.0, we > >> may need to bring it back some time in the future (with OSGi R9 [4] > >> fe) > >> and that is going to be quite > >> difficult. From other side, this is probably the only option to > have > >> 4.0.0 milestone out (we excluded some > >> modules from the build right now but that is more like a temporary > >> hack > >> which we should not release upon, > >> even alphas). What do you think guys? > >> Best Regards, > >> Andriy Redko > >> [1] https://issues.apache.org/jira/browse/CXF-8714 > >> [2] https://issues.apache.org/jira/browse/CXF-8723 > >> [3] https://issues.apache.org/jira/browse/CXF-8722 > >> [4] https://github.com/osgi/osgi/milestone/5 > >> JM> After we merged the jakarta branch to default branch main > branch, > >> do we > >> JM> need to create some > >> JM> plan to do a future 4.x release? > >> JM> There are a couple of to-do things under > >> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, > >> JM> and for some of them we can't do more things because of the > jakarta > >> JM> dependency missing. It seems that some of the dependencies won't > >> JM> have the jakarta namespace artifact released in the near future. > >> Should we > >> JM> have some milestone/alpha release > >> JM> before all these dependencies are availab
Re: [DISCUSS] CXF 3.5.x and beyond
Hi Jim, That is correct, I am working on https://issues.apache.org/jira/browse/CXF-8717 as part of Jetty 11 migration, the Atmosphere implementation seems to be fine. Thanks. Best Regards, Andriy Redko JM> Thanks for the update, Andiry. You already did a lot of work on third party JM> jakarta support ! JM> Just to understand the CXF Jakarta support work status, are these issues we JM> can start without waiting for the dependency release ? JM> https://issues.apache.org/jira/browse/CXF-8716 JM> https://issues.apache.org/jira/browse/CXF-8717 JM> https://issues.apache.org/jira/browse/CXF-8719 JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko wrote: >> Hi Jim, >> >> Yeah, we may need some time, I am also finalizing work on the Wiremock ( >> https://github.com/wiremock/wiremock/pull/1942), >> we use it in tests extensively. One of the largest efforts is migration to >> Jetty 11, I have started on that already but >> have difficulties with WebSockets migration, it needs rework and that is >> my focus at the moment. The Swagger 1.x we have >> to drop I believe, I don't see roadmap on Jakarta support there. >> >> Thanks! >> >> Best Regards, >> Andriy Redko >> >> JM> Hi Andriy, >> JM> It looks like we still have to wait for the other dependency jakarta >> JM> support available, like brave's new release to include this change : >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see any other >> JM> dependencies that haven't been released yet except OSGI and Karaf ? >> >> JM> Thanks, >> JM> Jim >> >> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma wrote: >> >> >> Thanks for the informative input, Freeman. >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good >> >> chance to do this job. When OSGI/Karaf jakarta release is ready, >> >> We can look at bringing this back with more improvement and refactor >> work >> >> to make it loosely coupled with core code. >> >> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang >> >> wrote: >> >> >> >>> Hi Jim, >> >>> >> >>> Sorry for the late reply, just back from vacation. >> >>> >> >>> About the OSGi part, the main problem is that the OSGi R9 spec which >> will >> >>> support Jakarta namespace is in progress and isn't released yet(and I >> don't >> >>> think there is a concrete release date for OSGi R9 spec in the new >> future). >> >>> Before OSGi R9 spec gets released and adopted by OSGi implementations >> like >> >>> Felix/Equinox, I don't think there is much we can do in CXF or even in >> >>> Karaf about this part. >> >>> >> >>> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit >> >>> seems the only option we have so far, and I'm +1 for this way >> now(Since we >> >>> don't know how long we need to wait for the proper OSGi spec released >> and >> >>> upstream projects can support it). >> >>> >> >>> Just my 2 cents. >> >>> Best Regards >> >>> Freeman >> >>> >> >>> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote: >> >>> >> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman >> about this topic several months ago and got to know >> there won't be Jakarta namespace support work in the future. I don't >> know if this has changed. >> Freeman, do you have some update on this ? >> >> >> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko >> wrote: >> >> > Hey Jim, >> > >> > I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real >> > blockers. For Swagger 1.x, we could >> > go ahead and drop the support altogether, this is quite isolated >> > feature. OSGi and Karaf are not, those >> > penetrated very deep into core. What worries me, if we drop >> everything >> > OSGi/Karaf related from 4.0.0, we >> > may need to bring it back some time in the future (with OSGi R9 [4] >> fe) >> > and that is going to be quite >> > difficult. From other side, this is probably the only option to have >> > 4.0.0 milestone out (we excluded some >> > modules from the build right now but that is more like a temporary >> hack >> > which we should not release upon, >> > even alphas). What do you think guys? >> > >> > Best Regards, >> > Andriy Redko >> > >> > [1] https://issues.apache.org/jira/browse/CXF-8714 >> > [2] https://issues.apache.org/jira/browse/CXF-8723 >> > [3] https://issues.apache.org/jira/browse/CXF-8722 >> > [4] https://github.com/osgi/osgi/milestone/5 >> > >> > JM> After we merged the jakarta branch to default branch main branch, >> > do we >> > JM> need to create some >> > JM> plan to do a future 4.x release? >> > >> > JM> There are a couple of to-do things under >> > JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla, >> > JM> and for some of them we can't do more things because of the >> jakarta >> > JM> dependency missing. It seems that some of the dependencies won't >> > JM> have the jakarta namespace a
