You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jim Ma <ma...@gmail.com> on 2022/11/07 08:19:12 UTC
CXF 4.0.0 jakarta release
Hi all,
After 9 months of work, we finally fixed/worked around all issues for
Jakarta support. Now all the cxf tests are passed:
https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say that
CXF successfully migrated to Jakarta namespace(and support Jakarta EE9.1).
To get cxf jakarta artifacts/binary available for the CXF community
especially the user who asked for this jakarta artifacts like [1] and get
more feedback from our community, do you think it's time to release the CXF
4.0.0 and what else do you think we should have in this new jakarta release
?
[1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
Thanks,
Jim
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
I looked at these 3 corba example failures. The hello-world example has
been fixed and the other two examples still have this failure:
Caused by: org.omg.CORBA.MARSHAL: FINE: 00810007: Underflow in
BufferManagerReadStream after last fragment in message
at jdk.proxy3.$Proxy73.endOfStream (Unknown Source)
at com.sun.corba.ee.impl.encoding.BufferManagerReadStream.underflow
(BufferManagerReadStream.java:113)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_1.grow
(CDRInputStream_1_1.java:91)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck
(CDRInputStream_1_2.java:106)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long
(CDRInputStream_1_0.java:374)
at
com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readStringOrIndirection
(CDRInputStream_1_0.java:411)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_string
(CDRInputStream_1_0.java:449)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_string
(CDRInputObject.java:368)
at com.sun.corba.ee.impl.corba.TypeCodeImpl.copy
(TypeCodeImpl.java:1895)
at com.sun.corba.ee.impl.corba.TypeCodeImpl.copy
(TypeCodeImpl.java:1951)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value (AnyImpl.java:572)
at com.sun.corba.ee.impl.corba.RequestImpl.unmarshalReply
(RequestImpl.java:350)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleDIIReply
(MessageMediatorImpl.java:441)
at
com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.processResponse
(ClientRequestDispatcherImpl.java:652)
at
com.sun.corba.ee.impl.protocol.ClientRequestDispatcherImpl.marshalingComplete
(ClientRequestDispatcherImpl.java:349)
at com.sun.corba.ee.impl.protocol.ClientDelegateImpl.invoke
(ClientDelegateImpl.java:238)
at com.sun.corba.ee.impl.corba.RequestImpl.doInvocation
(RequestImpl.java:310)
at com.sun.corba.ee.impl.corba.RequestImpl.invoke (RequestImpl.java:230)
at org.apache.cxf.binding.corba.CorbaConduit.buildRequest
(CorbaConduit.java:194)
It seems that extra settings are needed for CorbaConduit when using
glassfish-orb.
Here is my draft work :
https://github.com/jimma/cxf/commit/ad605d7b006559202b2abb5c50878ebac3a48b0e
<https://github.com/jimma/cxf/commit/ad605d7b006559202b2abb5c50878ebac3a48b0e>
I added some comments to my change about fixing these two issues:
1. GMBALTLIB00004: Multiple upper bounds not supported on S in glassfish-orb
2. java.lang.IllegalMonitorStateException: attempt to unlock read lock, not
locked by current thread
Hope this will help something.
Thanks,
Jim
On Tue, Dec 13, 2022 at 9:15 AM Andriy Redko <dr...@gmail.com> wrote:
> Thanks Dan,
>
> Here is my update.
>
> I have fixed:
> ws_notification (jms broker issues)
> ws_transaction (spring test runner doesn't actually run the test, not
> sure why)
>
>
> I will be working on:
> jaxws_graalvm
> jaxws_graalvm_dynamic
>
> Not looked yet:
> corba (weird ORB errors with java17, missing transaction classes with
> java11)
> js_browser_client_java_first (ClassNotFoundException:
> org.eclipse.jetty.util.resource.FileResource)
> sts (some spring bean definition issues)
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> >>
> >> I passed through all samples to make sure they are compilable and
> buildable, but I only
> >> run a handful of them, it would be great to check that all samples do
> actually work.
> >> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds
> like a plan? If
> >> yes, I will create an umbrella issue so we could track individual
> samples. Thank you
> >> for bringing this on up.
>
> DK> I went through all the other samples (non JMS and non RS) and fixed up
> the “easy” ones. What’s left:
>
> DK> corba (weird ORB errors with java17, missing transaction classes with
> java11)
> DK> js_browser_client_java_first (ClassNotFoundException:
> org.eclipse.jetty.util.resource.FileResource)
> DK> sts (some spring bean definition issues)
> DK> ws_notification (jms broker issues)
> DK> ws_transaction (spring test runner doesn't actually run the test, not
> sure why)
>
>
> DK> Did not try: (M1 mac, no "native-image” available)
> DK> jaxws_graalvm
> DK> jaxws_graalvm_dynamic
>
>
>
> DK> Not sure what to do with the CORBA things…. Likely could add the
> javax.transaction things and get it to run with Java11. Might be a case
> where the example works on 11 and not 17.
>
>
> DK> Dan
>
>
>
>
>
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >>
> >>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because
> of Spring 6),
> >>>> we also need JDK-17 to compile (same reason), but when Spring is not
> involved (it is
> >>>> optional by and large), JDK-11 is sufficient. We do have a number of
> samples (bundled
> >>>> with distribution) that run on JDK-11 with no issues. Please let me
> know your conclusions
> >>>> and if you need any help or pointers here. Thank you.
> >>
> >> DK> Found a minor class loader issue in cxf-core which fixed a couple
> of things related to using spring5. (Non-servlet spring 5) I’ll get
> that committed shortly once test run.
> >>
> >> DK> That said, has anyone actually gone through the samples and
> actually made sure they work? They compile OK (with java17), but many
> don’t actually work. None of the JMS samples seem to work at all.
> Some are still setup to use activemq (might be OK, but the class path
> doesn’t have activemq) and others that are setup for Artemis don’t have
> proper spring bean configuration for it and the connection factories cannot
> be created. I’ve only tested a few samples, but so far I’m seeing a bunch
> of issues.
> >>
> >>
> >>
> >> DK> Dan
> >>
> >>
> >>>>
> >>>> Best Regards,
> >>>> Andriy Redko
> >>>>
> >>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Andriy,
> >>>>>> Thanks for the quick update. Good to see this is running with the
> jenkins
> >>>>>> pipeline and all tests are green.
> >>>>>> Did it include all things for the CXF 4.0.0 release ?
> >>>>
> >>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My
> basic tests don’t work with java11, but I didn’t really get time to figure
> out why yet. I’m trying to figure out if it’s still actually compatible
> with java11 or not. If not, we should bump the jdk.version up.
> >>>>
> >>>>
> >>>> DK> Dan
> >>>>
> >>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Jim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> Hi Jim,
> >>>>>>>
> >>>>>>> I disabled this build (and
> >>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
> >>>>>>> because we run pipeline matrix [1] against both JDKs. These builds
> were
> >>>>>>> quite useful when
> >>>>>>> the main branch was unstable, but the pipeline should be
> sufficient now.
> >>>>>>> Please let me
> >>>>>>> know if you have any concerns, thank you.
> >>>>>>>
> >>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Andriy Redko
> >>>>>>>
> >>>>>>> JM> Did we already start the 4.0 release work ?
> >>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
> >>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last
> build
> >>>>>>> result
> >>>>>>> JM> was 7 days ago.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>>>> Hi Colm,
> >>>>>>>>>
> >>>>>>>>> I still wait for review on [1], if you or/and Dan could take a
> look,
> >>>>>>>>> would be great. The [2] could go in today but no user response
> on [3],
> >>>>>>>>> may need a bump to next version. Thank you.
> >>>>>>>>>
> >>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
> >>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
> >>>>>>>>>
> >>>>>>>>> Best Regards,
> >>>>>>>>> Andriy Redko
> >>>>>>>>>
> >>>>>>>>> COh> Hi Andriy,
> >>>>>>>>>
> >>>>>>>>> COh> What's the status of these open issues? Can they be merged
> today or
> >>>>>>>>> COh> else bumped to the next release?
> >>>>>>>>>
> >>>>>>>>> COh> Colm.
> >>>>>>>>>
> >>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <
> drreta@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hey guys,
> >>>>>>>>>>>
> >>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all
> of them
> >>>>>>>>>>> pull requests are opened, waiting for minor changes /
> confirmations
> >>>>>>>>> fixes work.
> >>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to
> eliminate
> >>>>>>> the
> >>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
> >>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
> >>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
> >>>>>>>>>>>
> >>>>>>>>>>> Best Regards,
> >>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>
> >>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
> >>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else
> planned?
> >>>>>>>>>>>
> >>>>>>>>>>>> Colm.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> >>>>>>>>>>>> <co...@apache.org> wrote:
> >>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy
> Redko on
> >>>>>>> two
> >>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good
> to
> >>>>>>> go.
> >>>>>>>>>>>>> Colm.
> >>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <
> mail2jimma@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>> Thanks Andriy and Dan !
> >>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <
> drreta@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <
> dkulp@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move
> forward!
> >>>>>>>>> @Colm @Dan
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x
> releases as
> >>>>>>>>> well? With
> >>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon
> (hopefully),
> >>>>>>>>> the 3.4.x
> >>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
> >>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases
> sometime
> >>>>>>>>> before the
> >>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of
> releases. I
> >>>>>>>>> have a
> >>>>>>>>>>>>>>>> bunch of things happening this week, but would next
> Monday work
> >>>>>>>>> for
> >>>>>>>>>>>>>>>> everyone? That would give a week to get any final
> updates in.
> >>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>> Thank you guys!
> >>>>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <
> mail2jimma@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Hi Andriy,
> >>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major
> thing
> >>>>>>>>> left we
> >>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do
> the
> >>>>>>>>> release
> >>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>>>> it's convenient for you?
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Jim
> >>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
> >>>>>>>>> jb@nanthrax.net
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>> JB
> >>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <
> mail2jimma@gmail.com
> >>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked
> around all
> >>>>>>>>> issues
> >>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >>>>>>>>>>>>>>>>>>>>
> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
> >>>>>>> and
> >>>>>>>>> we can
> >>>>>>>>>>>>>>>> say
> >>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and
> support
> >>>>>>>>> Jakarta
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> EE9.1).
> >>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the
> CXF
> >>>>>>>>> community
> >>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta
> artifacts
> >>>>>>> like
> >>>>>>>>> [1]
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> get
> >>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's
> time to
> >>>>>>>>> release
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> CXF
> >>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in
> this new
> >>>>>>>>> jakarta
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Jim
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Daniel Kulp
> >>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
> >>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Colm O hEigeartaigh <co...@apache.org>.
I fixed:
sts (some spring bean definition issues)
Colm.
On Tue, Dec 13, 2022 at 1:15 AM Andriy Redko <dr...@gmail.com> wrote:
>
> Thanks Dan,
>
> Here is my update.
>
> I have fixed:
> ws_notification (jms broker issues)
> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>
>
> I will be working on:
> jaxws_graalvm
> jaxws_graalvm_dynamic
>
> Not looked yet:
> corba (weird ORB errors with java17, missing transaction classes with java11)
> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
> sts (some spring bean definition issues)
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> >>
> >> I passed through all samples to make sure they are compilable and buildable, but I only
> >> run a handful of them, it would be great to check that all samples do actually work.
> >> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
> >> yes, I will create an umbrella issue so we could track individual samples. Thank you
> >> for bringing this on up.
>
> DK> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>
> DK> corba (weird ORB errors with java17, missing transaction classes with java11)
> DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
> DK> sts (some spring bean definition issues)
> DK> ws_notification (jms broker issues)
> DK> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>
>
> DK> Did not try: (M1 mac, no "native-image” available)
> DK> jaxws_graalvm
> DK> jaxws_graalvm_dynamic
>
>
>
> DK> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>
>
> DK> Dan
>
>
>
>
>
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >>
> >>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
> >>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
> >>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
> >>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
> >>>> and if you need any help or pointers here. Thank you.
> >>
> >> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
> >>
> >> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
> >>
> >>
> >>
> >> DK> Dan
> >>
> >>
> >>>>
> >>>> Best Regards,
> >>>> Andriy Redko
> >>>>
> >>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Andriy,
> >>>>>> Thanks for the quick update. Good to see this is running with the jenkins
> >>>>>> pipeline and all tests are green.
> >>>>>> Did it include all things for the CXF 4.0.0 release ?
> >>>>
> >>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
> >>>>
> >>>>
> >>>> DK> Dan
> >>>>
> >>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Jim
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Hi Jim,
> >>>>>>>
> >>>>>>> I disabled this build (and
> >>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
> >>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
> >>>>>>> quite useful when
> >>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
> >>>>>>> Please let me
> >>>>>>> know if you have any concerns, thank you.
> >>>>>>>
> >>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Andriy Redko
> >>>>>>>
> >>>>>>> JM> Did we already start the 4.0 release work ?
> >>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
> >>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
> >>>>>>> result
> >>>>>>> JM> was 7 days ago.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>>> Hi Colm,
> >>>>>>>>>
> >>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
> >>>>>>>>> would be great. The [2] could go in today but no user response on [3],
> >>>>>>>>> may need a bump to next version. Thank you.
> >>>>>>>>>
> >>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
> >>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
> >>>>>>>>>
> >>>>>>>>> Best Regards,
> >>>>>>>>> Andriy Redko
> >>>>>>>>>
> >>>>>>>>> COh> Hi Andriy,
> >>>>>>>>>
> >>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
> >>>>>>>>> COh> else bumped to the next release?
> >>>>>>>>>
> >>>>>>>>> COh> Colm.
> >>>>>>>>>
> >>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hey guys,
> >>>>>>>>>>>
> >>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
> >>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
> >>>>>>>>> fixes work.
> >>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
> >>>>>>> the
> >>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
> >>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
> >>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
> >>>>>>>>>>>
> >>>>>>>>>>> Best Regards,
> >>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>
> >>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
> >>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
> >>>>>>>>>>>
> >>>>>>>>>>>> Colm.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> >>>>>>>>>>>> <co...@apache.org> wrote:
> >>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
> >>>>>>> two
> >>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
> >>>>>>> go.
> >>>>>>>>>>>>> Colm.
> >>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>> Thanks Andriy and Dan !
> >>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
> >>>>>>>>> @Colm @Dan
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
> >>>>>>>>> well? With
> >>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
> >>>>>>>>> the 3.4.x
> >>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
> >>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
> >>>>>>>>> before the
> >>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
> >>>>>>>>> have a
> >>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
> >>>>>>>>> for
> >>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
> >>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>> Thank you guys!
> >>>>>>>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Hi Andriy,
> >>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
> >>>>>>>>> left we
> >>>>>>>>>>>>>>>> need
> >>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
> >>>>>>>>> release
> >>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>>>> it's convenient for you?
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Jim
> >>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
> >>>>>>>>> jb@nanthrax.net
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>>>>>>> JB
> >>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
> >>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
> >>>>>>>>> issues
> >>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
> >>>>>>> and
> >>>>>>>>> we can
> >>>>>>>>>>>>>>>> say
> >>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
> >>>>>>>>> Jakarta
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> EE9.1).
> >>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
> >>>>>>>>> community
> >>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
> >>>>>>> like
> >>>>>>>>> [1]
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> get
> >>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
> >>>>>>>>> release
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> CXF
> >>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
> >>>>>>>>> jakarta
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Jim
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Daniel Kulp
> >>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
> >>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Thanks Dan,
Here is my update.
I have fixed:
ws_notification (jms broker issues)
ws_transaction (spring test runner doesn't actually run the test, not sure why)
I will be working on:
jaxws_graalvm
jaxws_graalvm_dynamic
Not looked yet:
corba (weird ORB errors with java17, missing transaction classes with java11)
js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
sts (some spring bean definition issues)
Thanks.
Best Regards,
Andriy Redko
>>
>> I passed through all samples to make sure they are compilable and buildable, but I only
>> run a handful of them, it would be great to check that all samples do actually work.
>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>> for bringing this on up.
DK> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
DK> corba (weird ORB errors with java17, missing transaction classes with java11)
DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
DK> sts (some spring bean definition issues)
DK> ws_notification (jms broker issues)
DK> ws_transaction (spring test runner doesn't actually run the test, not sure why)
DK> Did not try: (M1 mac, no "native-image” available)
DK> jaxws_graalvm
DK> jaxws_graalvm_dynamic
DK> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
DK> Dan
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>> and if you need any help or pointers here. Thank you.
>>
>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>
>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>
>>
>>
>> DK> Dan
>>
>>
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>
>>>>>> Hi Andriy,
>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>> pipeline and all tests are green.
>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>
>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>
>>>>
>>>> DK> Dan
>>>>
>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> I disabled this build (and
>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>> quite useful when
>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>> Please let me
>>>>>>> know if you have any concerns, thank you.
>>>>>>>
>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>> result
>>>>>>> JM> was 7 days ago.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>
>>>>>>>>> Hi Colm,
>>>>>>>>>
>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>
>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Andriy Redko
>>>>>>>>>
>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>
>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>
>>>>>>>>> COh> Colm.
>>>>>>>>>
>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hey guys,
>>>>>>>>>>>
>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>> fixes work.
>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>> the
>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>
>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>
>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>
>>>>>>>>>>>> Colm.
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>> two
>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>> go.
>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>> @Colm @Dan
>>>>>>>>>>>
>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>> well? With
>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>> before the
>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>> have a
>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>> for
>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>> left we
>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>> release
>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>> issues
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>> and
>>>>>>>>> we can
>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>> Jakarta
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>> like
>>>>>>>>> [1]
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>> release
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>> jakarta
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
Since a large majority of the sample are now working with just a few exceptions, we’re likely OK to do the 4.0 release and we can log bugs for the couple of remaining. I’ll try and build the release sometime this weekend so that we can get it fully released before everyone (including me) heads out for the holidays.
Thanks for all the efforts trying to get the samples working again. Having a few samples not work is one thing, having almost half not working is a big issue so I’m glad that’s not the case now.
Thanks
Dan
> On Dec 15, 2022, at 9:32 PM, Andriy Redko <dr...@gmail.com> wrote:
>
> Hey guys,
>
> We're getting closer, here is what's left:
>
> DK>> jaxrs/basic_oidc
> DK>> jaxrs/big_query
> DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
> DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>
> It is very likely we would have to drop description_openapi_microprofile_spring (for the time being) since
> Geronimo OpenAPI does not support Microprofile OpenApi 3.0 yet (I will double check). I am picking these
> ones to finish up:
>
> DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
> DK>> jax_rs/spring_boot_scan
> DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
> DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
>
>
> Thank you.
>
> Best Regards,
> Andriy Redko
>
> AR> Fixed these ones:
>
> DK>> jms_spring_config - hangs on client stop
> DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
> DK>> jms_pubsub - broker doesn't start
>
>
> AR> And will pick these ones:
>
> DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
> DK>> jax_rs/spring_boot_scan
> DK>> jax_rs/tracing_brave
> DK>> jax_rs/tracing_opentracing
> DK>> jax_rs/tracing_opentracing_camel
> DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
> DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
> DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
>
> AR> Here is what's left:
>
> DK>> jaxrs/basic_oidc
> DK>> jaxrs/big_query
> DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
> DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>
> AR> Thanks!
>
> AR> Best Regards,
> AR> Andriy Redko
>
> DK>>> jaxws_graalvm
> DK>>> jaxws_graalvm_dynamic
> DK>>> jax_rs/graalvm_basic
>
> AR>> Also fixed:
>
> DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
> DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
> DK>>> jax_rs/sse_tomcat - classpath? Jackson not found
>
> AR>> And will pick these ones:
>
> DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
> DK>>> jms_spring_config - hangs on client stop
> DK>>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
> DK>>> jms_pubsub - broker doesn't start
> DK>>> jax_rs/spring_boot_scan
> DK>>> jax_rs/tracing_brave
> DK>>> jax_rs/tracing_opentracing
> DK>>> jax_rs/tracing_opentracing_camel
> DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
> DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
> DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
>
> AR>> Here is what's left:
>
> DK>>> jaxrs/basic_oidc
> DK>>> jaxrs/big_query
> DK>>> corba (weird ORB errors with java17, missing transaction classes with java11)
> DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>
> AR>> [1] https://issues.apache.org/jira/browse/CXF-8743
>
> AR>> Thanks!
>
> AR>> Best Regards,
> AR>> Andriy Redko
>
>
> DK>>> I finished going through all the samples. This is what’s left:
>
> DK>>> Problems:
> DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
> DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
> DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
> DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
> DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
> DK>>> jax_rs/sse_tomcat - classpath? Jackson not found
> DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
> DK>>> corba (weird ORB errors with java17, missing transaction classes with java11)
> DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
> DK>>> jms_spring_config - hangs on client stop
> DK>>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
> DK>>> jms_pubsub - broker doesn't start
>
>
> DK>>> Did not try: (M1 mac, not "native-image")
> DK>>> jaxws_graalvm
> DK>>> jaxws_graalvm_dynamic
> DK>>> jax_rs/graalvm_basic
>
> DK>>> Did not try: (other setup things required) (ex: google dev id, docker, etc..)
> DK>>> jaxrs/basic_oidc
> DK>>> jaxrs/big_query
> DK>>> jax_rs/spring_boot_scan
> DK>>> jax_rs/tracing_brave
> DK>>> jax_rs/tracing_opentracing
> DK>>> jax_rs/tracing_opentracing_camel
>
>
> DK>>> Feel free to grab something and fix it. :)
>
> DK>>> Dan
>
>
>
>
>
>>>>> On Dec 12, 2022, at 4:21 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> I passed through all samples to make sure they are compilable and buildable, but I only
>>>>>> run a handful of them, it would be great to check that all samples do actually work.
>>>>>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>>>>>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>>>>>> for bringing this on up.
>>>>>
>>>>> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>>>>>
>>>>> corba (weird ORB errors with java17, missing transaction classes with java11)
>>>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>>>>> sts (some spring bean definition issues)
>>>>> ws_notification (jms broker issues)
>>>>> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>>>>>
>>>>>
>>>>> Did not try: (M1 mac, no "native-image” available)
>>>>> jaxws_graalvm
>>>>> jaxws_graalvm_dynamic
>>>>>
>>>>>
>>>>>
>>>>> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>>
>>>>>>
>>>>>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>>>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>>>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>>>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>>>>>> and if you need any help or pointers here. Thank you.
>>>>>>
>>>>>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>>>>>
>>>>>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>>>>>
>>>>>>
>>>>>>
>>>>>> DK> Dan
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Andriy Redko
>>>>>>>>
>>>>>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Andriy,
>>>>>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>>>>>> pipeline and all tests are green.
>>>>>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>>>>>
>>>>>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>>>>>
>>>>>>>>
>>>>>>>> DK> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>
>>>>>>>>>>> I disabled this build (and
>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>>>>>> quite useful when
>>>>>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>>>>>> Please let me
>>>>>>>>>>> know if you have any concerns, thank you.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>
>>>>>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>>>>>> result
>>>>>>>>>>> JM> was 7 days ago.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> Hi Colm,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>
>>>>>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>>>>>
>>>>>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>>>>>
>>>>>>>>>>>>> COh> Colm.
>>>>>>>>>>>>>
>>>>>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>>>>>> fixes work.
>>>>>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>>>>>> the
>>>>>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>>>>>> two
>>>>>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>>>>>> go.
>>>>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>>>>>> @Colm @Dan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>>>>>> well? With
>>>>>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>>>>>> before the
>>>>>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>>>>>> left we
>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>>>>>> and
>>>>>>>>>>>>> we can
>>>>>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>>>>>> Jakarta
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>>>>>> like
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>>>>>> jakarta
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org <ma...@apache.org>
>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hey guys,
We're getting closer, here is what's left:
DK>> jaxrs/basic_oidc
DK>> jaxrs/big_query
DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
It is very likely we would have to drop description_openapi_microprofile_spring (for the time being) since
Geronimo OpenAPI does not support Microprofile OpenApi 3.0 yet (I will double check). I am picking these
ones to finish up:
DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>> jax_rs/spring_boot_scan
DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
Thank you.
Best Regards,
Andriy Redko
AR> Fixed these ones:
DK>> jms_spring_config - hangs on client stop
DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK>> jms_pubsub - broker doesn't start
AR> And will pick these ones:
DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>> jax_rs/spring_boot_scan
DK>> jax_rs/tracing_brave
DK>> jax_rs/tracing_opentracing
DK>> jax_rs/tracing_opentracing_camel
DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
AR> Here is what's left:
DK>> jaxrs/basic_oidc
DK>> jaxrs/big_query
DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
AR> Thanks!
AR> Best Regards,
AR> Andriy Redko
DK>>> jaxws_graalvm
DK>>> jaxws_graalvm_dynamic
DK>>> jax_rs/graalvm_basic
AR>> Also fixed:
DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK>>> jax_rs/sse_tomcat - classpath? Jackson not found
AR>> And will pick these ones:
DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>>> jms_spring_config - hangs on client stop
DK>>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK>>> jms_pubsub - broker doesn't start
DK>>> jax_rs/spring_boot_scan
DK>>> jax_rs/tracing_brave
DK>>> jax_rs/tracing_opentracing
DK>>> jax_rs/tracing_opentracing_camel
DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
AR>> Here is what's left:
DK>>> jaxrs/basic_oidc
DK>>> jaxrs/big_query
DK>>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
AR>> [1] https://issues.apache.org/jira/browse/CXF-8743
AR>> Thanks!
AR>> Best Regards,
AR>> Andriy Redko
DK>>> I finished going through all the samples. This is what’s left:
DK>>> Problems:
DK>>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK>>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK>>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK>>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
DK>>> jax_rs/sse_tomcat - classpath? Jackson not found
DK>>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
DK>>> jms_spring_config - hangs on client stop
DK>>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK>>> jms_pubsub - broker doesn't start
DK>>> Did not try: (M1 mac, not "native-image")
DK>>> jaxws_graalvm
DK>>> jaxws_graalvm_dynamic
DK>>> jax_rs/graalvm_basic
DK>>> Did not try: (other setup things required) (ex: google dev id, docker, etc..)
DK>>> jaxrs/basic_oidc
DK>>> jaxrs/big_query
DK>>> jax_rs/spring_boot_scan
DK>>> jax_rs/tracing_brave
DK>>> jax_rs/tracing_opentracing
DK>>> jax_rs/tracing_opentracing_camel
DK>>> Feel free to grab something and fix it. :)
DK>>> Dan
>>>> On Dec 12, 2022, at 4:21 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>>
>>>>>
>>>>> I passed through all samples to make sure they are compilable and buildable, but I only
>>>>> run a handful of them, it would be great to check that all samples do actually work.
>>>>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>>>>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>>>>> for bringing this on up.
>>>>
>>>> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>>>>
>>>> corba (weird ORB errors with java17, missing transaction classes with java11)
>>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>>>> sts (some spring bean definition issues)
>>>> ws_notification (jms broker issues)
>>>> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>>>>
>>>>
>>>> Did not try: (M1 mac, no "native-image” available)
>>>> jaxws_graalvm
>>>> jaxws_graalvm_dynamic
>>>>
>>>>
>>>>
>>>> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>>
>>>>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>>>>> and if you need any help or pointers here. Thank you.
>>>>>
>>>>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>>>>
>>>>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>>>>
>>>>>
>>>>>
>>>>> DK> Dan
>>>>>
>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Andriy,
>>>>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>>>>> pipeline and all tests are green.
>>>>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>>>>
>>>>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>>>>
>>>>>>>
>>>>>>> DK> Dan
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Jim,
>>>>>>>>>>
>>>>>>>>>> I disabled this build (and
>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>>>>> quite useful when
>>>>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>>>>> Please let me
>>>>>>>>>> know if you have any concerns, thank you.
>>>>>>>>>>
>>>>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Andriy Redko
>>>>>>>>>>
>>>>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>>>>> result
>>>>>>>>>> JM> was 7 days ago.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>> Hi Colm,
>>>>>>>>>>>>
>>>>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>
>>>>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>>>>
>>>>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>>>>
>>>>>>>>>>>> COh> Colm.
>>>>>>>>>>>>
>>>>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>>>>> fixes work.
>>>>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>>>>> the
>>>>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>>>>> two
>>>>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>>>>> go.
>>>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>>>>> @Colm @Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>>>>> well? With
>>>>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>>>>> before the
>>>>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>>>>> left we
>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>>>>> and
>>>>>>>>>>>> we can
>>>>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>>>>> Jakarta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>>>>> like
>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>>>>> jakarta
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org <ma...@apache.org>
>>>> Talend - https://talend.com <https://talend.com/>
>>>>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Fixed these ones:
DK> jms_spring_config - hangs on client stop
DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK> jms_pubsub - broker doesn't start
And will pick these ones:
DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK> jax_rs/spring_boot_scan
DK> jax_rs/tracing_brave
DK> jax_rs/tracing_opentracing
DK> jax_rs/tracing_opentracing_camel
DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
Here is what's left:
DK> jaxrs/basic_oidc
DK> jaxrs/big_query
DK> corba (weird ORB errors with java17, missing transaction classes with java11)
DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
Thanks!
Best Regards,
Andriy Redko
DK>> jaxws_graalvm
DK>> jaxws_graalvm_dynamic
DK>> jax_rs/graalvm_basic
AR> Also fixed:
DK>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK>> jax_rs/sse_tomcat - classpath? Jackson not found
AR> And will pick these ones:
DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>> jms_spring_config - hangs on client stop
DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK>> jms_pubsub - broker doesn't start
DK>> jax_rs/spring_boot_scan
DK>> jax_rs/tracing_brave
DK>> jax_rs/tracing_opentracing
DK>> jax_rs/tracing_opentracing_camel
DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
AR> Here is what's left:
DK>> jaxrs/basic_oidc
DK>> jaxrs/big_query
DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
AR> [1] https://issues.apache.org/jira/browse/CXF-8743
AR> Thanks!
AR> Best Regards,
AR> Andriy Redko
DK>> I finished going through all the samples. This is what’s left:
DK>> Problems:
DK>> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK>> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK>> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK>> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK>> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
DK>> jax_rs/sse_tomcat - classpath? Jackson not found
DK>> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK>> corba (weird ORB errors with java17, missing transaction classes with java11)
DK>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
DK>> jms_spring_config - hangs on client stop
DK>> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK>> jms_pubsub - broker doesn't start
DK>> Did not try: (M1 mac, not "native-image")
DK>> jaxws_graalvm
DK>> jaxws_graalvm_dynamic
DK>> jax_rs/graalvm_basic
DK>> Did not try: (other setup things required) (ex: google dev id, docker, etc..)
DK>> jaxrs/basic_oidc
DK>> jaxrs/big_query
DK>> jax_rs/spring_boot_scan
DK>> jax_rs/tracing_brave
DK>> jax_rs/tracing_opentracing
DK>> jax_rs/tracing_opentracing_camel
DK>> Feel free to grab something and fix it. :)
DK>> Dan
>>> On Dec 12, 2022, at 4:21 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> I passed through all samples to make sure they are compilable and buildable, but I only
>>>> run a handful of them, it would be great to check that all samples do actually work.
>>>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>>>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>>>> for bringing this on up.
>>>
>>> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>>>
>>> corba (weird ORB errors with java17, missing transaction classes with java11)
>>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>>> sts (some spring bean definition issues)
>>> ws_notification (jms broker issues)
>>> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>>>
>>>
>>> Did not try: (M1 mac, no "native-image” available)
>>> jaxws_graalvm
>>> jaxws_graalvm_dynamic
>>>
>>>
>>>
>>> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>>
>>>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>>>> and if you need any help or pointers here. Thank you.
>>>>
>>>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>>>
>>>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>>>
>>>>
>>>>
>>>> DK> Dan
>>>>
>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>>
>>>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Andriy,
>>>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>>>> pipeline and all tests are green.
>>>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>>>
>>>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>>>
>>>>>>
>>>>>> DK> Dan
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>> I disabled this build (and
>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>>>> quite useful when
>>>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>>>> Please let me
>>>>>>>>> know if you have any concerns, thank you.
>>>>>>>>>
>>>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Andriy Redko
>>>>>>>>>
>>>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>>>> result
>>>>>>>>> JM> was 7 days ago.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>> Hi Colm,
>>>>>>>>>>>
>>>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>
>>>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>>>
>>>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>>>
>>>>>>>>>>> COh> Colm.
>>>>>>>>>>>
>>>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>>>> fixes work.
>>>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>>>> the
>>>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>>>> two
>>>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>>>> go.
>>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>>>> @Colm @Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>>>> well? With
>>>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>>>> before the
>>>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>>>> left we
>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>>>> and
>>>>>>>>>>> we can
>>>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>>>> Jakarta
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>>>> like
>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>>>> jakarta
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org <ma...@apache.org>
>>> Talend - https://talend.com <https://talend.com/>
>>>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Fixed (as part of [1]) all GraalVM samples:
DK> jaxws_graalvm
DK> jaxws_graalvm_dynamic
DK> jax_rs/graalvm_basic
Also fixed:
DK> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK> jax_rs/sse_tomcat - classpath? Jackson not found
And will pick these ones:
DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK> jms_spring_config - hangs on client stop
DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK> jms_pubsub - broker doesn't start
DK> jax_rs/spring_boot_scan
DK> jax_rs/tracing_brave
DK> jax_rs/tracing_opentracing
DK> jax_rs/tracing_opentracing_camel
DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
Here is what's left:
DK> jaxrs/basic_oidc
DK> jaxrs/big_query
DK> corba (weird ORB errors with java17, missing transaction classes with java11)
DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
[1] https://issues.apache.org/jira/browse/CXF-8743
Thanks!
Best Regards,
Andriy Redko
DK> I finished going through all the samples. This is what’s left:
DK> Problems:
DK> jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
DK> java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
DK> jax_rs/description_openapi_v3_spring - classpath? Jackson not found
DK> jax_rs/description_openapi_v3_web - classpath? Jackson not found
DK> jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
DK> jax_rs/sse_tomcat - classpath? Jackson not found
DK> jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
DK> corba (weird ORB errors with java17, missing transaction classes with java11)
DK> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
DK> jms_spring_config - hangs on client stop
DK> jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
DK> jms_pubsub - broker doesn't start
DK> Did not try: (M1 mac, not "native-image")
DK> jaxws_graalvm
DK> jaxws_graalvm_dynamic
DK> jax_rs/graalvm_basic
DK> Did not try: (other setup things required) (ex: google dev id, docker, etc..)
DK> jaxrs/basic_oidc
DK> jaxrs/big_query
DK> jax_rs/spring_boot_scan
DK> jax_rs/tracing_brave
DK> jax_rs/tracing_opentracing
DK> jax_rs/tracing_opentracing_camel
DK> Feel free to grab something and fix it. :)
DK> Dan
>> On Dec 12, 2022, at 4:21 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> I passed through all samples to make sure they are compilable and buildable, but I only
>>> run a handful of them, it would be great to check that all samples do actually work.
>>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>>> for bringing this on up.
>>
>> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>>
>> corba (weird ORB errors with java17, missing transaction classes with java11)
>> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
>> sts (some spring bean definition issues)
>> ws_notification (jms broker issues)
>> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>>
>>
>> Did not try: (M1 mac, no "native-image” available)
>> jaxws_graalvm
>> jaxws_graalvm_dynamic
>>
>>
>>
>> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>>
>>
>> Dan
>>
>>
>>
>>
>>
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>>
>>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>>> and if you need any help or pointers here. Thank you.
>>>
>>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>>
>>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>>
>>>
>>>
>>> DK> Dan
>>>
>>>
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Andriy,
>>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>>> pipeline and all tests are green.
>>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>>
>>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>>
>>>>>
>>>>> DK> Dan
>>>>>
>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>> I disabled this build (and
>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>>> quite useful when
>>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>>> Please let me
>>>>>>>> know if you have any concerns, thank you.
>>>>>>>>
>>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Andriy Redko
>>>>>>>>
>>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>>> result
>>>>>>>> JM> was 7 days ago.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>> Hi Colm,
>>>>>>>>>>
>>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Andriy Redko
>>>>>>>>>>
>>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>>
>>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>>
>>>>>>>>>> COh> Colm.
>>>>>>>>>>
>>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>>
>>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>>> fixes work.
>>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>>> the
>>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>>
>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>>> two
>>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>>> go.
>>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>>> @Colm @Dan
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>>> well? With
>>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>>> before the
>>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>>> have a
>>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>>> for
>>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>>> left we
>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>>> release
>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>>> issues
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>>> and
>>>>>>>>>> we can
>>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>>> Jakarta
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>>> like
>>>>>>>>>> [1]
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>>> release
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>>> jakarta
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org <ma...@apache.org>
>> Talend - https://talend.com <https://talend.com/>
>>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
I finished going through all the samples. This is what’s left:
Problems:
jax_rs/description_openapi_microprofile_spring - spring config or claspath issue
java.lang.ClassNotFoundException: org.eclipse.microprofile.openapi.models.servers.ServerVariables
jax_rs/description_openapi_v3_spring - classpath? Jackson not found
jax_rs/description_openapi_v3_web - classpath? Jackson not found
jax_rs/spring_security - lots of stack traces on startup, likely spring config issues
jax_rs/sse_tomcat - classpath? Jackson not found
jax_rs/websocket - gives "WARNING: Websocket protocol not supported" which seems to defeat the entire purpose of the sample
corba (weird ORB errors with java17, missing transaction classes with java11)
js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
jms_spring_config - hangs on client stop
jms_spec_demo - server doesn't start, JNDI, org.apache.activemq.jndi.ActiveMQInitialContextFactory (not artemis)
jms_pubsub - broker doesn't start
Did not try: (M1 mac, not "native-image")
jaxws_graalvm
jaxws_graalvm_dynamic
jax_rs/graalvm_basic
Did not try: (other setup things required) (ex: google dev id, docker, etc..)
jaxrs/basic_oidc
jaxrs/big_query
jax_rs/spring_boot_scan
jax_rs/tracing_brave
jax_rs/tracing_opentracing
jax_rs/tracing_opentracing_camel
Feel free to grab something and fix it. :)
Dan
> On Dec 12, 2022, at 4:21 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> I passed through all samples to make sure they are compilable and buildable, but I only
>> run a handful of them, it would be great to check that all samples do actually work.
>> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
>> yes, I will create an umbrella issue so we could track individual samples. Thank you
>> for bringing this on up.
>
> I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
>
> corba (weird ORB errors with java17, missing transaction classes with java11)
> js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
> sts (some spring bean definition issues)
> ws_notification (jms broker issues)
> ws_transaction (spring test runner doesn't actually run the test, not sure why)
>
>
> Did not try: (M1 mac, no "native-image” available)
> jaxws_graalvm
> jaxws_graalvm_dynamic
>
>
>
> Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
>
>
> Dan
>
>
>
>
>
>>
>> Best Regards,
>> Andriy Redko
>>
>>
>>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>>> and if you need any help or pointers here. Thank you.
>>
>> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>>
>> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>>
>>
>>
>> DK> Dan
>>
>>
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>>
>>>>>> Hi Andriy,
>>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>>> pipeline and all tests are green.
>>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>>
>>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>>
>>>>
>>>> DK> Dan
>>>>
>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> I disabled this build (and
>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>>> quite useful when
>>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>>> Please let me
>>>>>>> know if you have any concerns, thank you.
>>>>>>>
>>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>>> result
>>>>>>> JM> was 7 days ago.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>>
>>>>>>>>> Hi Colm,
>>>>>>>>>
>>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>>
>>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Andriy Redko
>>>>>>>>>
>>>>>>>>> COh> Hi Andriy,
>>>>>>>>>
>>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>>> COh> else bumped to the next release?
>>>>>>>>>
>>>>>>>>> COh> Colm.
>>>>>>>>>
>>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hey guys,
>>>>>>>>>>>
>>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>>> fixes work.
>>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>>> the
>>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>>
>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>
>>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>>
>>>>>>>>>>>> Colm.
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>>> two
>>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>>> go.
>>>>>>>>>>>>> Colm.
>>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>>> @Colm @Dan
>>>>>>>>>>>
>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>>> well? With
>>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>>> before the
>>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>>> have a
>>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>>> for
>>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>>> left we
>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>>> release
>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>>> issues
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>>> and
>>>>>>>>> we can
>>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>>> Jakarta
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>>> like
>>>>>>>>> [1]
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>>> release
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>>> jakarta
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org>
> Talend - https://talend.com <https://talend.com/>
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
>
> I passed through all samples to make sure they are compilable and buildable, but I only
> run a handful of them, it would be great to check that all samples do actually work.
> I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
> yes, I will create an umbrella issue so we could track individual samples. Thank you
> for bringing this on up.
I went through all the other samples (non JMS and non RS) and fixed up the “easy” ones. What’s left:
corba (weird ORB errors with java17, missing transaction classes with java11)
js_browser_client_java_first (ClassNotFoundException: org.eclipse.jetty.util.resource.FileResource)
sts (some spring bean definition issues)
ws_notification (jms broker issues)
ws_transaction (spring test runner doesn't actually run the test, not sure why)
Did not try: (M1 mac, no "native-image” available)
jaxws_graalvm
jaxws_graalvm_dynamic
Not sure what to do with the CORBA things…. Likely could add the javax.transaction things and get it to run with Java11. Might be a case where the example works on 11 and not 17.
Dan
>
> Best Regards,
> Andriy Redko
>
>
>>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>>> and if you need any help or pointers here. Thank you.
>
> DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
>
> DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
>
>
>
> DK> Dan
>
>
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>>
>>>>> Hi Andriy,
>>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>>> pipeline and all tests are green.
>>>>> Did it include all things for the CXF 4.0.0 release ?
>>>
>>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>>
>>>
>>> DK> Dan
>>>
>>>
>>>>>
>>>>> Thanks,
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>> I disabled this build (and
>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>>> quite useful when
>>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>>> Please let me
>>>>>> know if you have any concerns, thank you.
>>>>>>
>>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>>
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>>
>>>>>> JM> Did we already start the 4.0 release work ?
>>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>>> result
>>>>>> JM> was 7 days ago.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>>
>>>>>>>> Hi Colm,
>>>>>>>>
>>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>>> may need a bump to next version. Thank you.
>>>>>>>>
>>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Andriy Redko
>>>>>>>>
>>>>>>>> COh> Hi Andriy,
>>>>>>>>
>>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>>> COh> else bumped to the next release?
>>>>>>>>
>>>>>>>> COh> Colm.
>>>>>>>>
>>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hey guys,
>>>>>>>>>>
>>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>>> fixes work.
>>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>>> the
>>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>>
>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Andriy Redko
>>>>>>>>>>
>>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>>
>>>>>>>>>>> Colm.
>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>>> two
>>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>>> go.
>>>>>>>>>>>> Colm.
>>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>>> @Colm @Dan
>>>>>>>>>>
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>>> well? With
>>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>>> the 3.4.x
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>>> before the
>>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>>> have a
>>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>>> for
>>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>>> left we
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>>
>>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>>> release
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>>> issues
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>>> and
>>>>>>>> we can
>>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>>> Jakarta
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>>> community
>>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>>> like
>>>>>>>> [1]
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>>> release
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>>> jakarta
>>>>>>>>>>
>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Dan,
I passed through all samples to make sure they are compilable and buildable, but I only
run a handful of them, it would be great to check that all samples do actually work.
I can take *jms* and *jaxrs* ones, may take a few days though. Sounds like a plan? If
yes, I will create an umbrella issue so we could track individual samples. Thank you
for bringing this on up.
Best Regards,
Andriy Redko
>> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
>> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
>> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
>> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
>> and if you need any help or pointers here. Thank you.
DK> Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
DK> That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
DK> Dan
>>
>> Best Regards,
>> Andriy Redko
>>
>> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>>
>>>> Hi Andriy,
>>>> Thanks for the quick update. Good to see this is running with the jenkins
>>>> pipeline and all tests are green.
>>>> Did it include all things for the CXF 4.0.0 release ?
>>
>> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>>
>>
>> DK> Dan
>>
>>
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>>
>>>>> Hi Jim,
>>>>>
>>>>> I disabled this build (and
>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>>> quite useful when
>>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>>> Please let me
>>>>> know if you have any concerns, thank you.
>>>>>
>>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>> JM> Did we already start the 4.0 release work ?
>>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>>> result
>>>>> JM> was 7 days ago.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>>
>>>>>>> Hi Colm,
>>>>>>>
>>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>>> may need a bump to next version. Thank you.
>>>>>>>
>>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>> COh> Hi Andriy,
>>>>>>>
>>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>>> COh> else bumped to the next release?
>>>>>>>
>>>>>>> COh> Colm.
>>>>>>>
>>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hey guys,
>>>>>>>>>
>>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>>> fixes work.
>>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>>> the
>>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>>
>>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Andriy Redko
>>>>>>>>>
>>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>>
>>>>>>>>>> Colm.
>>>>>>>>>
>>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>>> two
>>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>>> go.
>>>>>>>>>>> Colm.
>>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>>> wrote:
>>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>>> @Colm @Dan
>>>>>>>>>
>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>>> well? With
>>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>>> the 3.4.x
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>>> before the
>>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>>> have a
>>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>>> for
>>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>>> left we
>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>>
>>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>>> release
>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>>> issues
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>>> and
>>>>>>> we can
>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>>> Jakarta
>>>>>>>>>
>>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>>> community
>>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>>> like
>>>>>>> [1]
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>>> release
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>>> jakarta
>>>>>>>>>
>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>> [1]
>>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
> Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
> we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
> optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
> with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
> and if you need any help or pointers here. Thank you.
Found a minor class loader issue in cxf-core which fixed a couple of things related to using spring5. (Non-servlet spring 5) I’ll get that committed shortly once test run.
That said, has anyone actually gone through the samples and actually made sure they work? They compile OK (with java17), but many don’t actually work. None of the JMS samples seem to work at all. Some are still setup to use activemq (might be OK, but the class path doesn’t have activemq) and others that are setup for Artemis don’t have proper spring bean configuration for it and the connection factories cannot be created. I’ve only tested a few samples, but so far I’m seeing a bunch of issues.
Dan
>
> Best Regards,
> Andriy Redko
>
> DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>>
>>> Hi Andriy,
>>> Thanks for the quick update. Good to see this is running with the jenkins
>>> pipeline and all tests are green.
>>> Did it include all things for the CXF 4.0.0 release ?
>
> DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
>
>
> DK> Dan
>
>
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>>
>>>> Hi Jim,
>>>>
>>>> I disabled this build (and
>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>>> quite useful when
>>>> the main branch was unstable, but the pipeline should be sufficient now.
>>>> Please let me
>>>> know if you have any concerns, thank you.
>>>>
>>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>> JM> Did we already start the 4.0 release work ?
>>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>>> result
>>>> JM> was 7 days ago.
>>>>
>>>>
>>>>
>>>>
>>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>>
>>>>>> Hi Colm,
>>>>>>
>>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>>> may need a bump to next version. Thank you.
>>>>>>
>>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>>
>>>>>> COh> Hi Andriy,
>>>>>>
>>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>>> COh> else bumped to the next release?
>>>>>>
>>>>>> COh> Colm.
>>>>>>
>>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>>> wrote:
>>>>>>>>
>>>>>>>> Hey guys,
>>>>>>>>
>>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>>> fixes work.
>>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>>> the
>>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>>
>>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Andriy Redko
>>>>>>>>
>>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>>
>>>>>>>>> Colm.
>>>>>>>>
>>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>>> two
>>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>>> go.
>>>>>>>>>> Colm.
>>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>>> @Colm @Dan
>>>>>>>>
>>>>>>>>>>>>> do
>>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>>> well? With
>>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>>> the 3.4.x
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>>> before the
>>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>>> have a
>>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>>> for
>>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>>> left we
>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>>
>>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>>> release
>>>>>>>>>>>> when
>>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>>
>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>>> issues
>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>>> and
>>>>>> we can
>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>>> Jakarta
>>>>>>>>
>>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>>> community
>>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>>> like
>>>>>> [1]
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>>> release
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>>> jakarta
>>>>>>>>
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>> [1]
>>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Dan,
Yes, as Jim mentioned, most of our tests need JDK-17 to run (because of Spring 6),
we also need JDK-17 to compile (same reason), but when Spring is not involved (it is
optional by and large), JDK-11 is sufficient. We do have a number of samples (bundled
with distribution) that run on JDK-11 with no issues. Please let me know your conclusions
and if you need any help or pointers here. Thank you.
Best Regards,
Andriy Redko
DK> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>>
>> Hi Andriy,
>> Thanks for the quick update. Good to see this is running with the jenkins
>> pipeline and all tests are green.
>> Did it include all things for the CXF 4.0.0 release ?
DK> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
DK> Dan
>>
>> Thanks,
>> Jim
>>
>>
>>
>>
>>
>> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>>
>>> Hi Jim,
>>>
>>> I disabled this build (and
>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>>> because we run pipeline matrix [1] against both JDKs. These builds were
>>> quite useful when
>>> the main branch was unstable, but the pipeline should be sufficient now.
>>> Please let me
>>> know if you have any concerns, thank you.
>>>
>>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> JM> Did we already start the 4.0 release work ?
>>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>>> result
>>> JM> was 7 days ago.
>>>
>>>
>>>
>>>
>>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>>
>>>>> Hi Colm,
>>>>>
>>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>>> would be great. The [2] could go in today but no user response on [3],
>>>>> may need a bump to next version. Thank you.
>>>>>
>>>>> [1] https://github.com/apache/cxf/pull/1033
>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>>
>>>>> Best Regards,
>>>>> Andriy Redko
>>>>>
>>>>> COh> Hi Andriy,
>>>>>
>>>>> COh> What's the status of these open issues? Can they be merged today or
>>>>> COh> else bumped to the next release?
>>>>>
>>>>> COh> Colm.
>>>>>
>>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>>> wrote:
>>>>>>>
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>>> fixes work.
>>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>>> the
>>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>>
>>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Andriy Redko
>>>>>>>
>>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>>
>>>>>>>> Colm.
>>>>>>>
>>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>>> <co...@apache.org> wrote:
>>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>>> two
>>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>>> go.
>>>>>>>>> Colm.
>>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>>> wrote:
>>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>>> wrote:
>>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Andriy Redko
>>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>>> wrote:
>>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>>> @Colm @Dan
>>>>>>>
>>>>>>>>>>>> do
>>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>>> well? With
>>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>>> the 3.4.x
>>>>>>>>>>>> is
>>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>>> before the
>>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>>> have a
>>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>>> for
>>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>>> Dan
>>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>>> left we
>>>>>>>>>>>> need
>>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>>
>>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>>> release
>>>>>>>>>>> when
>>>>>>>>>>>>>> it's convenient for you?
>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>>> jb@nanthrax.net
>>>>>>>>>>>>>> wrote:
>>>>>>>
>>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>>
>>>>> wrote:
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>>> issues
>>>>>>>>>>> for
>>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>>> and
>>>>> we can
>>>>>>>>>>>> say
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>>> Jakarta
>>>>>>>
>>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>>> community
>>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>>> like
>>>>> [1]
>>>>>>>>>>> and
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>>> release
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>>> jakarta
>>>>>>>
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>> [1]
>>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>> --
>>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Thanks for the update, Dan. Are these basic tests failed because Spring6
is built with java17 and it isn't compatible with
java11 anymore ?
On Mon, Dec 12, 2022 at 11:01 AM Daniel Kulp <dk...@apache.org> wrote:
>
> On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
> >
> > Hi Andriy,
> > Thanks for the quick update. Good to see this is running with the jenkins
> > pipeline and all tests are green.
> > Did it include all things for the CXF 4.0.0 release ?
>
> I didn’t do the 4.0.0 release as I kind of ran out of time. My basic
> tests don’t work with java11, but I didn’t really get time to figure out
> why yet. I’m trying to figure out if it’s still actually compatible with
> java11 or not. If not, we should bump the jdk.version up.
>
>
> Dan
>
>
> >
> > Thanks,
> > Jim
> >
> >
> >
> >
> >
> > On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
> >
> >> Hi Jim,
> >>
> >> I disabled this build (and
> >> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
> >> because we run pipeline matrix [1] against both JDKs. These builds were
> >> quite useful when
> >> the main branch was unstable, but the pipeline should be sufficient
> now.
> >> Please let me
> >> know if you have any concerns, thank you.
> >>
> >> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> JM> Did we already start the 4.0 release work ?
> >> JM> I saw the CI build for CXF 4.0.0 is disabled now :
> >> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
> >> result
> >> JM> was 7 days ago.
> >>
> >>
> >>
> >>
> >> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com>
> wrote:
> >>
> >>>> Hi Colm,
> >>>>
> >>>> I still wait for review on [1], if you or/and Dan could take a look,
> >>>> would be great. The [2] could go in today but no user response on [3],
> >>>> may need a bump to next version. Thank you.
> >>>>
> >>>> [1] https://github.com/apache/cxf/pull/1033
> >>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>> [3] https://issues.apache.org/jira/browse/CXF-8798
> >>>>
> >>>> Best Regards,
> >>>> Andriy Redko
> >>>>
> >>>> COh> Hi Andriy,
> >>>>
> >>>> COh> What's the status of these open issues? Can they be merged today
> or
> >>>> COh> else bumped to the next release?
> >>>>
> >>>> COh> Colm.
> >>>>
> >>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>> Hey guys,
> >>>>>>
> >>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
> >>>>>> pull requests are opened, waiting for minor changes / confirmations
> >>>> fixes work.
> >>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
> >> the
> >>>>>> leak of the REMOVED_MARKER. Thanks!
> >>>>>>
> >>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
> >>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
> >>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
> >>>>>> [4] https://github.com/apache/cxf/pull/1033
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Andriy Redko
> >>>>>>
> >>>>>>> I'm done now in terms of any remaining fixes for the next
> >>>>>>> releases...not sure if @Andriy Redko has anything else planned?
> >>>>>>
> >>>>>>> Colm.
> >>>>>>
> >>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> >>>>>>> <co...@apache.org> wrote:
> >>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
> >> two
> >>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
> >> go.
> >>>>>>>> Colm.
> >>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
> >>>> wrote:
> >>>>>>>>> Thanks Andriy and Dan !
> >>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
> >>>> wrote:
> >>>>>>>>>> Works for me, thanks a lot Dan!
> >>>>>>
> >>>>>>>>>> Best Regards,
> >>>>>>>>>> Andriy Redko
> >>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
> >>>> wrote:
> >>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
> >>>> @Colm @Dan
> >>>>>>
> >>>>>>>>>>> do
> >>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
> >>>> well? With
> >>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
> >>>> the 3.4.x
> >>>>>>>>>>> is
> >>>>>>>>>>>> approaching EOL quickly, could be the last release.
> >>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
> >>>> before the
> >>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
> >>>> have a
> >>>>>>>>>>> bunch of things happening this week, but would next Monday work
> >>>> for
> >>>>>>>>>>> everyone? That would give a week to get any final updates in.
> >>>>>>>>>>> Dan
> >>>>>>>>>>>> Thank you guys!
> >>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>> Andriy Redko
> >>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>> Hi Andriy,
> >>>>>>>>>>>>> Can we start the release work if there isn't the major thing
> >>>> left we
> >>>>>>>>>>> need
> >>>>>>>>>>>>> to include in CXF 4.0.0 release ?
> >>>>>>
> >>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
> >>>> release
> >>>>>>>>>> when
> >>>>>>>>>>>>> it's convenient for you?
> >>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> Jim
> >>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
> >>>> jb@nanthrax.net
> >>>>>>>>>>>>> wrote:
> >>>>>>
> >>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
> >>>>>>
> >>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>> JB
> >>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
> >>>
> >>>> wrote:
> >>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
> >>>> issues
> >>>>>>>>>> for
> >>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
> >> and
> >>>> we can
> >>>>>>>>>>> say
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
> >>>> Jakarta
> >>>>>>
> >>>>>>>>>>>>>> EE9.1).
> >>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
> >>>> community
> >>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
> >> like
> >>>> [1]
> >>>>>>>>>> and
> >>>>>>>>>>>>>> get
> >>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
> >>>> release
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> CXF
> >>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
> >>>> jakarta
> >>>>>>
> >>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>> [1]
> >>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>> Jim
> >>>>>>>>>>> --
> >>>>>>>>>>> Daniel Kulp
> >>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
> >>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org>
> Talend - https://talend.com <https://talend.com/>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 11, 2022, at 9:36 PM, Jim Ma <ma...@gmail.com> wrote:
>
> Hi Andriy,
> Thanks for the quick update. Good to see this is running with the jenkins
> pipeline and all tests are green.
> Did it include all things for the CXF 4.0.0 release ?
I didn’t do the 4.0.0 release as I kind of ran out of time. My basic tests don’t work with java11, but I didn’t really get time to figure out why yet. I’m trying to figure out if it’s still actually compatible with java11 or not. If not, we should bump the jdk.version up.
Dan
>
> Thanks,
> Jim
>
>
>
>
>
> On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
>
>> Hi Jim,
>>
>> I disabled this build (and
>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
>> because we run pipeline matrix [1] against both JDKs. These builds were
>> quite useful when
>> the main branch was unstable, but the pipeline should be sufficient now.
>> Please let me
>> know if you have any concerns, thank you.
>>
>> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>>
>> Best Regards,
>> Andriy Redko
>>
>> JM> Did we already start the 4.0 release work ?
>> JM> I saw the CI build for CXF 4.0.0 is disabled now :
>> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
>> result
>> JM> was 7 days ago.
>>
>>
>>
>>
>> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>>
>>>> Hi Colm,
>>>>
>>>> I still wait for review on [1], if you or/and Dan could take a look,
>>>> would be great. The [2] could go in today but no user response on [3],
>>>> may need a bump to next version. Thank you.
>>>>
>>>> [1] https://github.com/apache/cxf/pull/1033
>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>>>
>>>> Best Regards,
>>>> Andriy Redko
>>>>
>>>> COh> Hi Andriy,
>>>>
>>>> COh> What's the status of these open issues? Can they be merged today or
>>>> COh> else bumped to the next release?
>>>>
>>>> COh> Colm.
>>>>
>>>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
>> wrote:
>>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>>>>>> pull requests are opened, waiting for minor changes / confirmations
>>>> fixes work.
>>>>>> @Dan @Colm appreciate your input on [4] please, this is to eliminate
>> the
>>>>>> leak of the REMOVED_MARKER. Thanks!
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/CXF-8798
>>>>>> [2] https://issues.apache.org/jira/browse/CXF-8799
>>>>>> [3] https://issues.apache.org/jira/browse/CXF-8796
>>>>>> [4] https://github.com/apache/cxf/pull/1033
>>>>>>
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>>
>>>>>>> I'm done now in terms of any remaining fixes for the next
>>>>>>> releases...not sure if @Andriy Redko has anything else planned?
>>>>>>
>>>>>>> Colm.
>>>>>>
>>>>>>> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>>>>>>> <co...@apache.org> wrote:
>>>>>>>> It works for me as well. I'm coordinating with @Andriy Redko on
>> two
>>>>>>>> fixes that remain for 3.5.x/3.4.x and then we should be good to
>> go.
>>>>>>>> Colm.
>>>>>>>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>>>> wrote:
>>>>>>>>> Thanks Andriy and Dan !
>>>>>>>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>>>> wrote:
>>>>>>>>>> Works for me, thanks a lot Dan!
>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Andriy Redko
>>>>>>>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>>>> wrote:
>>>>>>>>>>>> I don't think anything blocking is left, +1 to move forward!
>>>> @Colm @Dan
>>>>>>
>>>>>>>>>>> do
>>>>>>>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>>>> well? With
>>>>>>>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>>>> the 3.4.x
>>>>>>>>>>> is
>>>>>>>>>>>> approaching EOL quickly, could be the last release.
>>>>>>>>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>>>> before the
>>>>>>>>>>> end of the year. Thus, we could do a full set of releases. I
>>>> have a
>>>>>>>>>>> bunch of things happening this week, but would next Monday work
>>>> for
>>>>>>>>>>> everyone? That would give a week to get any final updates in.
>>>>>>>>>>> Dan
>>>>>>>>>>>> Thank you guys!
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Andriy Redko
>>>>>>>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>>>> wrote:
>>>>>>>>>>>>> Hi Andriy,
>>>>>>>>>>>>> Can we start the release work if there isn't the major thing
>>>> left we
>>>>>>>>>>> need
>>>>>>>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>
>>>>>>>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>>>> release
>>>>>>>>>> when
>>>>>>>>>>>>> it's convenient for you?
>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Jim
>>>>>>>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>>>> jb@nanthrax.net
>>>>>>>>>>>>> wrote:
>>>>>>
>>>>>>>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> JB
>>>>>>>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
>>>
>>>> wrote:
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>> After 9 months of work, we finally fixed/worked around all
>>>> issues
>>>>>>>>>> for
>>>>>>>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
>> and
>>>> we can
>>>>>>>>>>> say
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>>>> Jakarta
>>>>>>
>>>>>>>>>>>>>> EE9.1).
>>>>>>>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>>> community
>>>>>>>>>>>>>>> especially the user who asked for this jakarta artifacts
>> like
>>>> [1]
>>>>>>>>>> and
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> more feedback from our community, do you think it's time to
>>>> release
>>>>>>>>>>> the
>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>> 4.0.0 and what else do you think we should have in this new
>>>> jakarta
>>>>>>
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>> [1]
>>>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Jim
>>>>>>>>>>> --
>>>>>>>>>>> Daniel Kulp
>>>>>>>>>>> dkulp@apache.org <ma...@apache.org>
>>>>>>>>>>> Talend - https://talend.com <https://talend.com/>
>>>>>>
>>>>
>>>>
>>
>>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Hi Andriy,
Thanks for the quick update. Good to see this is running with the jenkins
pipeline and all tests are green.
Did it include all things for the CXF 4.0.0 release ?
Thanks,
Jim
On Mon, Dec 12, 2022 at 10:06 AM Andriy Redko <dr...@gmail.com> wrote:
> Hi Jim,
>
> I disabled this build (and
> https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
> because we run pipeline matrix [1] against both JDKs. These builds were
> quite useful when
> the main branch was unstable, but the pipeline should be sufficient now.
> Please let me
> know if you have any concerns, thank you.
>
> [1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
>
> Best Regards,
> Andriy Redko
>
> JM> Did we already start the 4.0 release work ?
> JM> I saw the CI build for CXF 4.0.0 is disabled now :
> JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build
> result
> JM> was 7 days ago.
>
>
>
>
> JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>
> >> Hi Colm,
> >>
> >> I still wait for review on [1], if you or/and Dan could take a look,
> >> would be great. The [2] could go in today but no user response on [3],
> >> may need a bump to next version. Thank you.
> >>
> >> [1] https://github.com/apache/cxf/pull/1033
> >> [2] https://issues.apache.org/jira/browse/CXF-8799
> >> [3] https://issues.apache.org/jira/browse/CXF-8798
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> COh> Hi Andriy,
> >>
> >> COh> What's the status of these open issues? Can they be merged today or
> >> COh> else bumped to the next release?
> >>
> >> COh> Colm.
> >>
> >> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com>
> wrote:
> >> >>
> >> >> Hey guys,
> >> >>
> >> >> I have only these 3 issues to wrap up [1], [2], [3], for all of them
> >> >> pull requests are opened, waiting for minor changes / confirmations
> >> fixes work.
> >> >> @Dan @Colm appreciate your input on [4] please, this is to eliminate
> the
> >> >> leak of the REMOVED_MARKER. Thanks!
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/CXF-8798
> >> >> [2] https://issues.apache.org/jira/browse/CXF-8799
> >> >> [3] https://issues.apache.org/jira/browse/CXF-8796
> >> >> [4] https://github.com/apache/cxf/pull/1033
> >> >>
> >> >> Best Regards,
> >> >> Andriy Redko
> >> >>
> >> >> > I'm done now in terms of any remaining fixes for the next
> >> >> > releases...not sure if @Andriy Redko has anything else planned?
> >> >>
> >> >> > Colm.
> >> >>
> >> >> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> >> >> > <co...@apache.org> wrote:
> >> >> >> It works for me as well. I'm coordinating with @Andriy Redko on
> two
> >> >> >> fixes that remain for 3.5.x/3.4.x and then we should be good to
> go.
> >> >> >> Colm.
> >> >> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
> >> wrote:
> >> >> >>> Thanks Andriy and Dan !
> >> >> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
> >> wrote:
> >> >> >>>> Works for me, thanks a lot Dan!
> >> >>
> >> >> >>>> Best Regards,
> >> >> >>>> Andriy Redko
> >> >> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
> >> wrote:
> >> >> >>>>>> I don't think anything blocking is left, +1 to move forward!
> >> @Colm @Dan
> >> >>
> >> >> >>>>> do
> >> >> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
> >> well? With
> >> >> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
> >> the 3.4.x
> >> >> >>>>> is
> >> >> >>>>>> approaching EOL quickly, could be the last release.
> >> >> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime
> >> before the
> >> >> >>>>> end of the year. Thus, we could do a full set of releases. I
> >> have a
> >> >> >>>>> bunch of things happening this week, but would next Monday work
> >> for
> >> >> >>>>> everyone? That would give a week to get any final updates in.
> >> >> >>>>> Dan
> >> >> >>>>>> Thank you guys!
> >> >> >>>>>> Best Regards,
> >> >> >>>>>> Andriy Redko
> >> >> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
> >> wrote:
> >> >> >>>>>>> Hi Andriy,
> >> >> >>>>>>> Can we start the release work if there isn't the major thing
> >> left we
> >> >> >>>>> need
> >> >> >>>>>>> to include in CXF 4.0.0 release ?
> >> >>
> >> >> >>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
> >> release
> >> >> >>>> when
> >> >> >>>>>>> it's convenient for you?
> >> >>
> >> >> >>>>>>> Thanks,
> >> >> >>>>>>> Jim
> >> >> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
> >> jb@nanthrax.net
> >> >> >>>>>>> wrote:
> >> >>
> >> >> >>>>>>>> +1 to release 4.0.0 even partial release.
> >> >>
> >> >> >>>>>>>> Regards
> >> >> >>>>>>>> JB
> >> >> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <mail2jimma@gmail.com
> >
> >> wrote:
> >> >> >>>>>>>>> Hi all,
> >> >> >>>>>>>>> After 9 months of work, we finally fixed/worked around all
> >> issues
> >> >> >>>> for
> >> >> >>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >> >> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/
> and
> >> we can
> >> >> >>>>> say
> >> >> >>>>>>>> that
> >> >> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
> >> Jakarta
> >> >>
> >> >> >>>>>>>> EE9.1).
> >> >> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
> >> community
> >> >> >>>>>>>>> especially the user who asked for this jakarta artifacts
> like
> >> [1]
> >> >> >>>> and
> >> >> >>>>>>>> get
> >> >> >>>>>>>>> more feedback from our community, do you think it's time to
> >> release
> >> >> >>>>> the
> >> >> >>>>>>>> CXF
> >> >> >>>>>>>>> 4.0.0 and what else do you think we should have in this new
> >> jakarta
> >> >>
> >> >> >>>>>>>> release
> >> >> >>>>>>>>> ?
> >> >> >>>>>>>>> [1]
> >> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >> >> >>>>>>>>> Thanks,
> >> >> >>>>>>>>> Jim
> >> >> >>>>> --
> >> >> >>>>> Daniel Kulp
> >> >> >>>>> dkulp@apache.org <ma...@apache.org>
> >> >> >>>>> Talend - https://talend.com <https://talend.com/>
> >> >>
> >>
> >>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Jim,
I disabled this build (and https://ci-builds.apache.org/job/CXF/job/CXF-JDK19/ as well)
because we run pipeline matrix [1] against both JDKs. These builds were quite useful when
the main branch was unstable, but the pipeline should be sufficient now. Please let me
know if you have any concerns, thank you.
[1] https://ci-builds.apache.org/job/CXF/job/pipeline/job/main/
Best Regards,
Andriy Redko
JM> Did we already start the 4.0 release work ?
JM> I saw the CI build for CXF 4.0.0 is disabled now :
JM> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build result
JM> was 7 days ago.
JM> On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
>> Hi Colm,
>>
>> I still wait for review on [1], if you or/and Dan could take a look,
>> would be great. The [2] could go in today but no user response on [3],
>> may need a bump to next version. Thank you.
>>
>> [1] https://github.com/apache/cxf/pull/1033
>> [2] https://issues.apache.org/jira/browse/CXF-8799
>> [3] https://issues.apache.org/jira/browse/CXF-8798
>>
>> Best Regards,
>> Andriy Redko
>>
>> COh> Hi Andriy,
>>
>> COh> What's the status of these open issues? Can they be merged today or
>> COh> else bumped to the next release?
>>
>> COh> Colm.
>>
>> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com> wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>> >> pull requests are opened, waiting for minor changes / confirmations
>> fixes work.
>> >> @Dan @Colm appreciate your input on [4] please, this is to eliminate the
>> >> leak of the REMOVED_MARKER. Thanks!
>> >>
>> >> [1] https://issues.apache.org/jira/browse/CXF-8798
>> >> [2] https://issues.apache.org/jira/browse/CXF-8799
>> >> [3] https://issues.apache.org/jira/browse/CXF-8796
>> >> [4] https://github.com/apache/cxf/pull/1033
>> >>
>> >> Best Regards,
>> >> Andriy Redko
>> >>
>> >> > I'm done now in terms of any remaining fixes for the next
>> >> > releases...not sure if @Andriy Redko has anything else planned?
>> >>
>> >> > Colm.
>> >>
>> >> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>> >> > <co...@apache.org> wrote:
>> >> >> It works for me as well. I'm coordinating with @Andriy Redko on two
>> >> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
>> >> >> Colm.
>> >> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
>> wrote:
>> >> >>> Thanks Andriy and Dan !
>> >> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
>> wrote:
>> >> >>>> Works for me, thanks a lot Dan!
>> >>
>> >> >>>> Best Regards,
>> >> >>>> Andriy Redko
>> >> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
>> wrote:
>> >> >>>>>> I don't think anything blocking is left, +1 to move forward!
>> @Colm @Dan
>> >>
>> >> >>>>> do
>> >> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
>> well? With
>> >> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
>> the 3.4.x
>> >> >>>>> is
>> >> >>>>>> approaching EOL quickly, could be the last release.
>> >> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime
>> before the
>> >> >>>>> end of the year. Thus, we could do a full set of releases. I
>> have a
>> >> >>>>> bunch of things happening this week, but would next Monday work
>> for
>> >> >>>>> everyone? That would give a week to get any final updates in.
>> >> >>>>> Dan
>> >> >>>>>> Thank you guys!
>> >> >>>>>> Best Regards,
>> >> >>>>>> Andriy Redko
>> >> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
>> wrote:
>> >> >>>>>>> Hi Andriy,
>> >> >>>>>>> Can we start the release work if there isn't the major thing
>> left we
>> >> >>>>> need
>> >> >>>>>>> to include in CXF 4.0.0 release ?
>> >>
>> >> >>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
>> release
>> >> >>>> when
>> >> >>>>>>> it's convenient for you?
>> >>
>> >> >>>>>>> Thanks,
>> >> >>>>>>> Jim
>> >> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
>> jb@nanthrax.net
>> >> >>>>>>> wrote:
>> >>
>> >> >>>>>>>> +1 to release 4.0.0 even partial release.
>> >>
>> >> >>>>>>>> Regards
>> >> >>>>>>>> JB
>> >> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com>
>> wrote:
>> >> >>>>>>>>> Hi all,
>> >> >>>>>>>>> After 9 months of work, we finally fixed/worked around all
>> issues
>> >> >>>> for
>> >> >>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>> >> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
>> we can
>> >> >>>>> say
>> >> >>>>>>>> that
>> >> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
>> Jakarta
>> >>
>> >> >>>>>>>> EE9.1).
>> >> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
>> community
>> >> >>>>>>>>> especially the user who asked for this jakarta artifacts like
>> [1]
>> >> >>>> and
>> >> >>>>>>>> get
>> >> >>>>>>>>> more feedback from our community, do you think it's time to
>> release
>> >> >>>>> the
>> >> >>>>>>>> CXF
>> >> >>>>>>>>> 4.0.0 and what else do you think we should have in this new
>> jakarta
>> >>
>> >> >>>>>>>> release
>> >> >>>>>>>>> ?
>> >> >>>>>>>>> [1]
>> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> >> >>>>>>>>> Thanks,
>> >> >>>>>>>>> Jim
>> >> >>>>> --
>> >> >>>>> Daniel Kulp
>> >> >>>>> dkulp@apache.org <ma...@apache.org>
>> >> >>>>> Talend - https://talend.com <https://talend.com/>
>> >>
>>
>>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Did we already start the 4.0 release work ?
I saw the CI build for CXF 4.0.0 is disabled now :
https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/ and last build result
was 7 days ago.
On Wed, Dec 7, 2022 at 8:46 PM Andriy Redko <dr...@gmail.com> wrote:
> Hi Colm,
>
> I still wait for review on [1], if you or/and Dan could take a look,
> would be great. The [2] could go in today but no user response on [3],
> may need a bump to next version. Thank you.
>
> [1] https://github.com/apache/cxf/pull/1033
> [2] https://issues.apache.org/jira/browse/CXF-8799
> [3] https://issues.apache.org/jira/browse/CXF-8798
>
> Best Regards,
> Andriy Redko
>
> COh> Hi Andriy,
>
> COh> What's the status of these open issues? Can they be merged today or
> COh> else bumped to the next release?
>
> COh> Colm.
>
> COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com> wrote:
> >>
> >> Hey guys,
> >>
> >> I have only these 3 issues to wrap up [1], [2], [3], for all of them
> >> pull requests are opened, waiting for minor changes / confirmations
> fixes work.
> >> @Dan @Colm appreciate your input on [4] please, this is to eliminate the
> >> leak of the REMOVED_MARKER. Thanks!
> >>
> >> [1] https://issues.apache.org/jira/browse/CXF-8798
> >> [2] https://issues.apache.org/jira/browse/CXF-8799
> >> [3] https://issues.apache.org/jira/browse/CXF-8796
> >> [4] https://github.com/apache/cxf/pull/1033
> >>
> >> Best Regards,
> >> Andriy Redko
> >>
> >> > I'm done now in terms of any remaining fixes for the next
> >> > releases...not sure if @Andriy Redko has anything else planned?
> >>
> >> > Colm.
> >>
> >> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> >> > <co...@apache.org> wrote:
> >> >> It works for me as well. I'm coordinating with @Andriy Redko on two
> >> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
> >> >> Colm.
> >> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com>
> wrote:
> >> >>> Thanks Andriy and Dan !
> >> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com>
> wrote:
> >> >>>> Works for me, thanks a lot Dan!
> >>
> >> >>>> Best Regards,
> >> >>>> Andriy Redko
> >> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>>>>> I don't think anything blocking is left, +1 to move forward!
> @Colm @Dan
> >>
> >> >>>>> do
> >> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as
> well? With
> >> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully),
> the 3.4.x
> >> >>>>> is
> >> >>>>>> approaching EOL quickly, could be the last release.
> >> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime
> before the
> >> >>>>> end of the year. Thus, we could do a full set of releases. I
> have a
> >> >>>>> bunch of things happening this week, but would next Monday work
> for
> >> >>>>> everyone? That would give a week to get any final updates in.
> >> >>>>> Dan
> >> >>>>>> Thank you guys!
> >> >>>>>> Best Regards,
> >> >>>>>> Andriy Redko
> >> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com>
> wrote:
> >> >>>>>>> Hi Andriy,
> >> >>>>>>> Can we start the release work if there isn't the major thing
> left we
> >> >>>>> need
> >> >>>>>>> to include in CXF 4.0.0 release ?
> >>
> >> >>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the
> release
> >> >>>> when
> >> >>>>>>> it's convenient for you?
> >>
> >> >>>>>>> Thanks,
> >> >>>>>>> Jim
> >> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <
> jb@nanthrax.net
> >> >>>>>>> wrote:
> >>
> >> >>>>>>>> +1 to release 4.0.0 even partial release.
> >>
> >> >>>>>>>> Regards
> >> >>>>>>>> JB
> >> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com>
> wrote:
> >> >>>>>>>>> Hi all,
> >> >>>>>>>>> After 9 months of work, we finally fixed/worked around all
> issues
> >> >>>> for
> >> >>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> we can
> >> >>>>> say
> >> >>>>>>>> that
> >> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support
> Jakarta
> >>
> >> >>>>>>>> EE9.1).
> >> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF
> community
> >> >>>>>>>>> especially the user who asked for this jakarta artifacts like
> [1]
> >> >>>> and
> >> >>>>>>>> get
> >> >>>>>>>>> more feedback from our community, do you think it's time to
> release
> >> >>>>> the
> >> >>>>>>>> CXF
> >> >>>>>>>>> 4.0.0 and what else do you think we should have in this new
> jakarta
> >>
> >> >>>>>>>> release
> >> >>>>>>>>> ?
> >> >>>>>>>>> [1]
> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >> >>>>>>>>> Thanks,
> >> >>>>>>>>> Jim
> >> >>>>> --
> >> >>>>> Daniel Kulp
> >> >>>>> dkulp@apache.org <ma...@apache.org>
> >> >>>>> Talend - https://talend.com <https://talend.com/>
> >>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Colm,
I still wait for review on [1], if you or/and Dan could take a look,
would be great. The [2] could go in today but no user response on [3],
may need a bump to next version. Thank you.
[1] https://github.com/apache/cxf/pull/1033
[2] https://issues.apache.org/jira/browse/CXF-8799
[3] https://issues.apache.org/jira/browse/CXF-8798
Best Regards,
Andriy Redko
COh> Hi Andriy,
COh> What's the status of these open issues? Can they be merged today or
COh> else bumped to the next release?
COh> Colm.
COh> On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com> wrote:
>>
>> Hey guys,
>>
>> I have only these 3 issues to wrap up [1], [2], [3], for all of them
>> pull requests are opened, waiting for minor changes / confirmations fixes work.
>> @Dan @Colm appreciate your input on [4] please, this is to eliminate the
>> leak of the REMOVED_MARKER. Thanks!
>>
>> [1] https://issues.apache.org/jira/browse/CXF-8798
>> [2] https://issues.apache.org/jira/browse/CXF-8799
>> [3] https://issues.apache.org/jira/browse/CXF-8796
>> [4] https://github.com/apache/cxf/pull/1033
>>
>> Best Regards,
>> Andriy Redko
>>
>> > I'm done now in terms of any remaining fixes for the next
>> > releases...not sure if @Andriy Redko has anything else planned?
>>
>> > Colm.
>>
>> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
>> > <co...@apache.org> wrote:
>> >> It works for me as well. I'm coordinating with @Andriy Redko on two
>> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
>> >> Colm.
>> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com> wrote:
>> >>> Thanks Andriy and Dan !
>> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
>> >>>> Works for me, thanks a lot Dan!
>>
>> >>>> Best Regards,
>> >>>> Andriy Redko
>> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
>> >>>>>> I don't think anything blocking is left, +1 to move forward! @Colm @Dan
>>
>> >>>>> do
>> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
>> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
>> >>>>> is
>> >>>>>> approaching EOL quickly, could be the last release.
>> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime before the
>> >>>>> end of the year. Thus, we could do a full set of releases. I have a
>> >>>>> bunch of things happening this week, but would next Monday work for
>> >>>>> everyone? That would give a week to get any final updates in.
>> >>>>> Dan
>> >>>>>> Thank you guys!
>> >>>>>> Best Regards,
>> >>>>>> Andriy Redko
>> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
>> >>>>>>> Hi Andriy,
>> >>>>>>> Can we start the release work if there isn't the major thing left we
>> >>>>> need
>> >>>>>>> to include in CXF 4.0.0 release ?
>>
>> >>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the release
>> >>>> when
>> >>>>>>> it's convenient for you?
>>
>> >>>>>>> Thanks,
>> >>>>>>> Jim
>> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
>> >>>>>>> wrote:
>>
>> >>>>>>>> +1 to release 4.0.0 even partial release.
>>
>> >>>>>>>> Regards
>> >>>>>>>> JB
>> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
>> >>>>>>>>> Hi all,
>> >>>>>>>>> After 9 months of work, we finally fixed/worked around all issues
>> >>>> for
>> >>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
>> >>>>> say
>> >>>>>>>> that
>> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>>
>> >>>>>>>> EE9.1).
>> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF community
>> >>>>>>>>> especially the user who asked for this jakarta artifacts like [1]
>> >>>> and
>> >>>>>>>> get
>> >>>>>>>>> more feedback from our community, do you think it's time to release
>> >>>>> the
>> >>>>>>>> CXF
>> >>>>>>>>> 4.0.0 and what else do you think we should have in this new jakarta
>>
>> >>>>>>>> release
>> >>>>>>>>> ?
>> >>>>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> >>>>>>>>> Thanks,
>> >>>>>>>>> Jim
>> >>>>> --
>> >>>>> Daniel Kulp
>> >>>>> dkulp@apache.org <ma...@apache.org>
>> >>>>> Talend - https://talend.com <https://talend.com/>
>>
Re: CXF 4.0.0 jakarta release
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Andriy,
What's the status of these open issues? Can they be merged today or
else bumped to the next release?
Colm.
On Fri, Dec 2, 2022 at 6:17 PM Andriy Redko <dr...@gmail.com> wrote:
>
> Hey guys,
>
> I have only these 3 issues to wrap up [1], [2], [3], for all of them
> pull requests are opened, waiting for minor changes / confirmations fixes work.
> @Dan @Colm appreciate your input on [4] please, this is to eliminate the
> leak of the REMOVED_MARKER. Thanks!
>
> [1] https://issues.apache.org/jira/browse/CXF-8798
> [2] https://issues.apache.org/jira/browse/CXF-8799
> [3] https://issues.apache.org/jira/browse/CXF-8796
> [4] https://github.com/apache/cxf/pull/1033
>
> Best Regards,
> Andriy Redko
>
> > I'm done now in terms of any remaining fixes for the next
> > releases...not sure if @Andriy Redko has anything else planned?
>
> > Colm.
>
> > On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> > <co...@apache.org> wrote:
> >> It works for me as well. I'm coordinating with @Andriy Redko on two
> >> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
> >> Colm.
> >> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com> wrote:
> >>> Thanks Andriy and Dan !
> >>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
> >>>> Works for me, thanks a lot Dan!
>
> >>>> Best Regards,
> >>>> Andriy Redko
> >>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
> >>>>>> I don't think anything blocking is left, +1 to move forward! @Colm @Dan
>
> >>>>> do
> >>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> >>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
> >>>>> is
> >>>>>> approaching EOL quickly, could be the last release.
> >>>>> I was definitely planning on doing 3.4/3.5 releases sometime before the
> >>>>> end of the year. Thus, we could do a full set of releases. I have a
> >>>>> bunch of things happening this week, but would next Monday work for
> >>>>> everyone? That would give a week to get any final updates in.
> >>>>> Dan
> >>>>>> Thank you guys!
> >>>>>> Best Regards,
> >>>>>> Andriy Redko
> >>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> >>>>>>> Hi Andriy,
> >>>>>>> Can we start the release work if there isn't the major thing left we
> >>>>> need
> >>>>>>> to include in CXF 4.0.0 release ?
>
> >>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the release
> >>>> when
> >>>>>>> it's convenient for you?
>
> >>>>>>> Thanks,
> >>>>>>> Jim
> >>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
> >>>>>>> wrote:
>
> >>>>>>>> +1 to release 4.0.0 even partial release.
>
> >>>>>>>> Regards
> >>>>>>>> JB
> >>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> >>>>>>>>> Hi all,
> >>>>>>>>> After 9 months of work, we finally fixed/worked around all issues
> >>>> for
> >>>>>>>>> Jakarta support. Now all the cxf tests are passed:
> >>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> >>>>> say
> >>>>>>>> that
> >>>>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>
> >>>>>>>> EE9.1).
> >>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF community
> >>>>>>>>> especially the user who asked for this jakarta artifacts like [1]
> >>>> and
> >>>>>>>> get
> >>>>>>>>> more feedback from our community, do you think it's time to release
> >>>>> the
> >>>>>>>> CXF
> >>>>>>>>> 4.0.0 and what else do you think we should have in this new jakarta
>
> >>>>>>>> release
> >>>>>>>>> ?
> >>>>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>>>>>> Thanks,
> >>>>>>>>> Jim
> >>>>> --
> >>>>> Daniel Kulp
> >>>>> dkulp@apache.org <ma...@apache.org>
> >>>>> Talend - https://talend.com <https://talend.com/>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hey guys,
I have only these 3 issues to wrap up [1], [2], [3], for all of them
pull requests are opened, waiting for minor changes / confirmations fixes work.
@Dan @Colm appreciate your input on [4] please, this is to eliminate the
leak of the REMOVED_MARKER. Thanks!
[1] https://issues.apache.org/jira/browse/CXF-8798
[2] https://issues.apache.org/jira/browse/CXF-8799
[3] https://issues.apache.org/jira/browse/CXF-8796
[4] https://github.com/apache/cxf/pull/1033
Best Regards,
Andriy Redko
> I'm done now in terms of any remaining fixes for the next
> releases...not sure if @Andriy Redko has anything else planned?
> Colm.
> On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
> <co...@apache.org> wrote:
>> It works for me as well. I'm coordinating with @Andriy Redko on two
>> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
>> Colm.
>> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com> wrote:
>>> Thanks Andriy and Dan !
>>> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
>>>> Works for me, thanks a lot Dan!
>>>> Best Regards,
>>>> Andriy Redko
>>>> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
>>>>>> I don't think anything blocking is left, +1 to move forward! @Colm @Dan
>>>>> do
>>>>>> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
>>>>>> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
>>>>> is
>>>>>> approaching EOL quickly, could be the last release.
>>>>> I was definitely planning on doing 3.4/3.5 releases sometime before the
>>>>> end of the year. Thus, we could do a full set of releases. I have a
>>>>> bunch of things happening this week, but would next Monday work for
>>>>> everyone? That would give a week to get any final updates in.
>>>>> Dan
>>>>>> Thank you guys!
>>>>>> Best Regards,
>>>>>> Andriy Redko
>>>>>> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
>>>>>>> Hi Andriy,
>>>>>>> Can we start the release work if there isn't the major thing left we
>>>>> need
>>>>>>> to include in CXF 4.0.0 release ?
>>>>>>> @Daniel Kulp <dk...@apache.org> Can you please help do the release
>>>> when
>>>>>>> it's convenient for you?
>>>>>>> Thanks,
>>>>>>> Jim
>>>>>>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
>>>>>>> wrote:
>>>>>>>> +1 to release 4.0.0 even partial release.
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
>>>>>>>>> Hi all,
>>>>>>>>> After 9 months of work, we finally fixed/worked around all issues
>>>> for
>>>>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
>>>>> say
>>>>>>>> that
>>>>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>>>>>>>> EE9.1).
>>>>>>>>> To get cxf jakarta artifacts/binary available for the CXF community
>>>>>>>>> especially the user who asked for this jakarta artifacts like [1]
>>>> and
>>>>>>>> get
>>>>>>>>> more feedback from our community, do you think it's time to release
>>>>> the
>>>>>>>> CXF
>>>>>>>>> 4.0.0 and what else do you think we should have in this new jakarta
>>>>>>>> release
>>>>>>>>> ?
>>>>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>>>>> Thanks,
>>>>>>>>> Jim
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org <ma...@apache.org>
>>>>> Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Colm O hEigeartaigh <co...@apache.org>.
I'm done now in terms of any remaining fixes for the next
releases...not sure if @Andriy Redko has anything else planned?
Colm.
On Wed, Nov 30, 2022 at 10:48 AM Colm O hEigeartaigh
<co...@apache.org> wrote:
>
> It works for me as well. I'm coordinating with @Andriy Redko on two
> fixes that remain for 3.5.x/3.4.x and then we should be good to go.
>
> Colm.
>
> On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com> wrote:
> >
> > Thanks Andriy and Dan !
> >
> > On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
> >
> > > Works for me, thanks a lot Dan!
> > >
> > > Best Regards,
> > > Andriy Redko
> > >
> > > On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
> > >
> > > >
> > > > >
> > > > > I don't think anything blocking is left, +1 to move forward! @Colm @Dan
> > > > do
> > > > > we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> > > > > 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
> > > > is
> > > > > approaching EOL quickly, could be the last release.
> > > >
> > > >
> > > > I was definitely planning on doing 3.4/3.5 releases sometime before the
> > > > end of the year. Thus, we could do a full set of releases. I have a
> > > > bunch of things happening this week, but would next Monday work for
> > > > everyone? That would give a week to get any final updates in.
> > > >
> > > > Dan
> > > >
> > > >
> > > > >
> > > > > Thank you guys!
> > > > >
> > > > >
> > > > > Best Regards,
> > > > > Andriy Redko
> > > > >
> > > > > On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> > > > >
> > > > >> Hi Andriy,
> > > > >> Can we start the release work if there isn't the major thing left we
> > > > need
> > > > >> to include in CXF 4.0.0 release ?
> > > > >>
> > > > >> @Daniel Kulp <dk...@apache.org> Can you please help do the release
> > > when
> > > > >> it's convenient for you?
> > > > >>
> > > > >> Thanks,
> > > > >> Jim
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
> > > >
> > > > >> wrote:
> > > > >>
> > > > >>> +1 to release 4.0.0 even partial release.
> > > > >>>
> > > > >>> Regards
> > > > >>> JB
> > > > >>>
> > > > >>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> > > > >>>>
> > > > >>>> Hi all,
> > > > >>>> After 9 months of work, we finally fixed/worked around all issues
> > > for
> > > > >>>> Jakarta support. Now all the cxf tests are passed:
> > > > >>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> > > > say
> > > > >>> that
> > > > >>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
> > > > >>> EE9.1).
> > > > >>>> To get cxf jakarta artifacts/binary available for the CXF community
> > > > >>>> especially the user who asked for this jakarta artifacts like [1]
> > > and
> > > > >>> get
> > > > >>>> more feedback from our community, do you think it's time to release
> > > > the
> > > > >>> CXF
> > > > >>>> 4.0.0 and what else do you think we should have in this new jakarta
> > > > >>> release
> > > > >>>> ?
> > > > >>>>
> > > > >>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>> Jim
> > > > >>>
> > > > >>
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org <ma...@apache.org>
> > > > Talend - https://talend.com <https://talend.com/>
> > > >
> > > >
> > >
Re: CXF 4.0.0 jakarta release
Posted by Colm O hEigeartaigh <co...@apache.org>.
It works for me as well. I'm coordinating with @Andriy Redko on two
fixes that remain for 3.5.x/3.4.x and then we should be good to go.
Colm.
On Wed, Nov 30, 2022 at 10:10 AM Jim Ma <ma...@gmail.com> wrote:
>
> Thanks Andriy and Dan !
>
> On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
>
> > Works for me, thanks a lot Dan!
> >
> > Best Regards,
> > Andriy Redko
> >
> > On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
> >
> > >
> > > >
> > > > I don't think anything blocking is left, +1 to move forward! @Colm @Dan
> > > do
> > > > we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> > > > 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
> > > is
> > > > approaching EOL quickly, could be the last release.
> > >
> > >
> > > I was definitely planning on doing 3.4/3.5 releases sometime before the
> > > end of the year. Thus, we could do a full set of releases. I have a
> > > bunch of things happening this week, but would next Monday work for
> > > everyone? That would give a week to get any final updates in.
> > >
> > > Dan
> > >
> > >
> > > >
> > > > Thank you guys!
> > > >
> > > >
> > > > Best Regards,
> > > > Andriy Redko
> > > >
> > > > On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> > > >
> > > >> Hi Andriy,
> > > >> Can we start the release work if there isn't the major thing left we
> > > need
> > > >> to include in CXF 4.0.0 release ?
> > > >>
> > > >> @Daniel Kulp <dk...@apache.org> Can you please help do the release
> > when
> > > >> it's convenient for you?
> > > >>
> > > >> Thanks,
> > > >> Jim
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
> > >
> > > >> wrote:
> > > >>
> > > >>> +1 to release 4.0.0 even partial release.
> > > >>>
> > > >>> Regards
> > > >>> JB
> > > >>>
> > > >>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> > > >>>>
> > > >>>> Hi all,
> > > >>>> After 9 months of work, we finally fixed/worked around all issues
> > for
> > > >>>> Jakarta support. Now all the cxf tests are passed:
> > > >>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> > > say
> > > >>> that
> > > >>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
> > > >>> EE9.1).
> > > >>>> To get cxf jakarta artifacts/binary available for the CXF community
> > > >>>> especially the user who asked for this jakarta artifacts like [1]
> > and
> > > >>> get
> > > >>>> more feedback from our community, do you think it's time to release
> > > the
> > > >>> CXF
> > > >>>> 4.0.0 and what else do you think we should have in this new jakarta
> > > >>> release
> > > >>>> ?
> > > >>>>
> > > >>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Jim
> > > >>>
> > > >>
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org <ma...@apache.org>
> > > Talend - https://talend.com <https://talend.com/>
> > >
> > >
> >
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Thanks Andriy and Dan !
On Mon, Nov 28, 2022 at 10:28 PM Andrey Redko <dr...@gmail.com> wrote:
> Works for me, thanks a lot Dan!
>
> Best Regards,
> Andriy Redko
>
> On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > >
> > > I don't think anything blocking is left, +1 to move forward! @Colm @Dan
> > do
> > > we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> > > 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
> > is
> > > approaching EOL quickly, could be the last release.
> >
> >
> > I was definitely planning on doing 3.4/3.5 releases sometime before the
> > end of the year. Thus, we could do a full set of releases. I have a
> > bunch of things happening this week, but would next Monday work for
> > everyone? That would give a week to get any final updates in.
> >
> > Dan
> >
> >
> > >
> > > Thank you guys!
> > >
> > >
> > > Best Regards,
> > > Andriy Redko
> > >
> > > On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> > >
> > >> Hi Andriy,
> > >> Can we start the release work if there isn't the major thing left we
> > need
> > >> to include in CXF 4.0.0 release ?
> > >>
> > >> @Daniel Kulp <dk...@apache.org> Can you please help do the release
> when
> > >> it's convenient for you?
> > >>
> > >> Thanks,
> > >> Jim
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb@nanthrax.net
> >
> > >> wrote:
> > >>
> > >>> +1 to release 4.0.0 even partial release.
> > >>>
> > >>> Regards
> > >>> JB
> > >>>
> > >>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> > >>>>
> > >>>> Hi all,
> > >>>> After 9 months of work, we finally fixed/worked around all issues
> for
> > >>>> Jakarta support. Now all the cxf tests are passed:
> > >>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> > say
> > >>> that
> > >>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
> > >>> EE9.1).
> > >>>> To get cxf jakarta artifacts/binary available for the CXF community
> > >>>> especially the user who asked for this jakarta artifacts like [1]
> and
> > >>> get
> > >>>> more feedback from our community, do you think it's time to release
> > the
> > >>> CXF
> > >>>> 4.0.0 and what else do you think we should have in this new jakarta
> > >>> release
> > >>>> ?
> > >>>>
> > >>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > >>>>
> > >>>> Thanks,
> > >>>> Jim
> > >>>
> > >>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org <ma...@apache.org>
> > Talend - https://talend.com <https://talend.com/>
> >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Andrey Redko <dr...@gmail.com>.
Works for me, thanks a lot Dan!
Best Regards,
Andriy Redko
On Mon, Nov 28, 2022, 8:45 AM Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > I don't think anything blocking is left, +1 to move forward! @Colm @Dan
> do
> > we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> > 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x
> is
> > approaching EOL quickly, could be the last release.
>
>
> I was definitely planning on doing 3.4/3.5 releases sometime before the
> end of the year. Thus, we could do a full set of releases. I have a
> bunch of things happening this week, but would next Monday work for
> everyone? That would give a week to get any final updates in.
>
> Dan
>
>
> >
> > Thank you guys!
> >
> >
> > Best Regards,
> > Andriy Redko
> >
> > On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> >
> >> Hi Andriy,
> >> Can we start the release work if there isn't the major thing left we
> need
> >> to include in CXF 4.0.0 release ?
> >>
> >> @Daniel Kulp <dk...@apache.org> Can you please help do the release when
> >> it's convenient for you?
> >>
> >> Thanks,
> >> Jim
> >>
> >>
> >>
> >>
> >> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >>
> >>> +1 to release 4.0.0 even partial release.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> >>>>
> >>>> Hi all,
> >>>> After 9 months of work, we finally fixed/worked around all issues for
> >>>> Jakarta support. Now all the cxf tests are passed:
> >>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> say
> >>> that
> >>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
> >>> EE9.1).
> >>>> To get cxf jakarta artifacts/binary available for the CXF community
> >>>> especially the user who asked for this jakarta artifacts like [1] and
> >>> get
> >>>> more feedback from our community, do you think it's time to release
> the
> >>> CXF
> >>>> 4.0.0 and what else do you think we should have in this new jakarta
> >>> release
> >>>> ?
> >>>>
> >>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>
> >>>> Thanks,
> >>>> Jim
> >>>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org <ma...@apache.org>
> Talend - https://talend.com <https://talend.com/>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Daniel Kulp <dk...@apache.org>.
>
> I don't think anything blocking is left, +1 to move forward! @Colm @Dan do
> we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
> 4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x is
> approaching EOL quickly, could be the last release.
I was definitely planning on doing 3.4/3.5 releases sometime before the end of the year. Thus, we could do a full set of releases. I have a bunch of things happening this week, but would next Monday work for everyone? That would give a week to get any final updates in.
Dan
>
> Thank you guys!
>
>
> Best Regards,
> Andriy Redko
>
> On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
>
>> Hi Andriy,
>> Can we start the release work if there isn't the major thing left we need
>> to include in CXF 4.0.0 release ?
>>
>> @Daniel Kulp <dk...@apache.org> Can you please help do the release when
>> it's convenient for you?
>>
>> Thanks,
>> Jim
>>
>>
>>
>>
>> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> +1 to release 4.0.0 even partial release.
>>>
>>> Regards
>>> JB
>>>
>>> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>> After 9 months of work, we finally fixed/worked around all issues for
>>>> Jakarta support. Now all the cxf tests are passed:
>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
>>> that
>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>>> EE9.1).
>>>> To get cxf jakarta artifacts/binary available for the CXF community
>>>> especially the user who asked for this jakarta artifacts like [1] and
>>> get
>>>> more feedback from our community, do you think it's time to release the
>>> CXF
>>>> 4.0.0 and what else do you think we should have in this new jakarta
>>> release
>>>> ?
>>>>
>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>
>>>> Thanks,
>>>> Jim
>>>
>>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org>
Talend - https://talend.com <https://talend.com/>
Re: CXF 4.0.0 jakarta release
Posted by Andrey Redko <dr...@gmail.com>.
Hi Jim,
I don't think anything blocking is left, +1 to move forward! @Colm @Dan do
we want to drop 4.0.0 only or make 3.4.x / 3.5.x releases as well? With
4.0.0 out and 3.6.0 getting ready to be out soon (hopefully), the 3.4.x is
approaching EOL quickly, could be the last release.
Thank you guys!
Best Regards,
Andriy Redko
On Sun, Nov 27, 2022, 10:27 PM Jim Ma <ma...@gmail.com> wrote:
> Hi Andriy,
> Can we start the release work if there isn't the major thing left we need
> to include in CXF 4.0.0 release ?
>
> @Daniel Kulp <dk...@apache.org> Can you please help do the release when
> it's convenient for you?
>
> Thanks,
> Jim
>
>
>
>
> On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > +1 to release 4.0.0 even partial release.
> >
> > Regards
> > JB
> >
> > On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> > >
> > > Hi all,
> > > After 9 months of work, we finally fixed/worked around all issues for
> > > Jakarta support. Now all the cxf tests are passed:
> > > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
> > that
> > > CXF successfully migrated to Jakarta namespace(and support Jakarta
> > EE9.1).
> > > To get cxf jakarta artifacts/binary available for the CXF community
> > > especially the user who asked for this jakarta artifacts like [1] and
> > get
> > > more feedback from our community, do you think it's time to release the
> > CXF
> > > 4.0.0 and what else do you think we should have in this new jakarta
> > release
> > > ?
> > >
> > > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > >
> > > Thanks,
> > > Jim
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Hi Andriy,
Can we start the release work if there isn't the major thing left we need
to include in CXF 4.0.0 release ?
@Daniel Kulp <dk...@apache.org> Can you please help do the release when
it's convenient for you?
Thanks,
Jim
On Mon, Nov 14, 2022 at 1:18 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> +1 to release 4.0.0 even partial release.
>
> Regards
> JB
>
> On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
> >
> > Hi all,
> > After 9 months of work, we finally fixed/worked around all issues for
> > Jakarta support. Now all the cxf tests are passed:
> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
> that
> > CXF successfully migrated to Jakarta namespace(and support Jakarta
> EE9.1).
> > To get cxf jakarta artifacts/binary available for the CXF community
> > especially the user who asked for this jakarta artifacts like [1] and
> get
> > more feedback from our community, do you think it's time to release the
> CXF
> > 4.0.0 and what else do you think we should have in this new jakarta
> release
> > ?
> >
> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >
> > Thanks,
> > Jim
>
Re: CXF 4.0.0 jakarta release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 to release 4.0.0 even partial release.
Regards
JB
On Mon, Nov 7, 2022 at 9:19 AM Jim Ma <ma...@gmail.com> wrote:
>
> Hi all,
> After 9 months of work, we finally fixed/worked around all issues for
> Jakarta support. Now all the cxf tests are passed:
> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say that
> CXF successfully migrated to Jakarta namespace(and support Jakarta EE9.1).
> To get cxf jakarta artifacts/binary available for the CXF community
> especially the user who asked for this jakarta artifacts like [1] and get
> more feedback from our community, do you think it's time to release the CXF
> 4.0.0 and what else do you think we should have in this new jakarta release
> ?
>
> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>
> Thanks,
> Jim
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Jim,
I am not aware of any but @Colm is the source of truth here :-)
Thanks!
Best Regards,
Andriy Redko
> We can probably include this upgrade in the CXF 4.1 or later version after it's released and get into WSS4j.
> AFAIK, there is no CXF or WSS4j issue blocked by the OpenSAML 5.0.0 upgrade.
> @Colm O hEigeartaigh @Andriy Redko WDYT ?
> On Mon, Nov 7, 2022 at 9:25 PM Misagh <mi...@gmail.com> wrote:
>> Hello all,
>> If possible, I'd like to ask that you allow v4 to ship with a new
>> release of wss4j that would contain this change:
>> https://github.com/apache/ws-wss4j/pull/62
>> At the moment, OpenSAML v5 is not released yet, but it is anticipated
>> to be GA before end of this year, hopefully.
>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
>>>
>>> Hi all,
>>> After 9 months of work, we finally fixed/worked around all issues for
>>> Jakarta support. Now all the cxf tests are passed:
>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say that
>>> CXF successfully migrated to Jakarta namespace(and support Jakarta EE9.1).
>>> To get cxf jakarta artifacts/binary available for the CXF community
>>> especially the user who asked for this jakarta artifacts like [1] and get
>>> more feedback from our community, do you think it's time to release the CXF
>>> 4.0.0 and what else do you think we should have in this new jakarta release
>>> ?
>>>
>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>
>>> Thanks,
>>> Jim
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
We can probably include this upgrade in the CXF 4.1 or later version after
it's released and get into WSS4j.
AFAIK, there is no CXF or WSS4j issue blocked by the OpenSAML 5.0.0 upgrade.
@Colm O hEigeartaigh <co...@apache.org> @Andriy Redko <dr...@gmail.com>
WDYT ?
On Mon, Nov 7, 2022 at 9:25 PM Misagh <mi...@gmail.com> wrote:
> Hello all,
>
> If possible, I'd like to ask that you allow v4 to ship with a new
> release of wss4j that would contain this change:
> https://github.com/apache/ws-wss4j/pull/62
>
> At the moment, OpenSAML v5 is not released yet, but it is anticipated
> to be GA before end of this year, hopefully.
>
> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
> >
> > Hi all,
> > After 9 months of work, we finally fixed/worked around all issues for
> > Jakarta support. Now all the cxf tests are passed:
> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
> that
> > CXF successfully migrated to Jakarta namespace(and support Jakarta
> EE9.1).
> > To get cxf jakarta artifacts/binary available for the CXF community
> > especially the user who asked for this jakarta artifacts like [1] and
> get
> > more feedback from our community, do you think it's time to release the
> CXF
> > 4.0.0 and what else do you think we should have in this new jakarta
> release
> > ?
> >
> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >
> > Thanks,
> > Jim
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Here we are [1], Dan has created 4.0.0 migration guide a while back, I filled it a bit.
Thanks!
[1] https://cwiki.apache.org/confluence/display/CXF20DOC/4.0+Migration+Guide
Best Regards,
Andriy Redko
AR> Yes, I will create the page shortly and share on the list.
AR> Best Regards,
AR> Andriy Redko
JM>> +1 to document this when we tag the release. There is a migration guide for
JM>> each release like: https://cxf.apache.org/docs/35-migration-guide.html.
JM>> Can we add this update in the 4.0 migration guide ?
JM>> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano <as...@apache.org> wrote:
>>> +1
>>>
>>> I would suggest to deal with this in documentation, restricting runtime jdk
>>> support to JDK17+ is actually going to create problems to some integration
>>> (Spring is effectively optional already), while not really giving us much
>>> (if you know you use Spring, just use JDK17, no need for it to be
>>> mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or
>>> 11; support for JDK 17 is something coming with JakartaEE 10 afair.
>>>
>>> Thanks
>>>
>>> On Tue, Nov 8, 2022 at 1:34 PM Jim Ma <ma...@gmail.com> wrote:
>>>
>>> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF
>>> > binary classes/artifacts are all JDK-11 version (class major version
>>> > 55) as Andriy
>>> > mentioned
>>> > we set target/source to JDK-11. I believe this setting on CXF at the
>>> > moment is the best option:
>>> >
>>> > - Users don't need to upgrade the JDK version if they are using CXF
>>> > without Spring. FWIK, there are a lot of non-Spring CXF users out
>>> > there.
>>> > - For the CXF Spring users, because the Spring 6 Jakarta version is
>>> > JDK-17 baseline and built classes are JDK-17 versions(class major
>>> > version
>>> > 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17
>>> is
>>> > mandatory from Spring 6 and not from CXF.
>>> >
>>> >
>>> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
>>> > wrote:
>>> >
>>> > > Hello,
>>> > >
>>> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
>>> > > optionally and we don't need to have spring artifacts on the classpath
>>> if
>>> > > we don't want to use spring/spring boot features, and this has been the
>>> > > case for a very long time.
>>> > >
>>> > > Freeman
>>> > >
>>> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>> > >
>>> > > wrote:
>>> > >
>>> > > > I was more referencing the long awaited split of cxf-core (it is
>>> still
>>> > > the
>>> > > > same old content than for the early jaxws time and without a modular
>>> > > design
>>> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
>>> > sounds
>>> > > > like a big awaited features (don't start by bringing 1.4M said
>>> > > otherwise).
>>> > > > Since several part of OSGi dropped I think it would be good to create
>>> > > > cxf-spring (and maybe spring-boot thanks some generator like camel).
>>> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds
>>> > fine
>>> > > > for me to drop spring if the refactor is too much and would delay a
>>> lot
>>> > > the
>>> > > > release - agree on this one.
>>> > > > But keeping it like that means it will stay for years so likely that
>>> > cxf
>>> > > 4
>>> > > > will be the same than cxf 3 on this point which would be sad IMHO.
>>> > > >
>>> > > > Side note: indeed the obvious answer to that point is "v5" but it is
>>> > > > pushing again this issue (coming from v2 ;)) and also makes the
>>> > > versioning
>>> > > > harder to follow if not pushed too far IMHO.
>>> > > >
>>> > > > Hope it makes sense.
>>> > > >
>>> > > > Romain Manni-Bucau
>>> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> > > > <https://rmannibucau.metawerx.net/> | Old Blog
>>> > > > <http://rmannibucau.wordpress.com> | Github <
>>> > > > https://github.com/rmannibucau> |
>>> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> > > > <
>>> > > >
>>> > >
>>> >
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> > > > >
>>> > > >
>>> > > >
>>> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a
>>> écrit :
>>> > > >
>>> > > > > Hi Romain,
>>> > > > >
>>> > > > > Thanks a lot for the feedback, just to clarify: we won't be
>>> dropping
>>> > > > > Spring
>>> > > > > (this is basically another "few months long" effort), it is merely
>>> to
>>> > > try
>>> > > > > to
>>> > > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
>>> > Boot
>>> > > at
>>> > > > > this moment) by default. It would definitely require more work for
>>> > the
>>> > > > > users
>>> > > > > to wire everything properly but at least that would allow us to
>>> > > preserve
>>> > > > > JDK-11
>>> > > > > baseline. Apologies if I am rephrasing what you intended to say,
>>> just
>>> > > an
>>> > > > > attempt to eliminate the possible confusion.
>>> > > > >
>>> > > > > Thank you.
>>> > > > >
>>> > > > >
>>> > > > > > Think Java 11 is a good baseline as of today - at least to enable
>>> > > > Jakarta
>>> > > > > > vendors to use CXF as an implementation and pass tck.
>>> > > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
>>> > we
>>> > > > can
>>> > > > > > catch up later like other dropped integrations and core should be
>>> > > > > exploded
>>> > > > > > anyway, it is way too fat for what it does so moving spring out
>>> of
>>> > it
>>> > > > is
>>> > > > > > quite a good direction IMHO.
>>> > > > >
>>> > > > > > Romain Manni-Bucau
>>> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
>>> > > > > > <http://rmannibucau.wordpress.com> | Github <
>>> > > > > https://github.com/rmannibucau> |
>>> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> > > > > > <
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <
>>> freeman.fang@gmail.com>
>>> > a
>>> > > > > écrit :
>>> > > > >
>>> > > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as
>>> baseline
>>> > > > > since we
>>> > > > > >> upgraded to Spring 6 and Spring Boot 3.
>>> > > > >
>>> > > > > >> Thanks to all guys involved in this long process!
>>> > > > > >> Freeman
>>> > > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
>>> > > > wrote:
>>> > > > > >>> +1 to move forward with release (or milestone), but before
>>> that,
>>> > > > there
>>> > > > > is
>>> > > > > >>> one issue which
>>> > > > > >>> I would like to bring up and agree us upon. The initial
>>> > discussion
>>> > > > for
>>> > > > > >>> Jakarta / 4.0.0 [1] concluded
>>> > > > > >>> on having JDK-11 as a baseline. At the same time, there is a
>>> > > > > misalignment
>>> > > > > >>> with Spring 6 / Spring Boot 3
>>> > > > > >>> requirements which bumped the baseline to JDK-17. Now, the way
>>> we
>>> > > > build
>>> > > > > >>> Jakarta / 4.0.0 branch (main) is
>>> > > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
>>> > > > >
>>> > > > > >>> With that being said, the not so good part. Technically,
>>> Jakarta
>>> > /
>>> > > > > 4.0.0
>>> > > > > >>> bits could be used in the
>>> > > > > >>> projects which are still using JDK-11. But because mostly every
>>> > > > single
>>> > > > > >>> piece (starting from cxf-core) depends
>>> > > > > >>> on Spring, the application fail to start with
>>> > > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
>>> > > > > >>> on any CXF provided sample). Effectively, the baseline is
>>> JDK-17,
>>> > > not
>>> > > > > >>> JDK-11 (we have hoped to isolate Spring
>>> > > > > >>> related implementation but it hasn't happened yet and not sure
>>> it
>>> > > > will
>>> > > > > in
>>> > > > > >>> the future). The question: does
>>> > > > > >>> anyone have a compelling usecase for keeping CXF baseline at
>>> > JDK-11
>>> > > > > level
>>> > > > > >>> despite being able to run only
>>> > > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
>>> > > > related
>>> > > > > >>> dependencies optional and document
>>> > > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
>>> > > used,
>>> > > > we
>>> > > > > >>> surely cannot leave things
>>> > > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17
>>> as a
>>> > > > > >>> baseline.
>>> > > > > >>> What do you guys think?
>>> > > > > >>> Thank you.
>>> > > > > >>> [1]
>>> > https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
>>> > > > > >>> Best Regards,
>>> > > > > >>> Andriy Redko
>>> > > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
>>> > > > > RMB>>>> +1 to release, there are too much forks out there already
>>> so
>>> > > > better
>>> > > > > >> to
>>> > > > > RMB>>>> release partially than not release at all IMHO
>>> > > > > RMB>>>> Romain Manni-Bucau
>>> > > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> > > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> > > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
>>> > > > > >>> https://github.com/rmannibucau> |
>>> > > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> > > > > RMB>>>> <
>>> > > > > >>
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> > > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
>>> > misagh.moayyed@gmail.com>
>>> > > a
>>> > > > > >>> écrit :
>>> > > > > >>>>> Hello all,
>>> > > > >
>>> > > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
>>> > new
>>> > > > > >>>>> release of wss4j that would contain this change:
>>> > > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
>>> > > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
>>> > > > anticipated
>>> > > > > >>>>> to be GA before end of this year, hopefully.
>>> > > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <mail2jimma@gmail.com
>>> >
>>> > > > wrote:
>>> > > > > >>>>>> Hi all,
>>> > > > > >>>>>> After 9 months of work, we finally fixed/worked around all
>>> > > issues
>>> > > > > >> for
>>> > > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
>>> > > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
>>> > we
>>> > > > can
>>> > > > > >>> say
>>> > > > > >>>>> that
>>> > > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
>>> > > Jakarta
>>> > > > >
>>> > > > > >>>>> EE9.1).
>>> > > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
>>> > > > community
>>> > > > > >>>>>> especially the user who asked for this jakarta artifacts
>>> like
>>> > > [1]
>>> > > > > >> and
>>> > > > > >>>>> get
>>> > > > > >>>>>> more feedback from our community, do you think it's time to
>>> > > > release
>>> > > > > >>> the
>>> > > > > >>>>> CXF
>>> > > > > >>>>>> 4.0.0 and what else do you think we should have in this new
>>> > > > jakarta
>>> > > > >
>>> > > > > >>>>> release
>>> > > > > >>>>>> ?
>>> > > > > >>>>>> [1]
>>> > > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>> > > > > >>>>>> Thanks,
>>> > > > > >>>>>> Jim
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>>
>>> --
>>>
>>> Alessio Soldano
>>>
>>> Manager, Software Engineering
>>>
>>> Red Hat <https://www.redhat.com>
>>> <https://www.redhat.com>
>>>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Yes, I will create the page shortly and share on the list.
Best Regards,
Andriy Redko
JM> +1 to document this when we tag the release. There is a migration guide for
JM> each release like: https://cxf.apache.org/docs/35-migration-guide.html.
JM> Can we add this update in the 4.0 migration guide ?
JM> On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano <as...@apache.org> wrote:
>> +1
>>
>> I would suggest to deal with this in documentation, restricting runtime jdk
>> support to JDK17+ is actually going to create problems to some integration
>> (Spring is effectively optional already), while not really giving us much
>> (if you know you use Spring, just use JDK17, no need for it to be
>> mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or
>> 11; support for JDK 17 is something coming with JakartaEE 10 afair.
>>
>> Thanks
>>
>> On Tue, Nov 8, 2022 at 1:34 PM Jim Ma <ma...@gmail.com> wrote:
>>
>> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF
>> > binary classes/artifacts are all JDK-11 version (class major version
>> > 55) as Andriy
>> > mentioned
>> > we set target/source to JDK-11. I believe this setting on CXF at the
>> > moment is the best option:
>> >
>> > - Users don't need to upgrade the JDK version if they are using CXF
>> > without Spring. FWIK, there are a lot of non-Spring CXF users out
>> > there.
>> > - For the CXF Spring users, because the Spring 6 Jakarta version is
>> > JDK-17 baseline and built classes are JDK-17 versions(class major
>> > version
>> > 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17
>> is
>> > mandatory from Spring 6 and not from CXF.
>> >
>> >
>> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
>> > > optionally and we don't need to have spring artifacts on the classpath
>> if
>> > > we don't want to use spring/spring boot features, and this has been the
>> > > case for a very long time.
>> > >
>> > > Freeman
>> > >
>> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > >
>> > > wrote:
>> > >
>> > > > I was more referencing the long awaited split of cxf-core (it is
>> still
>> > > the
>> > > > same old content than for the early jaxws time and without a modular
>> > > design
>> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
>> > sounds
>> > > > like a big awaited features (don't start by bringing 1.4M said
>> > > otherwise).
>> > > > Since several part of OSGi dropped I think it would be good to create
>> > > > cxf-spring (and maybe spring-boot thanks some generator like camel).
>> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds
>> > fine
>> > > > for me to drop spring if the refactor is too much and would delay a
>> lot
>> > > the
>> > > > release - agree on this one.
>> > > > But keeping it like that means it will stay for years so likely that
>> > cxf
>> > > 4
>> > > > will be the same than cxf 3 on this point which would be sad IMHO.
>> > > >
>> > > > Side note: indeed the obvious answer to that point is "v5" but it is
>> > > > pushing again this issue (coming from v2 ;)) and also makes the
>> > > versioning
>> > > > harder to follow if not pushed too far IMHO.
>> > > >
>> > > > Hope it makes sense.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > https://github.com/rmannibucau> |
>> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > <
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > >
>> > > >
>> > > >
>> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a
>> écrit :
>> > > >
>> > > > > Hi Romain,
>> > > > >
>> > > > > Thanks a lot for the feedback, just to clarify: we won't be
>> dropping
>> > > > > Spring
>> > > > > (this is basically another "few months long" effort), it is merely
>> to
>> > > try
>> > > > > to
>> > > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
>> > Boot
>> > > at
>> > > > > this moment) by default. It would definitely require more work for
>> > the
>> > > > > users
>> > > > > to wire everything properly but at least that would allow us to
>> > > preserve
>> > > > > JDK-11
>> > > > > baseline. Apologies if I am rephrasing what you intended to say,
>> just
>> > > an
>> > > > > attempt to eliminate the possible confusion.
>> > > > >
>> > > > > Thank you.
>> > > > >
>> > > > >
>> > > > > > Think Java 11 is a good baseline as of today - at least to enable
>> > > > Jakarta
>> > > > > > vendors to use CXF as an implementation and pass tck.
>> > > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
>> > we
>> > > > can
>> > > > > > catch up later like other dropped integrations and core should be
>> > > > > exploded
>> > > > > > anyway, it is way too fat for what it does so moving spring out
>> of
>> > it
>> > > > is
>> > > > > > quite a good direction IMHO.
>> > > > >
>> > > > > > Romain Manni-Bucau
>> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > > https://github.com/rmannibucau> |
>> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > > > <
>> > > > >
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > > >
>> > > > >
>> > > > >
>> > > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <
>> freeman.fang@gmail.com>
>> > a
>> > > > > écrit :
>> > > > >
>> > > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as
>> baseline
>> > > > > since we
>> > > > > >> upgraded to Spring 6 and Spring Boot 3.
>> > > > >
>> > > > > >> Thanks to all guys involved in this long process!
>> > > > > >> Freeman
>> > > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
>> > > > wrote:
>> > > > > >>> +1 to move forward with release (or milestone), but before
>> that,
>> > > > there
>> > > > > is
>> > > > > >>> one issue which
>> > > > > >>> I would like to bring up and agree us upon. The initial
>> > discussion
>> > > > for
>> > > > > >>> Jakarta / 4.0.0 [1] concluded
>> > > > > >>> on having JDK-11 as a baseline. At the same time, there is a
>> > > > > misalignment
>> > > > > >>> with Spring 6 / Spring Boot 3
>> > > > > >>> requirements which bumped the baseline to JDK-17. Now, the way
>> we
>> > > > build
>> > > > > >>> Jakarta / 4.0.0 branch (main) is
>> > > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
>> > > > >
>> > > > > >>> With that being said, the not so good part. Technically,
>> Jakarta
>> > /
>> > > > > 4.0.0
>> > > > > >>> bits could be used in the
>> > > > > >>> projects which are still using JDK-11. But because mostly every
>> > > > single
>> > > > > >>> piece (starting from cxf-core) depends
>> > > > > >>> on Spring, the application fail to start with
>> > > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
>> > > > > >>> on any CXF provided sample). Effectively, the baseline is
>> JDK-17,
>> > > not
>> > > > > >>> JDK-11 (we have hoped to isolate Spring
>> > > > > >>> related implementation but it hasn't happened yet and not sure
>> it
>> > > > will
>> > > > > in
>> > > > > >>> the future). The question: does
>> > > > > >>> anyone have a compelling usecase for keeping CXF baseline at
>> > JDK-11
>> > > > > level
>> > > > > >>> despite being able to run only
>> > > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
>> > > > related
>> > > > > >>> dependencies optional and document
>> > > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
>> > > used,
>> > > > we
>> > > > > >>> surely cannot leave things
>> > > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17
>> as a
>> > > > > >>> baseline.
>> > > > > >>> What do you guys think?
>> > > > > >>> Thank you.
>> > > > > >>> [1]
>> > https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
>> > > > > >>> Best Regards,
>> > > > > >>> Andriy Redko
>> > > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
>> > > > > RMB>>>> +1 to release, there are too much forks out there already
>> so
>> > > > better
>> > > > > >> to
>> > > > > RMB>>>> release partially than not release at all IMHO
>> > > > > RMB>>>> Romain Manni-Bucau
>> > > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
>> > > > > >>> https://github.com/rmannibucau> |
>> > > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > > RMB>>>> <
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
>> > misagh.moayyed@gmail.com>
>> > > a
>> > > > > >>> écrit :
>> > > > > >>>>> Hello all,
>> > > > >
>> > > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
>> > new
>> > > > > >>>>> release of wss4j that would contain this change:
>> > > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
>> > > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
>> > > > anticipated
>> > > > > >>>>> to be GA before end of this year, hopefully.
>> > > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <mail2jimma@gmail.com
>> >
>> > > > wrote:
>> > > > > >>>>>> Hi all,
>> > > > > >>>>>> After 9 months of work, we finally fixed/worked around all
>> > > issues
>> > > > > >> for
>> > > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
>> > > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
>> > we
>> > > > can
>> > > > > >>> say
>> > > > > >>>>> that
>> > > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
>> > > Jakarta
>> > > > >
>> > > > > >>>>> EE9.1).
>> > > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
>> > > > community
>> > > > > >>>>>> especially the user who asked for this jakarta artifacts
>> like
>> > > [1]
>> > > > > >> and
>> > > > > >>>>> get
>> > > > > >>>>>> more feedback from our community, do you think it's time to
>> > > > release
>> > > > > >>> the
>> > > > > >>>>> CXF
>> > > > > >>>>>> 4.0.0 and what else do you think we should have in this new
>> > > > jakarta
>> > > > >
>> > > > > >>>>> release
>> > > > > >>>>>> ?
>> > > > > >>>>>> [1]
>> > > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> > > > > >>>>>> Thanks,
>> > > > > >>>>>> Jim
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>>
>> --
>>
>> Alessio Soldano
>>
>> Manager, Software Engineering
>>
>> Red Hat <https://www.redhat.com>
>> <https://www.redhat.com>
>>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
+1 to document this when we tag the release. There is a migration guide for
each release like: https://cxf.apache.org/docs/35-migration-guide.html.
Can we add this update in the 4.0 migration guide ?
On Wed, Nov 9, 2022 at 12:28 AM Alessio Soldano <as...@apache.org> wrote:
> +1
>
> I would suggest to deal with this in documentation, restricting runtime jdk
> support to JDK17+ is actually going to create problems to some integration
> (Spring is effectively optional already), while not really giving us much
> (if you know you use Spring, just use JDK17, no need for it to be
> mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or
> 11; support for JDK 17 is something coming with JakartaEE 10 afair.
>
> Thanks
>
> On Tue, Nov 8, 2022 at 1:34 PM Jim Ma <ma...@gmail.com> wrote:
>
> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF
> > binary classes/artifacts are all JDK-11 version (class major version
> > 55) as Andriy
> > mentioned
> > we set target/source to JDK-11. I believe this setting on CXF at the
> > moment is the best option:
> >
> > - Users don't need to upgrade the JDK version if they are using CXF
> > without Spring. FWIK, there are a lot of non-Spring CXF users out
> > there.
> > - For the CXF Spring users, because the Spring 6 Jakarta version is
> > JDK-17 baseline and built classes are JDK-17 versions(class major
> > version
> > 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17
> is
> > mandatory from Spring 6 and not from CXF.
> >
> >
> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
> > > optionally and we don't need to have spring artifacts on the classpath
> if
> > > we don't want to use spring/spring boot features, and this has been the
> > > case for a very long time.
> > >
> > > Freeman
> > >
> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > wrote:
> > >
> > > > I was more referencing the long awaited split of cxf-core (it is
> still
> > > the
> > > > same old content than for the early jaxws time and without a modular
> > > design
> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
> > sounds
> > > > like a big awaited features (don't start by bringing 1.4M said
> > > otherwise).
> > > > Since several part of OSGi dropped I think it would be good to create
> > > > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds
> > fine
> > > > for me to drop spring if the refactor is too much and would delay a
> lot
> > > the
> > > > release - agree on this one.
> > > > But keeping it like that means it will stay for years so likely that
> > cxf
> > > 4
> > > > will be the same than cxf 3 on this point which would be sad IMHO.
> > > >
> > > > Side note: indeed the obvious answer to that point is "v5" but it is
> > > > pushing again this issue (coming from v2 ;)) and also makes the
> > > versioning
> > > > harder to follow if not pushed too far IMHO.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a
> écrit :
> > > >
> > > > > Hi Romain,
> > > > >
> > > > > Thanks a lot for the feedback, just to clarify: we won't be
> dropping
> > > > > Spring
> > > > > (this is basically another "few months long" effort), it is merely
> to
> > > try
> > > > > to
> > > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
> > Boot
> > > at
> > > > > this moment) by default. It would definitely require more work for
> > the
> > > > > users
> > > > > to wire everything properly but at least that would allow us to
> > > preserve
> > > > > JDK-11
> > > > > baseline. Apologies if I am rephrasing what you intended to say,
> just
> > > an
> > > > > attempt to eliminate the possible confusion.
> > > > >
> > > > > Thank you.
> > > > >
> > > > >
> > > > > > Think Java 11 is a good baseline as of today - at least to enable
> > > > Jakarta
> > > > > > vendors to use CXF as an implementation and pass tck.
> > > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
> > we
> > > > can
> > > > > > catch up later like other dropped integrations and core should be
> > > > > exploded
> > > > > > anyway, it is way too fat for what it does so moving spring out
> of
> > it
> > > > is
> > > > > > quite a good direction IMHO.
> > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <
> freeman.fang@gmail.com>
> > a
> > > > > écrit :
> > > > >
> > > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as
> baseline
> > > > > since we
> > > > > >> upgraded to Spring 6 and Spring Boot 3.
> > > > >
> > > > > >> Thanks to all guys involved in this long process!
> > > > > >> Freeman
> > > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> > > > wrote:
> > > > > >>> +1 to move forward with release (or milestone), but before
> that,
> > > > there
> > > > > is
> > > > > >>> one issue which
> > > > > >>> I would like to bring up and agree us upon. The initial
> > discussion
> > > > for
> > > > > >>> Jakarta / 4.0.0 [1] concluded
> > > > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > > > misalignment
> > > > > >>> with Spring 6 / Spring Boot 3
> > > > > >>> requirements which bumped the baseline to JDK-17. Now, the way
> we
> > > > build
> > > > > >>> Jakarta / 4.0.0 branch (main) is
> > > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > > > >
> > > > > >>> With that being said, the not so good part. Technically,
> Jakarta
> > /
> > > > > 4.0.0
> > > > > >>> bits could be used in the
> > > > > >>> projects which are still using JDK-11. But because mostly every
> > > > single
> > > > > >>> piece (starting from cxf-core) depends
> > > > > >>> on Spring, the application fail to start with
> > > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > > > >>> on any CXF provided sample). Effectively, the baseline is
> JDK-17,
> > > not
> > > > > >>> JDK-11 (we have hoped to isolate Spring
> > > > > >>> related implementation but it hasn't happened yet and not sure
> it
> > > > will
> > > > > in
> > > > > >>> the future). The question: does
> > > > > >>> anyone have a compelling usecase for keeping CXF baseline at
> > JDK-11
> > > > > level
> > > > > >>> despite being able to run only
> > > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > > > related
> > > > > >>> dependencies optional and document
> > > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> > > used,
> > > > we
> > > > > >>> surely cannot leave things
> > > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17
> as a
> > > > > >>> baseline.
> > > > > >>> What do you guys think?
> > > > > >>> Thank you.
> > > > > >>> [1]
> > https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > > > >>> Best Regards,
> > > > > >>> Andriy Redko
> > > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > > > RMB>>>> +1 to release, there are too much forks out there already
> so
> > > > better
> > > > > >> to
> > > > > RMB>>>> release partially than not release at all IMHO
> > > > > RMB>>>> Romain Manni-Bucau
> > > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > > > >>> https://github.com/rmannibucau> |
> > > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > RMB>>>> <
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
> > misagh.moayyed@gmail.com>
> > > a
> > > > > >>> écrit :
> > > > > >>>>> Hello all,
> > > > >
> > > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
> > new
> > > > > >>>>> release of wss4j that would contain this change:
> > > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > > > anticipated
> > > > > >>>>> to be GA before end of this year, hopefully.
> > > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <mail2jimma@gmail.com
> >
> > > > wrote:
> > > > > >>>>>> Hi all,
> > > > > >>>>>> After 9 months of work, we finally fixed/worked around all
> > > issues
> > > > > >> for
> > > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> > we
> > > > can
> > > > > >>> say
> > > > > >>>>> that
> > > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> > > Jakarta
> > > > >
> > > > > >>>>> EE9.1).
> > > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > > > community
> > > > > >>>>>> especially the user who asked for this jakarta artifacts
> like
> > > [1]
> > > > > >> and
> > > > > >>>>> get
> > > > > >>>>>> more feedback from our community, do you think it's time to
> > > > release
> > > > > >>> the
> > > > > >>>>> CXF
> > > > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > > > jakarta
> > > > >
> > > > > >>>>> release
> > > > > >>>>>> ?
> > > > > >>>>>> [1]
> > > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > > >>>>>> Thanks,
> > > > > >>>>>> Jim
> > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
>
> Alessio Soldano
>
> Manager, Software Engineering
>
> Red Hat <https://www.redhat.com>
> <https://www.redhat.com>
>
Re: CXF 4.0.0 jakarta release
Posted by Alessio Soldano <as...@apache.org>.
+1
I would suggest to deal with this in documentation, restricting runtime jdk
support to JDK17+ is actually going to create problems to some integration
(Spring is effectively optional already), while not really giving us much
(if you know you use Spring, just use JDK17, no need for it to be
mandatory). Btw, I believe JakartaEE 9.1 was meant to be used with JDK 8 or
11; support for JDK 17 is something coming with JakartaEE 10 afair.
Thanks
On Tue, Nov 8, 2022 at 1:34 PM Jim Ma <ma...@gmail.com> wrote:
> Yes. Spring is optional for CXF runtime for a long time. Now all CXF
> binary classes/artifacts are all JDK-11 version (class major version
> 55) as Andriy
> mentioned
> we set target/source to JDK-11. I believe this setting on CXF at the
> moment is the best option:
>
> - Users don't need to upgrade the JDK version if they are using CXF
> without Spring. FWIK, there are a lot of non-Spring CXF users out
> there.
> - For the CXF Spring users, because the Spring 6 Jakarta version is
> JDK-17 baseline and built classes are JDK-17 versions(class major
> version
> 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
> mandatory from Spring 6 and not from CXF.
>
>
> On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
> wrote:
>
> > Hello,
> >
> > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
> > optionally and we don't need to have spring artifacts on the classpath if
> > we don't want to use spring/spring boot features, and this has been the
> > case for a very long time.
> >
> > Freeman
> >
> > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > I was more referencing the long awaited split of cxf-core (it is still
> > the
> > > same old content than for the early jaxws time and without a modular
> > design
> > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
> sounds
> > > like a big awaited features (don't start by bringing 1.4M said
> > otherwise).
> > > Since several part of OSGi dropped I think it would be good to create
> > > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > > Since next release is mainly enabling cxf to hit jakarta, it sounds
> fine
> > > for me to drop spring if the refactor is too much and would delay a lot
> > the
> > > release - agree on this one.
> > > But keeping it like that means it will stay for years so likely that
> cxf
> > 4
> > > will be the same than cxf 3 on this point which would be sad IMHO.
> > >
> > > Side note: indeed the obvious answer to that point is "v5" but it is
> > > pushing again this issue (coming from v2 ;)) and also makes the
> > versioning
> > > harder to follow if not pushed too far IMHO.
> > >
> > > Hope it makes sense.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
> > >
> > > > Hi Romain,
> > > >
> > > > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > > > Spring
> > > > (this is basically another "few months long" effort), it is merely to
> > try
> > > > to
> > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
> Boot
> > at
> > > > this moment) by default. It would definitely require more work for
> the
> > > > users
> > > > to wire everything properly but at least that would allow us to
> > preserve
> > > > JDK-11
> > > > baseline. Apologies if I am rephrasing what you intended to say, just
> > an
> > > > attempt to eliminate the possible confusion.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > > Think Java 11 is a good baseline as of today - at least to enable
> > > Jakarta
> > > > > vendors to use CXF as an implementation and pass tck.
> > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
> we
> > > can
> > > > > catch up later like other dropped integrations and core should be
> > > > exploded
> > > > > anyway, it is way too fat for what it does so moving spring out of
> it
> > > is
> > > > > quite a good direction IMHO.
> > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com>
> a
> > > > écrit :
> > > >
> > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > > since we
> > > > >> upgraded to Spring 6 and Spring Boot 3.
> > > >
> > > > >> Thanks to all guys involved in this long process!
> > > > >> Freeman
> > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> > > wrote:
> > > > >>> +1 to move forward with release (or milestone), but before that,
> > > there
> > > > is
> > > > >>> one issue which
> > > > >>> I would like to bring up and agree us upon. The initial
> discussion
> > > for
> > > > >>> Jakarta / 4.0.0 [1] concluded
> > > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > > misalignment
> > > > >>> with Spring 6 / Spring Boot 3
> > > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> > > build
> > > > >>> Jakarta / 4.0.0 branch (main) is
> > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > > >
> > > > >>> With that being said, the not so good part. Technically, Jakarta
> /
> > > > 4.0.0
> > > > >>> bits could be used in the
> > > > >>> projects which are still using JDK-11. But because mostly every
> > > single
> > > > >>> piece (starting from cxf-core) depends
> > > > >>> on Spring, the application fail to start with
> > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
> > not
> > > > >>> JDK-11 (we have hoped to isolate Spring
> > > > >>> related implementation but it hasn't happened yet and not sure it
> > > will
> > > > in
> > > > >>> the future). The question: does
> > > > >>> anyone have a compelling usecase for keeping CXF baseline at
> JDK-11
> > > > level
> > > > >>> despite being able to run only
> > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > > related
> > > > >>> dependencies optional and document
> > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> > used,
> > > we
> > > > >>> surely cannot leave things
> > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > > > >>> baseline.
> > > > >>> What do you guys think?
> > > > >>> Thank you.
> > > > >>> [1]
> https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > > >>> Best Regards,
> > > > >>> Andriy Redko
> > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > > RMB>>>> +1 to release, there are too much forks out there already so
> > > better
> > > > >> to
> > > > RMB>>>> release partially than not release at all IMHO
> > > > RMB>>>> Romain Manni-Bucau
> > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > > >>> https://github.com/rmannibucau> |
> > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > RMB>>>> <
> > > > >>
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
> misagh.moayyed@gmail.com>
> > a
> > > > >>> écrit :
> > > > >>>>> Hello all,
> > > >
> > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
> new
> > > > >>>>> release of wss4j that would contain this change:
> > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > > anticipated
> > > > >>>>> to be GA before end of this year, hopefully.
> > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com>
> > > wrote:
> > > > >>>>>> Hi all,
> > > > >>>>>> After 9 months of work, we finally fixed/worked around all
> > issues
> > > > >> for
> > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> we
> > > can
> > > > >>> say
> > > > >>>>> that
> > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> > Jakarta
> > > >
> > > > >>>>> EE9.1).
> > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > > community
> > > > >>>>>> especially the user who asked for this jakarta artifacts like
> > [1]
> > > > >> and
> > > > >>>>> get
> > > > >>>>>> more feedback from our community, do you think it's time to
> > > release
> > > > >>> the
> > > > >>>>> CXF
> > > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > > jakarta
> > > >
> > > > >>>>> release
> > > > >>>>>> ?
> > > > >>>>>> [1]
> > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > >>>>>> Thanks,
> > > > >>>>>> Jim
> > > >
> > > >
> > >
> >
>
--
Alessio Soldano
Manager, Software Engineering
Red Hat <https://www.redhat.com>
<https://www.redhat.com>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
On Tue, Nov 8, 2022 at 9:01 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi,
>
> Ok so just to clarify it means
> 1. the cxf-core split (soap, rs, integration) is postponed > 4.x
>
+1.
> 2. the compiler setting is updated to add release (current setup is only
> source/target which does not guarantee that compiled with a jdk > version
> set in pom run on a lower jdk).
>
PR to add release to compiler plugin :
https://github.com/apache/cxf/pull/1023
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 8 nov. 2022 à 13:25, Jim Ma <ma...@gmail.com> a écrit :
>
> > Yes. Spring is optional for CXF runtime for a long time. Now all CXF
> > binary classes/artifacts are all JDK-11 version (class major version
> > 55) as Andriy
> > mentioned
> > we set target/source to JDK-11. I believe this setting on CXF at the
> > moment is the best option:
> >
> > - Users don't need to upgrade the JDK version if they are using CXF
> > without Spring. FWIK, there are a lot of non-Spring CXF users out
> > there.
> > - For the CXF Spring users, because the Spring 6 Jakarta version is
> > JDK-17 baseline and built classes are JDK-17 versions(class major
> > version
> > 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17
> is
> > mandatory from Spring 6 and not from CXF.
> >
> >
> > On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
> > > optionally and we don't need to have spring artifacts on the classpath
> if
> > > we don't want to use spring/spring boot features, and this has been the
> > > case for a very long time.
> > >
> > > Freeman
> > >
> > > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > wrote:
> > >
> > > > I was more referencing the long awaited split of cxf-core (it is
> still
> > > the
> > > > same old content than for the early jaxws time and without a modular
> > > design
> > > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
> > sounds
> > > > like a big awaited features (don't start by bringing 1.4M said
> > > otherwise).
> > > > Since several part of OSGi dropped I think it would be good to create
> > > > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > > > Since next release is mainly enabling cxf to hit jakarta, it sounds
> > fine
> > > > for me to drop spring if the refactor is too much and would delay a
> lot
> > > the
> > > > release - agree on this one.
> > > > But keeping it like that means it will stay for years so likely that
> > cxf
> > > 4
> > > > will be the same than cxf 3 on this point which would be sad IMHO.
> > > >
> > > > Side note: indeed the obvious answer to that point is "v5" but it is
> > > > pushing again this issue (coming from v2 ;)) and also makes the
> > > versioning
> > > > harder to follow if not pushed too far IMHO.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a
> écrit :
> > > >
> > > > > Hi Romain,
> > > > >
> > > > > Thanks a lot for the feedback, just to clarify: we won't be
> dropping
> > > > > Spring
> > > > > (this is basically another "few months long" effort), it is merely
> to
> > > try
> > > > > to
> > > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
> > Boot
> > > at
> > > > > this moment) by default. It would definitely require more work for
> > the
> > > > > users
> > > > > to wire everything properly but at least that would allow us to
> > > preserve
> > > > > JDK-11
> > > > > baseline. Apologies if I am rephrasing what you intended to say,
> just
> > > an
> > > > > attempt to eliminate the possible confusion.
> > > > >
> > > > > Thank you.
> > > > >
> > > > >
> > > > > > Think Java 11 is a good baseline as of today - at least to enable
> > > > Jakarta
> > > > > > vendors to use CXF as an implementation and pass tck.
> > > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
> > we
> > > > can
> > > > > > catch up later like other dropped integrations and core should be
> > > > > exploded
> > > > > > anyway, it is way too fat for what it does so moving spring out
> of
> > it
> > > > is
> > > > > > quite a good direction IMHO.
> > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <
> freeman.fang@gmail.com>
> > a
> > > > > écrit :
> > > > >
> > > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as
> baseline
> > > > > since we
> > > > > >> upgraded to Spring 6 and Spring Boot 3.
> > > > >
> > > > > >> Thanks to all guys involved in this long process!
> > > > > >> Freeman
> > > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> > > > wrote:
> > > > > >>> +1 to move forward with release (or milestone), but before
> that,
> > > > there
> > > > > is
> > > > > >>> one issue which
> > > > > >>> I would like to bring up and agree us upon. The initial
> > discussion
> > > > for
> > > > > >>> Jakarta / 4.0.0 [1] concluded
> > > > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > > > misalignment
> > > > > >>> with Spring 6 / Spring Boot 3
> > > > > >>> requirements which bumped the baseline to JDK-17. Now, the way
> we
> > > > build
> > > > > >>> Jakarta / 4.0.0 branch (main) is
> > > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > > > >
> > > > > >>> With that being said, the not so good part. Technically,
> Jakarta
> > /
> > > > > 4.0.0
> > > > > >>> bits could be used in the
> > > > > >>> projects which are still using JDK-11. But because mostly every
> > > > single
> > > > > >>> piece (starting from cxf-core) depends
> > > > > >>> on Spring, the application fail to start with
> > > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > > > >>> on any CXF provided sample). Effectively, the baseline is
> JDK-17,
> > > not
> > > > > >>> JDK-11 (we have hoped to isolate Spring
> > > > > >>> related implementation but it hasn't happened yet and not sure
> it
> > > > will
> > > > > in
> > > > > >>> the future). The question: does
> > > > > >>> anyone have a compelling usecase for keeping CXF baseline at
> > JDK-11
> > > > > level
> > > > > >>> despite being able to run only
> > > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > > > related
> > > > > >>> dependencies optional and document
> > > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> > > used,
> > > > we
> > > > > >>> surely cannot leave things
> > > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17
> as a
> > > > > >>> baseline.
> > > > > >>> What do you guys think?
> > > > > >>> Thank you.
> > > > > >>> [1]
> > https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > > > >>> Best Regards,
> > > > > >>> Andriy Redko
> > > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > > > RMB>>>> +1 to release, there are too much forks out there already
> so
> > > > better
> > > > > >> to
> > > > > RMB>>>> release partially than not release at all IMHO
> > > > > RMB>>>> Romain Manni-Bucau
> > > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > > > >>> https://github.com/rmannibucau> |
> > > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > RMB>>>> <
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
> > misagh.moayyed@gmail.com>
> > > a
> > > > > >>> écrit :
> > > > > >>>>> Hello all,
> > > > >
> > > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
> > new
> > > > > >>>>> release of wss4j that would contain this change:
> > > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > > > anticipated
> > > > > >>>>> to be GA before end of this year, hopefully.
> > > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <mail2jimma@gmail.com
> >
> > > > wrote:
> > > > > >>>>>> Hi all,
> > > > > >>>>>> After 9 months of work, we finally fixed/worked around all
> > > issues
> > > > > >> for
> > > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> > we
> > > > can
> > > > > >>> say
> > > > > >>>>> that
> > > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> > > Jakarta
> > > > >
> > > > > >>>>> EE9.1).
> > > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > > > community
> > > > > >>>>>> especially the user who asked for this jakarta artifacts
> like
> > > [1]
> > > > > >> and
> > > > > >>>>> get
> > > > > >>>>>> more feedback from our community, do you think it's time to
> > > > release
> > > > > >>> the
> > > > > >>>>> CXF
> > > > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > > > jakarta
> > > > >
> > > > > >>>>> release
> > > > > >>>>>> ?
> > > > > >>>>>> [1]
> > > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > > >>>>>> Thanks,
> > > > > >>>>>> Jim
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Regarding cxf-core split, correct, we won't be able to make it in 4.0.0
but dependencies should be formalized as optional [1] so we won't bring them
in unless Spring 6 / Spring Boot 3 is on the picture. Thanks!
[1] https://issues.apache.org/jira/browse/CXF-8791
Best Regards,
Andriy Redko
RMB> Hi,
RMB> Ok so just to clarify it means
RMB> 1. the cxf-core split (soap, rs, integration) is postponed > 4.x
RMB> 2. the compiler setting is updated to add release (current setup is only
RMB> source/target which does not guarantee that compiled with a jdk > version
RMB> set in pom run on a lower jdk).
RMB> Romain Manni-Bucau
RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB> <https://rmannibucau.metawerx.net/> | Old Blog
RMB> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
RMB> Le mar. 8 nov. 2022 à 13:25, Jim Ma <ma...@gmail.com> a écrit :
>> Yes. Spring is optional for CXF runtime for a long time. Now all CXF
>> binary classes/artifacts are all JDK-11 version (class major version
>> 55) as Andriy
>> mentioned
>> we set target/source to JDK-11. I believe this setting on CXF at the
>> moment is the best option:
>>
>> - Users don't need to upgrade the JDK version if they are using CXF
>> without Spring. FWIK, there are a lot of non-Spring CXF users out
>> there.
>> - For the CXF Spring users, because the Spring 6 Jakarta version is
>> JDK-17 baseline and built classes are JDK-17 versions(class major
>> version
>> 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
>> mandatory from Spring 6 and not from CXF.
>>
>>
>> On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
>> wrote:
>>
>> > Hello,
>> >
>> > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
>> > optionally and we don't need to have spring artifacts on the classpath if
>> > we don't want to use spring/spring boot features, and this has been the
>> > case for a very long time.
>> >
>> > Freeman
>> >
>> > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rmannibucau@gmail.com
>> >
>> > wrote:
>> >
>> > > I was more referencing the long awaited split of cxf-core (it is still
>> > the
>> > > same old content than for the early jaxws time and without a modular
>> > design
>> > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
>> sounds
>> > > like a big awaited features (don't start by bringing 1.4M said
>> > otherwise).
>> > > Since several part of OSGi dropped I think it would be good to create
>> > > cxf-spring (and maybe spring-boot thanks some generator like camel).
>> > > Since next release is mainly enabling cxf to hit jakarta, it sounds
>> fine
>> > > for me to drop spring if the refactor is too much and would delay a lot
>> > the
>> > > release - agree on this one.
>> > > But keeping it like that means it will stay for years so likely that
>> cxf
>> > 4
>> > > will be the same than cxf 3 on this point which would be sad IMHO.
>> > >
>> > > Side note: indeed the obvious answer to that point is "v5" but it is
>> > > pushing again this issue (coming from v2 ;)) and also makes the
>> > versioning
>> > > harder to follow if not pushed too far IMHO.
>> > >
>> > > Hope it makes sense.
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > >
>> > >
>> > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
>> > >
>> > > > Hi Romain,
>> > > >
>> > > > Thanks a lot for the feedback, just to clarify: we won't be dropping
>> > > > Spring
>> > > > (this is basically another "few months long" effort), it is merely to
>> > try
>> > > > to
>> > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
>> Boot
>> > at
>> > > > this moment) by default. It would definitely require more work for
>> the
>> > > > users
>> > > > to wire everything properly but at least that would allow us to
>> > preserve
>> > > > JDK-11
>> > > > baseline. Apologies if I am rephrasing what you intended to say, just
>> > an
>> > > > attempt to eliminate the possible confusion.
>> > > >
>> > > > Thank you.
>> > > >
>> > > >
>> > > > > Think Java 11 is a good baseline as of today - at least to enable
>> > > Jakarta
>> > > > > vendors to use CXF as an implementation and pass tck.
>> > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
>> we
>> > > can
>> > > > > catch up later like other dropped integrations and core should be
>> > > > exploded
>> > > > > anyway, it is way too fat for what it does so moving spring out of
>> it
>> > > is
>> > > > > quite a good direction IMHO.
>> > > >
>> > > > > Romain Manni-Bucau
>> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > https://github.com/rmannibucau> |
>> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > > <
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > >
>> > > >
>> > > >
>> > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com>
>> a
>> > > > écrit :
>> > > >
>> > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
>> > > > since we
>> > > > >> upgraded to Spring 6 and Spring Boot 3.
>> > > >
>> > > > >> Thanks to all guys involved in this long process!
>> > > > >> Freeman
>> > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
>> > > wrote:
>> > > > >>> +1 to move forward with release (or milestone), but before that,
>> > > there
>> > > > is
>> > > > >>> one issue which
>> > > > >>> I would like to bring up and agree us upon. The initial
>> discussion
>> > > for
>> > > > >>> Jakarta / 4.0.0 [1] concluded
>> > > > >>> on having JDK-11 as a baseline. At the same time, there is a
>> > > > misalignment
>> > > > >>> with Spring 6 / Spring Boot 3
>> > > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
>> > > build
>> > > > >>> Jakarta / 4.0.0 branch (main) is
>> > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
>> > > >
>> > > > >>> With that being said, the not so good part. Technically, Jakarta
>> /
>> > > > 4.0.0
>> > > > >>> bits could be used in the
>> > > > >>> projects which are still using JDK-11. But because mostly every
>> > > single
>> > > > >>> piece (starting from cxf-core) depends
>> > > > >>> on Spring, the application fail to start with
>> > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
>> > > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
>> > not
>> > > > >>> JDK-11 (we have hoped to isolate Spring
>> > > > >>> related implementation but it hasn't happened yet and not sure it
>> > > will
>> > > > in
>> > > > >>> the future). The question: does
>> > > > >>> anyone have a compelling usecase for keeping CXF baseline at
>> JDK-11
>> > > > level
>> > > > >>> despite being able to run only
>> > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
>> > > related
>> > > > >>> dependencies optional and document
>> > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
>> > used,
>> > > we
>> > > > >>> surely cannot leave things
>> > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
>> > > > >>> baseline.
>> > > > >>> What do you guys think?
>> > > > >>> Thank you.
>> > > > >>> [1]
>> https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
>> > > > >>> Best Regards,
>> > > > >>> Andriy Redko
>> > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
>> > > > RMB>>>> +1 to release, there are too much forks out there already so
>> > > better
>> > > > >> to
>> > > > RMB>>>> release partially than not release at all IMHO
>> > > > RMB>>>> Romain Manni-Bucau
>> > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
>> > > > >>> https://github.com/rmannibucau> |
>> > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > RMB>>>> <
>> > > > >>
>> > > >
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
>> misagh.moayyed@gmail.com>
>> > a
>> > > > >>> écrit :
>> > > > >>>>> Hello all,
>> > > >
>> > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
>> new
>> > > > >>>>> release of wss4j that would contain this change:
>> > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
>> > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
>> > > anticipated
>> > > > >>>>> to be GA before end of this year, hopefully.
>> > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com>
>> > > wrote:
>> > > > >>>>>> Hi all,
>> > > > >>>>>> After 9 months of work, we finally fixed/worked around all
>> > issues
>> > > > >> for
>> > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
>> > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
>> we
>> > > can
>> > > > >>> say
>> > > > >>>>> that
>> > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
>> > Jakarta
>> > > >
>> > > > >>>>> EE9.1).
>> > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
>> > > community
>> > > > >>>>>> especially the user who asked for this jakarta artifacts like
>> > [1]
>> > > > >> and
>> > > > >>>>> get
>> > > > >>>>>> more feedback from our community, do you think it's time to
>> > > release
>> > > > >>> the
>> > > > >>>>> CXF
>> > > > >>>>>> 4.0.0 and what else do you think we should have in this new
>> > > jakarta
>> > > >
>> > > > >>>>> release
>> > > > >>>>>> ?
>> > > > >>>>>> [1]
>> > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> > > > >>>>>> Thanks,
>> > > > >>>>>> Jim
>> > > >
>> > > >
>> > >
>> >
>>
Re: CXF 4.0.0 jakarta release
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Ok so just to clarify it means
1. the cxf-core split (soap, rs, integration) is postponed > 4.x
2. the compiler setting is updated to add release (current setup is only
source/target which does not guarantee that compiled with a jdk > version
set in pom run on a lower jdk).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 8 nov. 2022 à 13:25, Jim Ma <ma...@gmail.com> a écrit :
> Yes. Spring is optional for CXF runtime for a long time. Now all CXF
> binary classes/artifacts are all JDK-11 version (class major version
> 55) as Andriy
> mentioned
> we set target/source to JDK-11. I believe this setting on CXF at the
> moment is the best option:
>
> - Users don't need to upgrade the JDK version if they are using CXF
> without Spring. FWIK, there are a lot of non-Spring CXF users out
> there.
> - For the CXF Spring users, because the Spring 6 Jakarta version is
> JDK-17 baseline and built classes are JDK-17 versions(class major
> version
> 61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
> mandatory from Spring 6 and not from CXF.
>
>
> On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com>
> wrote:
>
> > Hello,
> >
> > FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
> > optionally and we don't need to have spring artifacts on the classpath if
> > we don't want to use spring/spring boot features, and this has been the
> > case for a very long time.
> >
> > Freeman
> >
> > On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > I was more referencing the long awaited split of cxf-core (it is still
> > the
> > > same old content than for the early jaxws time and without a modular
> > design
> > > - this is where spring comes from mainly IIRC) so for a 4.0.0 this
> sounds
> > > like a big awaited features (don't start by bringing 1.4M said
> > otherwise).
> > > Since several part of OSGi dropped I think it would be good to create
> > > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > > Since next release is mainly enabling cxf to hit jakarta, it sounds
> fine
> > > for me to drop spring if the refactor is too much and would delay a lot
> > the
> > > release - agree on this one.
> > > But keeping it like that means it will stay for years so likely that
> cxf
> > 4
> > > will be the same than cxf 3 on this point which would be sad IMHO.
> > >
> > > Side note: indeed the obvious answer to that point is "v5" but it is
> > > pushing again this issue (coming from v2 ;)) and also makes the
> > versioning
> > > harder to follow if not pushed too far IMHO.
> > >
> > > Hope it makes sense.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
> > >
> > > > Hi Romain,
> > > >
> > > > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > > > Spring
> > > > (this is basically another "few months long" effort), it is merely to
> > try
> > > > to
> > > > not bring any dependency with JDK-17 baseline (== Spring / Spring
> Boot
> > at
> > > > this moment) by default. It would definitely require more work for
> the
> > > > users
> > > > to wire everything properly but at least that would allow us to
> > preserve
> > > > JDK-11
> > > > baseline. Apologies if I am rephrasing what you intended to say, just
> > an
> > > > attempt to eliminate the possible confusion.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > > Think Java 11 is a good baseline as of today - at least to enable
> > > Jakarta
> > > > > vendors to use CXF as an implementation and pass tck.
> > > > > +1 to drop spring if it bothers to get a first 4.0.0 release out,
> we
> > > can
> > > > > catch up later like other dropped integrations and core should be
> > > > exploded
> > > > > anyway, it is way too fat for what it does so moving spring out of
> it
> > > is
> > > > > quite a good direction IMHO.
> > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com>
> a
> > > > écrit :
> > > >
> > > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > > since we
> > > > >> upgraded to Spring 6 and Spring Boot 3.
> > > >
> > > > >> Thanks to all guys involved in this long process!
> > > > >> Freeman
> > > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> > > wrote:
> > > > >>> +1 to move forward with release (or milestone), but before that,
> > > there
> > > > is
> > > > >>> one issue which
> > > > >>> I would like to bring up and agree us upon. The initial
> discussion
> > > for
> > > > >>> Jakarta / 4.0.0 [1] concluded
> > > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > > misalignment
> > > > >>> with Spring 6 / Spring Boot 3
> > > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> > > build
> > > > >>> Jakarta / 4.0.0 branch (main) is
> > > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > > >
> > > > >>> With that being said, the not so good part. Technically, Jakarta
> /
> > > > 4.0.0
> > > > >>> bits could be used in the
> > > > >>> projects which are still using JDK-11. But because mostly every
> > > single
> > > > >>> piece (starting from cxf-core) depends
> > > > >>> on Spring, the application fail to start with
> > > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
> > not
> > > > >>> JDK-11 (we have hoped to isolate Spring
> > > > >>> related implementation but it hasn't happened yet and not sure it
> > > will
> > > > in
> > > > >>> the future). The question: does
> > > > >>> anyone have a compelling usecase for keeping CXF baseline at
> JDK-11
> > > > level
> > > > >>> despite being able to run only
> > > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > > related
> > > > >>> dependencies optional and document
> > > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> > used,
> > > we
> > > > >>> surely cannot leave things
> > > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > > > >>> baseline.
> > > > >>> What do you guys think?
> > > > >>> Thank you.
> > > > >>> [1]
> https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > > >>> Best Regards,
> > > > >>> Andriy Redko
> > > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > > RMB>>>> +1 to release, there are too much forks out there already so
> > > better
> > > > >> to
> > > > RMB>>>> release partially than not release at all IMHO
> > > > RMB>>>> Romain Manni-Bucau
> > > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > > >>> https://github.com/rmannibucau> |
> > > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > RMB>>>> <
> > > > >>
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <
> misagh.moayyed@gmail.com>
> > a
> > > > >>> écrit :
> > > > >>>>> Hello all,
> > > >
> > > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a
> new
> > > > >>>>> release of wss4j that would contain this change:
> > > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > > anticipated
> > > > >>>>> to be GA before end of this year, hopefully.
> > > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com>
> > > wrote:
> > > > >>>>>> Hi all,
> > > > >>>>>> After 9 months of work, we finally fixed/worked around all
> > issues
> > > > >> for
> > > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and
> we
> > > can
> > > > >>> say
> > > > >>>>> that
> > > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> > Jakarta
> > > >
> > > > >>>>> EE9.1).
> > > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > > community
> > > > >>>>>> especially the user who asked for this jakarta artifacts like
> > [1]
> > > > >> and
> > > > >>>>> get
> > > > >>>>>> more feedback from our community, do you think it's time to
> > > release
> > > > >>> the
> > > > >>>>> CXF
> > > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > > jakarta
> > > >
> > > > >>>>> release
> > > > >>>>>> ?
> > > > >>>>>> [1]
> > > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > > >>>>>> Thanks,
> > > > >>>>>> Jim
> > > >
> > > >
> > >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Jim Ma <ma...@gmail.com>.
Yes. Spring is optional for CXF runtime for a long time. Now all CXF
binary classes/artifacts are all JDK-11 version (class major version
55) as Andriy
mentioned
we set target/source to JDK-11. I believe this setting on CXF at the
moment is the best option:
- Users don't need to upgrade the JDK version if they are using CXF
without Spring. FWIK, there are a lot of non-Spring CXF users out there.
- For the CXF Spring users, because the Spring 6 Jakarta version is
JDK-17 baseline and built classes are JDK-17 versions(class major version
61), they have to use JDK17 in runtime to run Spring and CXF. JDK-17 is
mandatory from Spring 6 and not from CXF.
On Tue, Nov 8, 2022 at 2:31 AM Freeman Fang <fr...@gmail.com> wrote:
> Hello,
>
> FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
> optionally and we don't need to have spring artifacts on the classpath if
> we don't want to use spring/spring boot features, and this has been the
> case for a very long time.
>
> Freeman
>
> On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > I was more referencing the long awaited split of cxf-core (it is still
> the
> > same old content than for the early jaxws time and without a modular
> design
> > - this is where spring comes from mainly IIRC) so for a 4.0.0 this sounds
> > like a big awaited features (don't start by bringing 1.4M said
> otherwise).
> > Since several part of OSGi dropped I think it would be good to create
> > cxf-spring (and maybe spring-boot thanks some generator like camel).
> > Since next release is mainly enabling cxf to hit jakarta, it sounds fine
> > for me to drop spring if the refactor is too much and would delay a lot
> the
> > release - agree on this one.
> > But keeping it like that means it will stay for years so likely that cxf
> 4
> > will be the same than cxf 3 on this point which would be sad IMHO.
> >
> > Side note: indeed the obvious answer to that point is "v5" but it is
> > pushing again this issue (coming from v2 ;)) and also makes the
> versioning
> > harder to follow if not pushed too far IMHO.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
> >
> > > Hi Romain,
> > >
> > > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > > Spring
> > > (this is basically another "few months long" effort), it is merely to
> try
> > > to
> > > not bring any dependency with JDK-17 baseline (== Spring / Spring Boot
> at
> > > this moment) by default. It would definitely require more work for the
> > > users
> > > to wire everything properly but at least that would allow us to
> preserve
> > > JDK-11
> > > baseline. Apologies if I am rephrasing what you intended to say, just
> an
> > > attempt to eliminate the possible confusion.
> > >
> > > Thank you.
> > >
> > >
> > > > Think Java 11 is a good baseline as of today - at least to enable
> > Jakarta
> > > > vendors to use CXF as an implementation and pass tck.
> > > > +1 to drop spring if it bothers to get a first 4.0.0 release out, we
> > can
> > > > catch up later like other dropped integrations and core should be
> > > exploded
> > > > anyway, it is way too fat for what it does so moving spring out of it
> > is
> > > > quite a good direction IMHO.
> > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com> a
> > > écrit :
> > >
> > > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > > since we
> > > >> upgraded to Spring 6 and Spring Boot 3.
> > >
> > > >> Thanks to all guys involved in this long process!
> > > >> Freeman
> > > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> > wrote:
> > > >>> +1 to move forward with release (or milestone), but before that,
> > there
> > > is
> > > >>> one issue which
> > > >>> I would like to bring up and agree us upon. The initial discussion
> > for
> > > >>> Jakarta / 4.0.0 [1] concluded
> > > >>> on having JDK-11 as a baseline. At the same time, there is a
> > > misalignment
> > > >>> with Spring 6 / Spring Boot 3
> > > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> > build
> > > >>> Jakarta / 4.0.0 branch (main) is
> > > >>> like this: use JDK-17+ but set target/source to JDK-11.
> > >
> > > >>> With that being said, the not so good part. Technically, Jakarta /
> > > 4.0.0
> > > >>> bits could be used in the
> > > >>> projects which are still using JDK-11. But because mostly every
> > single
> > > >>> piece (starting from cxf-core) depends
> > > >>> on Spring, the application fail to start with
> > > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > > >>> on any CXF provided sample). Effectively, the baseline is JDK-17,
> not
> > > >>> JDK-11 (we have hoped to isolate Spring
> > > >>> related implementation but it hasn't happened yet and not sure it
> > will
> > > in
> > > >>> the future). The question: does
> > > >>> anyone have a compelling usecase for keeping CXF baseline at JDK-11
> > > level
> > > >>> despite being able to run only
> > > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> > related
> > > >>> dependencies optional and document
> > > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are
> used,
> > we
> > > >>> surely cannot leave things
> > > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > > >>> baseline.
> > > >>> What do you guys think?
> > > >>> Thank you.
> > > >>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > > >>> Best Regards,
> > > >>> Andriy Redko
> > > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > > RMB>>>> +1 to release, there are too much forks out there already so
> > better
> > > >> to
> > > RMB>>>> release partially than not release at all IMHO
> > > RMB>>>> Romain Manni-Bucau
> > > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > > >>> https://github.com/rmannibucau> |
> > > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > RMB>>>> <
> > > >>
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com>
> a
> > > >>> écrit :
> > > >>>>> Hello all,
> > >
> > > >>>>> If possible, I'd like to ask that you allow v4 to ship with a new
> > > >>>>> release of wss4j that would contain this change:
> > > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> > anticipated
> > > >>>>> to be GA before end of this year, hopefully.
> > > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com>
> > wrote:
> > > >>>>>> Hi all,
> > > >>>>>> After 9 months of work, we finally fixed/worked around all
> issues
> > > >> for
> > > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we
> > can
> > > >>> say
> > > >>>>> that
> > > >>>>>> CXF successfully migrated to Jakarta namespace(and support
> Jakarta
> > >
> > > >>>>> EE9.1).
> > > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> > community
> > > >>>>>> especially the user who asked for this jakarta artifacts like
> [1]
> > > >> and
> > > >>>>> get
> > > >>>>>> more feedback from our community, do you think it's time to
> > release
> > > >>> the
> > > >>>>> CXF
> > > >>>>>> 4.0.0 and what else do you think we should have in this new
> > jakarta
> > >
> > > >>>>> release
> > > >>>>>> ?
> > > >>>>>> [1]
> > https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > > >>>>>> Thanks,
> > > >>>>>> Jim
> > >
> > >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Freeman Fang <fr...@gmail.com>.
Hello,
FWIW, Spring isn't mandatory for CXF, cxf-core only depends on spring
optionally and we don't need to have spring artifacts on the classpath if
we don't want to use spring/spring boot features, and this has been the
case for a very long time.
Freeman
On Mon, Nov 7, 2022 at 1:22 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I was more referencing the long awaited split of cxf-core (it is still the
> same old content than for the early jaxws time and without a modular design
> - this is where spring comes from mainly IIRC) so for a 4.0.0 this sounds
> like a big awaited features (don't start by bringing 1.4M said otherwise).
> Since several part of OSGi dropped I think it would be good to create
> cxf-spring (and maybe spring-boot thanks some generator like camel).
> Since next release is mainly enabling cxf to hit jakarta, it sounds fine
> for me to drop spring if the refactor is too much and would delay a lot the
> release - agree on this one.
> But keeping it like that means it will stay for years so likely that cxf 4
> will be the same than cxf 3 on this point which would be sad IMHO.
>
> Side note: indeed the obvious answer to that point is "v5" but it is
> pushing again this issue (coming from v2 ;)) and also makes the versioning
> harder to follow if not pushed too far IMHO.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
>
> > Hi Romain,
> >
> > Thanks a lot for the feedback, just to clarify: we won't be dropping
> > Spring
> > (this is basically another "few months long" effort), it is merely to try
> > to
> > not bring any dependency with JDK-17 baseline (== Spring / Spring Boot at
> > this moment) by default. It would definitely require more work for the
> > users
> > to wire everything properly but at least that would allow us to preserve
> > JDK-11
> > baseline. Apologies if I am rephrasing what you intended to say, just an
> > attempt to eliminate the possible confusion.
> >
> > Thank you.
> >
> >
> > > Think Java 11 is a good baseline as of today - at least to enable
> Jakarta
> > > vendors to use CXF as an implementation and pass tck.
> > > +1 to drop spring if it bothers to get a first 4.0.0 release out, we
> can
> > > catch up later like other dropped integrations and core should be
> > exploded
> > > anyway, it is way too fat for what it does so moving spring out of it
> is
> > > quite a good direction IMHO.
> >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com> a
> > écrit :
> >
> > >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> > since we
> > >> upgraded to Spring 6 and Spring Boot 3.
> >
> > >> Thanks to all guys involved in this long process!
> > >> Freeman
> > >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com>
> wrote:
> > >>> +1 to move forward with release (or milestone), but before that,
> there
> > is
> > >>> one issue which
> > >>> I would like to bring up and agree us upon. The initial discussion
> for
> > >>> Jakarta / 4.0.0 [1] concluded
> > >>> on having JDK-11 as a baseline. At the same time, there is a
> > misalignment
> > >>> with Spring 6 / Spring Boot 3
> > >>> requirements which bumped the baseline to JDK-17. Now, the way we
> build
> > >>> Jakarta / 4.0.0 branch (main) is
> > >>> like this: use JDK-17+ but set target/source to JDK-11.
> >
> > >>> With that being said, the not so good part. Technically, Jakarta /
> > 4.0.0
> > >>> bits could be used in the
> > >>> projects which are still using JDK-11. But because mostly every
> single
> > >>> piece (starting from cxf-core) depends
> > >>> on Spring, the application fail to start with
> > >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > >>> on any CXF provided sample). Effectively, the baseline is JDK-17, not
> > >>> JDK-11 (we have hoped to isolate Spring
> > >>> related implementation but it hasn't happened yet and not sure it
> will
> > in
> > >>> the future). The question: does
> > >>> anyone have a compelling usecase for keeping CXF baseline at JDK-11
> > level
> > >>> despite being able to run only
> > >>> on JDK-17 or above? If yes, I think we have to make all Spring
> related
> > >>> dependencies optional and document
> > >>> clearly that JDK-17 is needed in case Spring / Spring Boot are used,
> we
> > >>> surely cannot leave things
> > >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > >>> baseline.
> > >>> What do you guys think?
> > >>> Thank you.
> > >>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> > >>> Best Regards,
> > >>> Andriy Redko
> > >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> > RMB>>>> +1 to release, there are too much forks out there already so
> better
> > >> to
> > RMB>>>> release partially than not release at all IMHO
> > RMB>>>> Romain Manni-Bucau
> > RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> > >>> https://github.com/rmannibucau> |
> > RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > RMB>>>> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a
> > >>> écrit :
> > >>>>> Hello all,
> >
> > >>>>> If possible, I'd like to ask that you allow v4 to ship with a new
> > >>>>> release of wss4j that would contain this change:
> > >>>>> https://github.com/apache/ws-wss4j/pull/62
> > >>>>> At the moment, OpenSAML v5 is not released yet, but it is
> anticipated
> > >>>>> to be GA before end of this year, hopefully.
> > >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com>
> wrote:
> > >>>>>> Hi all,
> > >>>>>> After 9 months of work, we finally fixed/worked around all issues
> > >> for
> > >>>>>> Jakarta support. Now all the cxf tests are passed:
> > >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we
> can
> > >>> say
> > >>>>> that
> > >>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
> >
> > >>>>> EE9.1).
> > >>>>>> To get cxf jakarta artifacts/binary available for the CXF
> community
> > >>>>>> especially the user who asked for this jakarta artifacts like [1]
> > >> and
> > >>>>> get
> > >>>>>> more feedback from our community, do you think it's time to
> release
> > >>> the
> > >>>>> CXF
> > >>>>>> 4.0.0 and what else do you think we should have in this new
> jakarta
> >
> > >>>>> release
> > >>>>>> ?
> > >>>>>> [1]
> https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > >>>>>> Thanks,
> > >>>>>> Jim
> >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I was more referencing the long awaited split of cxf-core (it is still the
same old content than for the early jaxws time and without a modular design
- this is where spring comes from mainly IIRC) so for a 4.0.0 this sounds
like a big awaited features (don't start by bringing 1.4M said otherwise).
Since several part of OSGi dropped I think it would be good to create
cxf-spring (and maybe spring-boot thanks some generator like camel).
Since next release is mainly enabling cxf to hit jakarta, it sounds fine
for me to drop spring if the refactor is too much and would delay a lot the
release - agree on this one.
But keeping it like that means it will stay for years so likely that cxf 4
will be the same than cxf 3 on this point which would be sad IMHO.
Side note: indeed the obvious answer to that point is "v5" but it is
pushing again this issue (coming from v2 ;)) and also makes the versioning
harder to follow if not pushed too far IMHO.
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 7 nov. 2022 à 19:10, Andriy Redko <dr...@gmail.com> a écrit :
> Hi Romain,
>
> Thanks a lot for the feedback, just to clarify: we won't be dropping
> Spring
> (this is basically another "few months long" effort), it is merely to try
> to
> not bring any dependency with JDK-17 baseline (== Spring / Spring Boot at
> this moment) by default. It would definitely require more work for the
> users
> to wire everything properly but at least that would allow us to preserve
> JDK-11
> baseline. Apologies if I am rephrasing what you intended to say, just an
> attempt to eliminate the possible confusion.
>
> Thank you.
>
>
> > Think Java 11 is a good baseline as of today - at least to enable Jakarta
> > vendors to use CXF as an implementation and pass tck.
> > +1 to drop spring if it bothers to get a first 4.0.0 release out, we can
> > catch up later like other dropped integrations and core should be
> exploded
> > anyway, it is way too fat for what it does so moving spring out of it is
> > quite a good direction IMHO.
>
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> > Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com> a
> écrit :
>
> >> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline
> since we
> >> upgraded to Spring 6 and Spring Boot 3.
>
> >> Thanks to all guys involved in this long process!
> >> Freeman
> >> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com> wrote:
> >>> +1 to move forward with release (or milestone), but before that, there
> is
> >>> one issue which
> >>> I would like to bring up and agree us upon. The initial discussion for
> >>> Jakarta / 4.0.0 [1] concluded
> >>> on having JDK-11 as a baseline. At the same time, there is a
> misalignment
> >>> with Spring 6 / Spring Boot 3
> >>> requirements which bumped the baseline to JDK-17. Now, the way we build
> >>> Jakarta / 4.0.0 branch (main) is
> >>> like this: use JDK-17+ but set target/source to JDK-11.
>
> >>> With that being said, the not so good part. Technically, Jakarta /
> 4.0.0
> >>> bits could be used in the
> >>> projects which are still using JDK-11. But because mostly every single
> >>> piece (starting from cxf-core) depends
> >>> on Spring, the application fail to start with
> >>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> >>> on any CXF provided sample). Effectively, the baseline is JDK-17, not
> >>> JDK-11 (we have hoped to isolate Spring
> >>> related implementation but it hasn't happened yet and not sure it will
> in
> >>> the future). The question: does
> >>> anyone have a compelling usecase for keeping CXF baseline at JDK-11
> level
> >>> despite being able to run only
> >>> on JDK-17 or above? If yes, I think we have to make all Spring related
> >>> dependencies optional and document
> >>> clearly that JDK-17 is needed in case Spring / Spring Boot are used, we
> >>> surely cannot leave things
> >>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> >>> baseline.
> >>> What do you guys think?
> >>> Thank you.
> >>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> >>> Best Regards,
> >>> Andriy Redko
> >>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
> RMB>>>> +1 to release, there are too much forks out there already so better
> >> to
> RMB>>>> release partially than not release at all IMHO
> RMB>>>> Romain Manni-Bucau
> RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> RMB>>>> <http://rmannibucau.wordpress.com> | Github <
> >>> https://github.com/rmannibucau> |
> RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> RMB>>>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a
> >>> écrit :
> >>>>> Hello all,
>
> >>>>> If possible, I'd like to ask that you allow v4 to ship with a new
> >>>>> release of wss4j that would contain this change:
> >>>>> https://github.com/apache/ws-wss4j/pull/62
> >>>>> At the moment, OpenSAML v5 is not released yet, but it is anticipated
> >>>>> to be GA before end of this year, hopefully.
> >>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
> >>>>>> Hi all,
> >>>>>> After 9 months of work, we finally fixed/worked around all issues
> >> for
> >>>>>> Jakarta support. Now all the cxf tests are passed:
> >>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> >>> say
> >>>>> that
> >>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>
> >>>>> EE9.1).
> >>>>>> To get cxf jakarta artifacts/binary available for the CXF community
> >>>>>> especially the user who asked for this jakarta artifacts like [1]
> >> and
> >>>>> get
> >>>>>> more feedback from our community, do you think it's time to release
> >>> the
> >>>>> CXF
> >>>>>> 4.0.0 and what else do you think we should have in this new jakarta
>
> >>>>> release
> >>>>>> ?
> >>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >>>>>> Thanks,
> >>>>>> Jim
>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
Hi Romain,
Thanks a lot for the feedback, just to clarify: we won't be dropping Spring
(this is basically another "few months long" effort), it is merely to try to
not bring any dependency with JDK-17 baseline (== Spring / Spring Boot at
this moment) by default. It would definitely require more work for the users
to wire everything properly but at least that would allow us to preserve JDK-11
baseline. Apologies if I am rephrasing what you intended to say, just an
attempt to eliminate the possible confusion.
Thank you.
> Think Java 11 is a good baseline as of today - at least to enable Jakarta
> vendors to use CXF as an implementation and pass tck.
> +1 to drop spring if it bothers to get a first 4.0.0 release out, we can
> catch up later like other dropped integrations and core should be exploded
> anyway, it is way too fat for what it does so moving spring out of it is
> quite a good direction IMHO.
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com> a écrit :
>> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline since we
>> upgraded to Spring 6 and Spring Boot 3.
>> Thanks to all guys involved in this long process!
>> Freeman
>> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com> wrote:
>>> +1 to move forward with release (or milestone), but before that, there is
>>> one issue which
>>> I would like to bring up and agree us upon. The initial discussion for
>>> Jakarta / 4.0.0 [1] concluded
>>> on having JDK-11 as a baseline. At the same time, there is a misalignment
>>> with Spring 6 / Spring Boot 3
>>> requirements which bumped the baseline to JDK-17. Now, the way we build
>>> Jakarta / 4.0.0 branch (main) is
>>> like this: use JDK-17+ but set target/source to JDK-11.
>>> With that being said, the not so good part. Technically, Jakarta / 4.0.0
>>> bits could be used in the
>>> projects which are still using JDK-11. But because mostly every single
>>> piece (starting from cxf-core) depends
>>> on Spring, the application fail to start with
>>> "java.lang.UnsupportedClassVersionError" (very easy to confirm
>>> on any CXF provided sample). Effectively, the baseline is JDK-17, not
>>> JDK-11 (we have hoped to isolate Spring
>>> related implementation but it hasn't happened yet and not sure it will in
>>> the future). The question: does
>>> anyone have a compelling usecase for keeping CXF baseline at JDK-11 level
>>> despite being able to run only
>>> on JDK-17 or above? If yes, I think we have to make all Spring related
>>> dependencies optional and document
>>> clearly that JDK-17 is needed in case Spring / Spring Boot are used, we
>>> surely cannot leave things
>>> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
>>> baseline.
>>> What do you guys think?
>>> Thank you.
>>> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
>>> Best Regards,
>>> Andriy Redko
>>> Monday, November 7, 2022, 8:50:02 AM, you wrote:
RMB>>>> +1 to release, there are too much forks out there already so better
>> to
RMB>>>> release partially than not release at all IMHO
RMB>>>> Romain Manni-Bucau
RMB>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB>>>> <https://rmannibucau.metawerx.net/> | Old Blog
RMB>>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
RMB>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB>>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
RMB>>>> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a
>>> écrit :
>>>>> Hello all,
>>>>> If possible, I'd like to ask that you allow v4 to ship with a new
>>>>> release of wss4j that would contain this change:
>>>>> https://github.com/apache/ws-wss4j/pull/62
>>>>> At the moment, OpenSAML v5 is not released yet, but it is anticipated
>>>>> to be GA before end of this year, hopefully.
>>>>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
>>>>>> Hi all,
>>>>>> After 9 months of work, we finally fixed/worked around all issues
>> for
>>>>>> Jakarta support. Now all the cxf tests are passed:
>>>>>> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
>>> say
>>>>> that
>>>>>> CXF successfully migrated to Jakarta namespace(and support Jakarta
>>>>> EE9.1).
>>>>>> To get cxf jakarta artifacts/binary available for the CXF community
>>>>>> especially the user who asked for this jakarta artifacts like [1]
>> and
>>>>> get
>>>>>> more feedback from our community, do you think it's time to release
>>> the
>>>>> CXF
>>>>>> 4.0.0 and what else do you think we should have in this new jakarta
>>>>> release
>>>>>> ?
>>>>>> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>>>>>> Thanks,
>>>>>> Jim
Re: CXF 4.0.0 jakarta release
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think Java 11 is a good baseline as of today - at least to enable Jakarta
vendors to use CXF as an implementation and pass tck.
+1 to drop spring if it bothers to get a first 4.0.0 release out, we can
catch up later like other dropped integrations and core should be exploded
anyway, it is way too fat for what it does so moving spring out of it is
quite a good direction IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 7 nov. 2022 à 18:06, Freeman Fang <fr...@gmail.com> a écrit :
> +1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline since we
> upgraded to Spring 6 and Spring Boot 3.
>
> Thanks to all guys involved in this long process!
> Freeman
>
> On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com> wrote:
>
> > +1 to move forward with release (or milestone), but before that, there is
> > one issue which
> > I would like to bring up and agree us upon. The initial discussion for
> > Jakarta / 4.0.0 [1] concluded
> > on having JDK-11 as a baseline. At the same time, there is a misalignment
> > with Spring 6 / Spring Boot 3
> > requirements which bumped the baseline to JDK-17. Now, the way we build
> > Jakarta / 4.0.0 branch (main) is
> > like this: use JDK-17+ but set target/source to JDK-11.
> >
> > With that being said, the not so good part. Technically, Jakarta / 4.0.0
> > bits could be used in the
> > projects which are still using JDK-11. But because mostly every single
> > piece (starting from cxf-core) depends
> > on Spring, the application fail to start with
> > "java.lang.UnsupportedClassVersionError" (very easy to confirm
> > on any CXF provided sample). Effectively, the baseline is JDK-17, not
> > JDK-11 (we have hoped to isolate Spring
> > related implementation but it hasn't happened yet and not sure it will in
> > the future). The question: does
> > anyone have a compelling usecase for keeping CXF baseline at JDK-11 level
> > despite being able to run only
> > on JDK-17 or above? If yes, I think we have to make all Spring related
> > dependencies optional and document
> > clearly that JDK-17 is needed in case Spring / Spring Boot are used, we
> > surely cannot leave things
> > as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> > baseline.
> >
> > What do you guys think?
> > Thank you.
> >
> >
> > [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
> >
> > Best Regards,
> > Andriy Redko
> >
> > Monday, November 7, 2022, 8:50:02 AM, you wrote:
> >
> > RMB> +1 to release, there are too much forks out there already so better
> to
> > RMB> release partially than not release at all IMHO
> >
> > RMB> Romain Manni-Bucau
> > RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > RMB> <https://rmannibucau.metawerx.net/> | Old Blog
> > RMB> <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > RMB> <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > RMB> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a
> > écrit :
> >
> > >> Hello all,
> > >>
> > >> If possible, I'd like to ask that you allow v4 to ship with a new
> > >> release of wss4j that would contain this change:
> > >> https://github.com/apache/ws-wss4j/pull/62
> > >>
> > >> At the moment, OpenSAML v5 is not released yet, but it is anticipated
> > >> to be GA before end of this year, hopefully.
> > >>
> > >> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
> > >> >
> > >> > Hi all,
> > >> > After 9 months of work, we finally fixed/worked around all issues
> for
> > >> > Jakarta support. Now all the cxf tests are passed:
> > >> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> > say
> > >> that
> > >> > CXF successfully migrated to Jakarta namespace(and support Jakarta
> > >> EE9.1).
> > >> > To get cxf jakarta artifacts/binary available for the CXF community
> > >> > especially the user who asked for this jakarta artifacts like [1]
> and
> > >> get
> > >> > more feedback from our community, do you think it's time to release
> > the
> > >> CXF
> > >> > 4.0.0 and what else do you think we should have in this new jakarta
> > >> release
> > >> > ?
> > >> >
> > >> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> > >> >
> > >> > Thanks,
> > >> > Jim
> > >>
> >
> >
>
Re: CXF 4.0.0 jakarta release
Posted by Freeman Fang <fr...@gmail.com>.
+1 to release CXF 4.0.0. And +1 to release using JDK17 as baseline since we
upgraded to Spring 6 and Spring Boot 3.
Thanks to all guys involved in this long process!
Freeman
On Mon, Nov 7, 2022 at 11:10 AM Andriy Redko <dr...@gmail.com> wrote:
> +1 to move forward with release (or milestone), but before that, there is
> one issue which
> I would like to bring up and agree us upon. The initial discussion for
> Jakarta / 4.0.0 [1] concluded
> on having JDK-11 as a baseline. At the same time, there is a misalignment
> with Spring 6 / Spring Boot 3
> requirements which bumped the baseline to JDK-17. Now, the way we build
> Jakarta / 4.0.0 branch (main) is
> like this: use JDK-17+ but set target/source to JDK-11.
>
> With that being said, the not so good part. Technically, Jakarta / 4.0.0
> bits could be used in the
> projects which are still using JDK-11. But because mostly every single
> piece (starting from cxf-core) depends
> on Spring, the application fail to start with
> "java.lang.UnsupportedClassVersionError" (very easy to confirm
> on any CXF provided sample). Effectively, the baseline is JDK-17, not
> JDK-11 (we have hoped to isolate Spring
> related implementation but it hasn't happened yet and not sure it will in
> the future). The question: does
> anyone have a compelling usecase for keeping CXF baseline at JDK-11 level
> despite being able to run only
> on JDK-17 or above? If yes, I think we have to make all Spring related
> dependencies optional and document
> clearly that JDK-17 is needed in case Spring / Spring Boot are used, we
> surely cannot leave things
> as-is (in my opinion). If not, I would suggest to set JDK-17 as a
> baseline.
>
> What do you guys think?
> Thank you.
>
>
> [1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
>
> Best Regards,
> Andriy Redko
>
> Monday, November 7, 2022, 8:50:02 AM, you wrote:
>
> RMB> +1 to release, there are too much forks out there already so better to
> RMB> release partially than not release at all IMHO
>
> RMB> Romain Manni-Bucau
> RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> RMB> <https://rmannibucau.metawerx.net/> | Old Blog
> RMB> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> RMB> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> RMB> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a
> écrit :
>
> >> Hello all,
> >>
> >> If possible, I'd like to ask that you allow v4 to ship with a new
> >> release of wss4j that would contain this change:
> >> https://github.com/apache/ws-wss4j/pull/62
> >>
> >> At the moment, OpenSAML v5 is not released yet, but it is anticipated
> >> to be GA before end of this year, hopefully.
> >>
> >> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
> >> >
> >> > Hi all,
> >> > After 9 months of work, we finally fixed/worked around all issues for
> >> > Jakarta support. Now all the cxf tests are passed:
> >> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can
> say
> >> that
> >> > CXF successfully migrated to Jakarta namespace(and support Jakarta
> >> EE9.1).
> >> > To get cxf jakarta artifacts/binary available for the CXF community
> >> > especially the user who asked for this jakarta artifacts like [1] and
> >> get
> >> > more feedback from our community, do you think it's time to release
> the
> >> CXF
> >> > 4.0.0 and what else do you think we should have in this new jakarta
> >> release
> >> > ?
> >> >
> >> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >> >
> >> > Thanks,
> >> > Jim
> >>
>
>
Re: CXF 4.0.0 jakarta release
Posted by Andriy Redko <dr...@gmail.com>.
+1 to move forward with release (or milestone), but before that, there is one issue which
I would like to bring up and agree us upon. The initial discussion for Jakarta / 4.0.0 [1] concluded
on having JDK-11 as a baseline. At the same time, there is a misalignment with Spring 6 / Spring Boot 3
requirements which bumped the baseline to JDK-17. Now, the way we build Jakarta / 4.0.0 branch (main) is
like this: use JDK-17+ but set target/source to JDK-11.
With that being said, the not so good part. Technically, Jakarta / 4.0.0 bits could be used in the
projects which are still using JDK-11. But because mostly every single piece (starting from cxf-core) depends
on Spring, the application fail to start with "java.lang.UnsupportedClassVersionError" (very easy to confirm
on any CXF provided sample). Effectively, the baseline is JDK-17, not JDK-11 (we have hoped to isolate Spring
related implementation but it hasn't happened yet and not sure it will in the future). The question: does
anyone have a compelling usecase for keeping CXF baseline at JDK-11 level despite being able to run only
on JDK-17 or above? If yes, I think we have to make all Spring related dependencies optional and document
clearly that JDK-17 is needed in case Spring / Spring Boot are used, we surely cannot leave things
as-is (in my opinion). If not, I would suggest to set JDK-17 as a baseline.
What do you guys think?
Thank you.
[1] https://www.mail-archive.com/dev@cxf.apache.org/msg17031.html
Best Regards,
Andriy Redko
Monday, November 7, 2022, 8:50:02 AM, you wrote:
RMB> +1 to release, there are too much forks out there already so better to
RMB> release partially than not release at all IMHO
RMB> Romain Manni-Bucau
RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB> <https://rmannibucau.metawerx.net/> | Old Blog
RMB> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
RMB> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
RMB> Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a écrit :
>> Hello all,
>>
>> If possible, I'd like to ask that you allow v4 to ship with a new
>> release of wss4j that would contain this change:
>> https://github.com/apache/ws-wss4j/pull/62
>>
>> At the moment, OpenSAML v5 is not released yet, but it is anticipated
>> to be GA before end of this year, hopefully.
>>
>> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
>> >
>> > Hi all,
>> > After 9 months of work, we finally fixed/worked around all issues for
>> > Jakarta support. Now all the cxf tests are passed:
>> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
>> that
>> > CXF successfully migrated to Jakarta namespace(and support Jakarta
>> EE9.1).
>> > To get cxf jakarta artifacts/binary available for the CXF community
>> > especially the user who asked for this jakarta artifacts like [1] and
>> get
>> > more feedback from our community, do you think it's time to release the
>> CXF
>> > 4.0.0 and what else do you think we should have in this new jakarta
>> release
>> > ?
>> >
>> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>> >
>> > Thanks,
>> > Jim
>>
Re: CXF 4.0.0 jakarta release
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 to release, there are too much forks out there already so better to
release partially than not release at all IMHO
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 7 nov. 2022 à 14:25, Misagh <mi...@gmail.com> a écrit :
> Hello all,
>
> If possible, I'd like to ask that you allow v4 to ship with a new
> release of wss4j that would contain this change:
> https://github.com/apache/ws-wss4j/pull/62
>
> At the moment, OpenSAML v5 is not released yet, but it is anticipated
> to be GA before end of this year, hopefully.
>
> On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
> >
> > Hi all,
> > After 9 months of work, we finally fixed/worked around all issues for
> > Jakarta support. Now all the cxf tests are passed:
> > https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say
> that
> > CXF successfully migrated to Jakarta namespace(and support Jakarta
> EE9.1).
> > To get cxf jakarta artifacts/binary available for the CXF community
> > especially the user who asked for this jakarta artifacts like [1] and
> get
> > more feedback from our community, do you think it's time to release the
> CXF
> > 4.0.0 and what else do you think we should have in this new jakarta
> release
> > ?
> >
> > [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
> >
> > Thanks,
> > Jim
>
Re: CXF 4.0.0 jakarta release
Posted by Misagh <mi...@gmail.com>.
Hello all,
If possible, I'd like to ask that you allow v4 to ship with a new
release of wss4j that would contain this change:
https://github.com/apache/ws-wss4j/pull/62
At the moment, OpenSAML v5 is not released yet, but it is anticipated
to be GA before end of this year, hopefully.
On Mon, Nov 7, 2022 at 12:19 PM Jim Ma <ma...@gmail.com> wrote:
>
> Hi all,
> After 9 months of work, we finally fixed/worked around all issues for
> Jakarta support. Now all the cxf tests are passed:
> https://ci-builds.apache.org/job/CXF/job/CXF-JDK17/848/ and we can say that
> CXF successfully migrated to Jakarta namespace(and support Jakarta EE9.1).
> To get cxf jakarta artifacts/binary available for the CXF community
> especially the user who asked for this jakarta artifacts like [1] and get
> more feedback from our community, do you think it's time to release the CXF
> 4.0.0 and what else do you think we should have in this new jakarta release
> ?
>
> [1]https://lists.apache.org/thread/kwfg2s5gj72tkgn5c5vdcsvtgdkdm6dl
>
> Thanks,
> Jim