Thanks for the informative input, Freeman.
IMO, If we want to decouple OSGI/Karaf, the 4.0 major release is a good
chance to do this job. When OSGI/Karaf jakarta release is ready,
We can look at bringing this back with more improvement and refactor work
to make it loosely coupled with core code.
On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang wrote:
> Hi Jim,
>
> Sorry for the late reply, just back from vacation.
>
> About the OSGi part, the main problem is that the OSGi R9 spec which will
> support Jakarta namespace is in progress and isn't released yet(and I don't
> think there is a concrete release date for OSGi R9 spec in the new future).
> Before OSGi R9 spec gets released and adopted by OSGi implementations like
> Felix/Equinox, I don't think there is much we can do in CXF or even in
> Karaf about this part.
>
> And Andriy, you are right, release CXF 4.0 M1 without OSGi/Karaf bit
> seems the only option we have so far, and I'm +1 for this way now(Since we
> don't know how long we need to wait for the proper OSGi spec released and
> upstream projects can support it).
>
> Just my 2 cents.
> Best Regards
> Freeman
>
> On Mon, Aug 22, 2022 at 10:34 PM Jim Ma wrote:
>
>> For OSGI and Karaf Jakarta native, I remembered I talked with Freeman
>> about this topic several months ago and got to know
>> there won't be Jakarta namespace support work in the future. I don't know
>> if this has changed.
>> Freeman, do you have some update on this ?
>>
>>
>> On Tue, Aug 23, 2022 at 6:43 AM Andriy Redko wrote:
>>
>>> Hey Jim,
>>>
>>> I think these [1], [2], [3] (Swagger 1.x, OSGi and Karaf) are real
>>> blockers. For Swagger 1.x, we could
>>> go ahead and drop the support altogether, this is quite isolated
>>> feature. OSGi and Karaf are not, those
>>> penetrated very deep into core. What worries me, if we drop everything
>>> OSGi/Karaf related from 4.0.0, we
>>> may need to bring it back some time in the future (with OSGi R9 [4] fe)
>>> and that is going to be quite
>>> difficult. From other side, this is probably the only option to have
>>> 4.0.0 milestone out (we excluded some
>>> modules from the build right now but that is more like a temporary hack
>>> which we should not release upon,
>>> even alphas). What do you think guys?
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> [1] https://issues.apache.org/jira/browse/CXF-8714
>>> [2] https://issues.apache.org/jira/browse/CXF-8723
>>> [3] https://issues.apache.org/jira/browse/CXF-8722
>>> [4] https://github.com/osgi/osgi/milestone/5
>>>
>>> JM> After we merged the jakarta branch to default branch main branch,
>>> do we
>>> JM> need to create some
>>> JM> plan to do a future 4.x release?
>>>
>>> JM> There are a couple of to-do things under
>>> JM> https://issues.apache.org/jira/browse/CXF-8371 umberbralla,
>>> JM> and for some of them we can't do more things because of the jakarta
>>> JM> dependency missing. It seems that some of the dependencies won't
>>> JM> have the jakarta namespace artifact released in the near future.
>>> Should we
>>> JM> have some milestone/alpha release
>>> JM> before all these dependencies are available ? And if we want to do a
>>> JM> milestone release, what do you think we should have in
>>> JM> this 4.0.0-M1 release ?
>>>
>>>
>>> JM> Thanks,
>>> JM> Jim
>>>
>>>
>>>
>>> JM> On Wed, Jun 22, 2022 at 10:02 AM Jim Ma
>>> wrote:
>>>
>>> >> Thanks Andriy too for driving this and moving forward !
>>> >>
>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko
>>> wrote:
>>> >>
>>> >>> Hey guys,
>>> >>>
>>> >>> The Jakarta branch [1] just went into master, HUGE THANKS everyone
>>> for
>>> >>> tremendous effort! Please
>>> >>> note, it is still work in progress, the things to be done are tracked
>>> >>> under [2], feel free to
>>> >>> add more items or pick the existing ones. The master builds still
>>> have
>>> >>> some tests failing, but those
>>> >>> should be fixed shortly. With that, 3.6.x-fixes becomes the "mirror"
>>> of
>>> >>> the master but for javax.*
>>> >>> packages. Cherrypicking / backporting changes from master might be a
>>> bit
>>> >>> more complicated (jakarta.* -> javax.*)
>>> >>> but manageable.
>>> >>>
>>> >>> One more thing, the pull requests against master and 3.6.x / 3.5.x
>>> are
>>> >>> build using JDK-17 now (was JDK-11
>>> >>> before), this is due to the fact that master needs JDK-17, as it's
>>> Spring
>>> >>> 6 / Spring Boot 3 JDK baseline.
>>> >>> I have difficulties configuring Jenkins Maven builds + Github Pull
>>> >>> Request builder per branch. It may be
>>> >>> possible with pipeline, I will experiment with that. Please share any
>>> >>> concerns, comments or feedback, it
>>> >>> is highly appreciated.
>>> >>>
>>> >>> Thank you!
>>> >>>
>>> >>> [1] https://github.com/apache/cxf/pull/912
>>> >>> [2] https://issues.apache.org/jira/browse/CXF-8371
>>> >>>
>>> >>> Best Regards,
>>> >>> Andriy Redko
>>> >>>
>>> >>> COh> +1 from me.
>>> >>>
>>> >>> COh> Colm.
>>> >>>
>>> >>> COh> On Thu, May 26, 2022 at 2:40
