I already created a branch for the pre-removal and merged this osgi removal change to the main branch . For these test failures and skipped modules, I'll have a look and fill a JIRA for them after I resolve the grizzly jakarta upgrade : https://issues.apache.org/jira/browse/CXF-8716.
@Andriy Redko <drr...@gmail.com> Do you remember why we skipped the maven-plugins/wadl2java-plugin and systests/wsdl_maven/codegen ? I remembered we analyzed this before , but I can't find the discussion log. On Wed, Sep 28, 2022 at 4:30 PM Colm O hEigeartaigh <cohei...@apache.org> wrote: > Hi, > > No objection from me either. Apart from OSGi, could we make sure that > all the gaps are recorded in JIRA? > > * Test failures in cxf-rt-mp-client - > https://issues.apache.org/jira/browse/CXF-8758 > * Test failures in > cxf-systests-transports-undertow,cxf-systests-jaxws (websocket > related) - https://issues.apache.org/jira/browse/CXF-8717 > * org.apache.cxf.jms.testsuite.testcases.SoapJmsSpecTest.testGzip is > failing in the jms transport systests - JIRA? > * ./systests/container-integration/grizzly skipped - > https://issues.apache.org/jira/browse/CXF-8716 > * jaxrs systests skipped - JIRA? > * systests/wsdl_maven/codegen skipped - JIRA? > * maven-plugins/wadl2java-plugin - JIRA? > * maven-plugins/java2swagger-plugin - JIRA? > > Colm. > > On Wed, Sep 28, 2022 at 2:45 AM Andrey Redko <drr...@gmail.com> wrote: > > > > Hi Jim, > > > > No objections from my side, thank you. > > > > Best Regards, > > Andriy Redko > > > > On Tue, Sep 27, 2022, 9:31 PM Jim Ma <mail2ji...@gmail.com> wrote: > >> > >> Hi all, > >> If there is no objection, I will create a branch > "osgi-pre-removal-v4.0" to record the changes before the osgi and karaf > removal, then > >> merge the this PR https://github.com/apache/cxf/pull/999 to the main > branch. > >> > >> Thanks, > >> Jim > >> > >> On Thu, Sep 22, 2022 at 9:06 PM Andrey Redko <drr...@gmail.com> wrote: > >>> > >>> This is great, thanks Jim, I will also take a look shortly. Thanks! > >>> > >>> Best Regards, > >>> Andriy Redko > >>> > >>> On Wed, Sep 21, 2022, 1:02 AM Jim Ma <mail2ji...@gmail.com> wrote: > >>>> > >>>> Hi All, > >>>> I tried to remove the osgi and karaf from CXF with this draft PR : > https://github.com/apache/cxf/pull/999. > >>>> This mainly removed the osgi code,test, examples and dependency, but > for some class like SpringBus which deeply coupled with osgi: > >>>> > https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java#L133-L142 > >>>> I added the comment "//uncomment this when osgi comes back" to mark > these commented lines for osgi. With the branch created before > >>>> this change is merged to main, I am sure this will make it easy to > bring the osgi and karaf back when the Jakarta support is ready in the > future. > >>>> > >>>> Please help review this PR. If you have any comment or question, > please let me know. > >>>> > >>>> Thanks, > >>>> Jim > >>>> > >>>> > >>>> On Sat, Sep 10, 2022 at 4:05 AM Andriy Redko <drr...@gmail.com> > wrote: > >>>>> > >>>>> Hi Jim, > >>>>> > >>>>> That is correct, I am working on > https://issues.apache.org/jira/browse/CXF-8717 as part of > >>>>> Jetty 11 migration, the Atmosphere implementation seems to be fine. > Thanks. > >>>>> > >>>>> Best Regards, > >>>>> Andriy Redko > >>>>> > >>>>> > >>>>> JM> Thanks for the update, Andiry. You already did a lot of work on > third party > >>>>> JM> jakarta support ! > >>>>> > >>>>> JM> Just to understand the CXF Jakarta support work status, are > these issues we > >>>>> JM> can start without waiting for the dependency release ? > >>>>> JM> https://issues.apache.org/jira/browse/CXF-8716 > >>>>> JM> https://issues.apache.org/jira/browse/CXF-8717 > >>>>> JM> https://issues.apache.org/jira/browse/CXF-8719 > >>>>> > >>>>> > >>>>> > >>>>> JM> On Thu, Sep 8, 2022 at 8:04 PM Andriy Redko <drr...@gmail.com> > wrote: > >>>>> > >>>>> >> Hi Jim, > >>>>> >> > >>>>> >> Yeah, we may need some time, I am also finalizing work on the > Wiremock ( > >>>>> >> https://github.com/wiremock/wiremock/pull/1942), > >>>>> >> we use it in tests extensively. One of the largest efforts is > migration to > >>>>> >> Jetty 11, I have started on that already but > >>>>> >> have difficulties with WebSockets migration, it needs rework and > that is > >>>>> >> my focus at the moment. The Swagger 1.x we have > >>>>> >> to drop I believe, I don't see roadmap on Jakarta support there. > >>>>> >> > >>>>> >> Thanks! > >>>>> >> > >>>>> >> Best Regards, > >>>>> >> Andriy Redko > >>>>> >> > >>>>> >> JM> Hi Andriy, > >>>>> >> JM> It looks like we still have to wait for the other dependency > jakarta > >>>>> >> JM> support available, like brave's new release to include this > change : > >>>>> >> JM> https://github.com/openzipkin/brave/pull/1344. Do you see > any other > >>>>> >> JM> dependencies that haven't been released yet except OSGI and > Karaf ? > >>>>> >> > >>>>> >> JM> Thanks, > >>>>> >> JM> Jim > >>>>> >> > >>>>> >> > >>>>> >> JM> On Wed, Sep 7, 2022 at 8:11 PM Jim Ma <mail2ji...@gmail.com> > wrote: > >>>>> >> > >>>>> >> >> Thanks for the informative input, Freeman. > >>>>> >> >> IMO, If we want to decouple OSGI/Karaf, the 4.0 major release > is a good > >>>>> >> >> chance to do this job. When OSGI/Karaf jakarta release is > ready, > >>>>> >> >> We can look at bringing this back with more improvement and > refactor > >>>>> >> work > >>>>> >> >> to make it loosely coupled with core code. > >>>>> >> >> > >>>>> >> >> On Wed, Sep 7, 2022 at 5:34 AM Freeman Fang < > freeman.f...@gmail.com> > >>>>> >> >> 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 <mail2ji...@gmail.com> > 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 < > drr...@gmail.com> > >>>>> >> 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 < > mail2ji...@gmail.com> > >>>>> >> >>>>> wrote: > >>>>> >> >>>>> > >>>>> >> >>>>> >> Thanks Andriy too for driving this and moving forward ! > >>>>> >> >>>>> >> > >>>>> >> >>>>> >> On Tue, Jun 21, 2022 at 9:49 AM Andriy Redko < > drr...@gmail.com> > >>>>> >> >>>>> 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 AM Jim Ma < > >>>>> >> mail2ji...@gmail.com> > >>>>> >> >>>>> wrote: > >>>>> >> >>>>> >>> >> > >>>>> >> >>>>> >>> >> Hi Andriy, > >>>>> >> >>>>> >>> >> A good plan. I agree with all these changes and > support > >>>>> >> versions. > >>>>> >> >>>>> >>> >> > >>>>> >> >>>>> >>> >> Thanks, > >>>>> >> >>>>> >>> >> Jim > >>>>> >> >>>>> >>> >> > >>>>> >> >>>>> >>> >> On Mon, May 23, 2022 at 12:45 AM Andriy Redko < > >>>>> >> drr...@gmail.com> > >>>>> >> >>>>> >>> wrote: > >>>>> >> >>>>> >>> >> > >>>>> >> >>>>> >>> >> > Hey folks, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > While the work on 4.x / Jakarta is slowly but > steadily > >>>>> >> moving > >>>>> >> >>>>> >>> forward, it > >>>>> >> >>>>> >>> >> > is > >>>>> >> >>>>> >>> >> > time to think about next 3.x release line. As we > discussed > >>>>> >> in > >>>>> >> >>>>> this > >>>>> >> >>>>> >>> thread, > >>>>> >> >>>>> >>> >> > it > >>>>> >> >>>>> >>> >> > seems we agreed on 3.6.x to be next javax.* based > release, > >>>>> >> with > >>>>> >> >>>>> >>> JDK-11 as > >>>>> >> >>>>> >>> >> > the > >>>>> >> >>>>> >>> >> > baseline. We have new Spring Boot 2.7.0 just > released [1], > >>>>> >> >>>>> along > >>>>> >> >>>>> >>> with tons > >>>>> >> >>>>> >>> >> > of other > >>>>> >> >>>>> >>> >> > related projects. I would like to propose to: > >>>>> >> >>>>> >>> >> > - branch off 3.6.x-fixes (from master) and work > on upgrades > >>>>> >> >>>>> (+ some > >>>>> >> >>>>> >>> new > >>>>> >> >>>>> >>> >> > features) > >>>>> >> >>>>> >>> >> > - as per @Jim suggestion, merge (very soon) > Jakarta branch > >>>>> >> >>>>> [2] into > >>>>> >> >>>>> >>> master > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > From the support perspective, it means we would > need to > >>>>> >> >>>>> maintain > >>>>> >> >>>>> >>> 3.4.x for > >>>>> >> >>>>> >>> >> > some > >>>>> >> >>>>> >>> >> > time, plus 3.5.x, 3.6.x and 4.0.0 (when released > at some > >>>>> >> >>>>> point). > >>>>> >> >>>>> >>> What do > >>>>> >> >>>>> >>> >> > you > >>>>> >> >>>>> >>> >> > think guys? Thank you! > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > [1] > >>>>> >> >>>>> >>> > >>>>> >> https://spring.io/blog/2022/05/19/spring-boot-2-7-0-available-now > >>>>> >> >>>>> >>> >> > [2] https://github.com/apache/cxf/pull/912 > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > Best Regards, > >>>>> >> >>>>> >>> >> > Andriy Redko > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > JM> Hi Andriy, > >>>>> >> >>>>> >>> >> > JM> I took some time to look at the CXF java11 > support and > >>>>> >> >>>>> spring > >>>>> >> >>>>> >>> >> > decoupling > >>>>> >> >>>>> >>> >> > JM> last week. > >>>>> >> >>>>> >>> >> > JM> Here are some thoughts and initial work: > >>>>> >> >>>>> >>> >> > JM> 1) Use cross compile to support java11 . We > can simply > >>>>> >> >>>>> change > >>>>> >> >>>>> >>> >> > JM> <cxf.jdk.version> in pom.xml to 11. > >>>>> >> >>>>> >>> >> > JM> This will allow the maven compiler plugin > to build > >>>>> >> cxf > >>>>> >> >>>>> with > >>>>> >> >>>>> >>> java11. > >>>>> >> >>>>> >>> >> > JM> 2) We can look at creating some separate > modules for > >>>>> >> Spring > >>>>> >> >>>>> >>> relevant > >>>>> >> >>>>> >>> >> > JM> code/configuration in the future. Ideally a > small > >>>>> >> >>>>> >>> >> > JM> number of modules would be better and it will > make it > >>>>> >> >>>>> easy for > >>>>> >> >>>>> >>> users > >>>>> >> >>>>> >>> >> > to > >>>>> >> >>>>> >>> >> > JM> import spring relevant dependencies. > >>>>> >> >>>>> >>> >> > JM> Here is my initial work : > >>>>> >> >>>>> >>> >> > https://github.com/jimma/cxf/commits/spring > >>>>> >> >>>>> >>> >> > JM> <https://github.com/jimma/cxf/commits/spring>. > This > >>>>> >> only > >>>>> >> >>>>> touches > >>>>> >> >>>>> >>> >> > several > >>>>> >> >>>>> >>> >> > JM> cxf modules, I am not > >>>>> >> >>>>> >>> >> > JM> sure if this approach will get other blockers > and > >>>>> >> issues. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > JM> Thanks, > >>>>> >> >>>>> >>> >> > JM> Jim > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > JM> On Sun, Jan 30, 2022 at 12:55 AM Andriy Redko < > >>>>> >> >>>>> drr...@gmail.com> > >>>>> >> >>>>> >>> >> > wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> Hey Jim, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> AFAIR this particular topic has popped up > several times, > >>>>> >> a > >>>>> >> >>>>> few > >>>>> >> >>>>> >>> issues > >>>>> >> >>>>> >>> >> > >> exist [1] and > >>>>> >> >>>>> >>> >> > >> @Christian even did the POC several years ago > [2] in > >>>>> >> >>>>> attempt to > >>>>> >> >>>>> >>> remove > >>>>> >> >>>>> >>> >> > >> some of the > >>>>> >> >>>>> >>> >> > >> hard Spring dependencies (I don't know the > outcomes to be > >>>>> >> >>>>> fair > >>>>> >> >>>>> >>> but I > >>>>> >> >>>>> >>> >> > >> suspect it turned > >>>>> >> >>>>> >>> >> > >> out to be much more difficult than anticipated). > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> The suggestion I have in mind is to keep JDK-17 > baseline > >>>>> >> >>>>> **for > >>>>> >> >>>>> >>> now** and > >>>>> >> >>>>> >>> >> > >> continue working > >>>>> >> >>>>> >>> >> > >> on addressing the blockers (there too many at > this > >>>>> >> point). > >>>>> >> >>>>> Once > >>>>> >> >>>>> >>> we get > >>>>> >> >>>>> >>> >> > to > >>>>> >> >>>>> >>> >> > >> the state when > >>>>> >> >>>>> >>> >> > >> the Jakarta branch is at least buildable / > deployable, we > >>>>> >> >>>>> could > >>>>> >> >>>>> >>> reassess > >>>>> >> >>>>> >>> >> > >> the Spring > >>>>> >> >>>>> >>> >> > >> coupling. I am just afraid doing everything at > once would > >>>>> >> >>>>> >>> introduce > >>>>> >> >>>>> >>> >> > >> instability in > >>>>> >> >>>>> >>> >> > >> codebase and slow down everyone on either of > these > >>>>> >> efforts. > >>>>> >> >>>>> Not > >>>>> >> >>>>> >>> sure if > >>>>> >> >>>>> >>> >> > >> you agree but > >>>>> >> >>>>> >>> >> > >> in any case I am definitely +1 for reducing the > scope of > >>>>> >> >>>>> >>> dependencies on > >>>>> >> >>>>> >>> >> > >> Spring, even > >>>>> >> >>>>> >>> >> > >> in 3.4.x / 3.5.x release lines. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> Thank you. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> [1] > https://issues.apache.org/jira/browse/CXF-5477 > >>>>> >> >>>>> >>> >> > >> [2] > >>>>> >> https://github.com/apache/cxf/tree/poc-remove-spring-bp > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> Best Regards, > >>>>> >> >>>>> >>> >> > >> Andriy Redko > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> JM> I accidentally clicked the send button, > please > >>>>> >> ignore > >>>>> >> >>>>> my > >>>>> >> >>>>> >>> previous > >>>>> >> >>>>> >>> >> > >> email > >>>>> >> >>>>> >>> >> > >> JM> and look at this reply. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> JM> On Sat, Jan 29, 2022 at 7:58 PM Jim Ma < > >>>>> >> >>>>> mail2ji...@gmail.com> > >>>>> >> >>>>> >>> >> > wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >> On Mon, Dec 27, 2021 at 10:49 PM Andriy > Redko < > >>>>> >> >>>>> >>> drr...@gmail.com> > >>>>> >> >>>>> >>> >> > wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> Hey guys, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> A bunch of good things have happened at the > end of > >>>>> >> this > >>>>> >> >>>>> year. > >>>>> >> >>>>> >>> The > >>>>> >> >>>>> >>> >> > 3.5.0 > >>>>> >> >>>>> >>> >> > >> >>> out and we are in a good > >>>>> >> >>>>> >>> >> > >> >>> shape to kick off Jakarta support: the > Spring 6 > >>>>> >> >>>>> milestones and > >>>>> >> >>>>> >>> >> > Spring > >>>>> >> >>>>> >>> >> > >> >>> Boot 3 snapshots are already > >>>>> >> >>>>> >>> >> > >> >>> available. There are tons of things to fix > and > >>>>> >> address, > >>>>> >> >>>>> I have > >>>>> >> >>>>> >>> >> > created > >>>>> >> >>>>> >>> >> > >> >>> this draft pull request [1] > >>>>> >> >>>>> >>> >> > >> >>> with a first batch of changes and TODOs. > Everyone > >>>>> >> >>>>> should be > >>>>> >> >>>>> >>> able to > >>>>> >> >>>>> >>> >> > >> push > >>>>> >> >>>>> >>> >> > >> >>> changes in there, if not > >>>>> >> >>>>> >>> >> > >> >>> - please let me know, I could give perms / > move the > >>>>> >> >>>>> branch to > >>>>> >> >>>>> >>> CXF > >>>>> >> >>>>> >>> >> > >> Github > >>>>> >> >>>>> >>> >> > >> >>> repo. Hope in the next > >>>>> >> >>>>> >>> >> > >> >>> couple of months we get closer to fully > embrace > >>>>> >> Jakarta. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> On the not so good news side, Spring 6 has > kept > >>>>> >> JDK-17 > >>>>> >> >>>>> >>> baseline. It > >>>>> >> >>>>> >>> >> > >> does > >>>>> >> >>>>> >>> >> > >> >>> not play well with our > >>>>> >> >>>>> >>> >> > >> >>> original plan to stick to JDK-11 baseline > for 4.x > >>>>> >> but I > >>>>> >> >>>>> am > >>>>> >> >>>>> >>> not sure > >>>>> >> >>>>> >>> >> > we > >>>>> >> >>>>> >>> >> > >> >>> have any choice here besides > >>>>> >> >>>>> >>> >> > >> >>> bumping the baseline as well. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> JM> From the JakartaEE9 release[1]and > JakartaEE10 > >>>>> >> >>>>> plan[2], it > >>>>> >> >>>>> >>> still > >>>>> >> >>>>> >>> >> > >> needs to > >>>>> >> >>>>> >>> >> > >> JM> support JDK11. Jakarta Restful WebService > 3.0/3.1 > >>>>> >> and > >>>>> >> >>>>> >>> Jakarta XML > >>>>> >> >>>>> >>> >> > Web > >>>>> >> >>>>> >>> >> > >> JM> Services 3.0/3.1 > >>>>> >> >>>>> >>> >> > >> JM> apis are the specifications we need to > implement in > >>>>> >> >>>>> CXF, so > >>>>> >> >>>>> >>> we > >>>>> >> >>>>> >>> >> > need > >>>>> >> >>>>> >>> >> > >> to > >>>>> >> >>>>> >>> >> > >> JM> build, run and test implementation with > JDK11. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> JM> Just thinking this loud, is it possible > that we > >>>>> >> make > >>>>> >> >>>>> Spring > >>>>> >> >>>>> >>> >> > plugable > >>>>> >> >>>>> >>> >> > >> or > >>>>> >> >>>>> >>> >> > >> JM> really optional ? 4.x is the major release > and it's > >>>>> >> the > >>>>> >> >>>>> >>> chance > >>>>> >> >>>>> >>> >> > >> JM> to refactor CXF code(like we move spring > related > >>>>> >> >>>>> >>> source/test to > >>>>> >> >>>>> >>> >> > >> separate > >>>>> >> >>>>> >>> >> > >> JM> module) to build/run/test without Spring > with a maven > >>>>> >> >>>>> profile. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> JM> [1] > >>>>> >> >>>>> >>> >> > >> JM> > >>>>> >> >>>>> >>> >> > >> > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> > >>>>> >> >>>>> > >>>>> >> > https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan > >>>>> >> >>>>> >>> >> > >> JM> [2] > >>>>> >> >>>>> >>> >> > >> JM> > >>>>> >> >>>>> >>> >> > >> > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> > >>>>> >> >>>>> > >>>>> >> > https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> Happy Holidays guys! > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> [1] https://github.com/apache/cxf/pull/888 > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> JM> On Tue, Sep 7, 2021 at 4:56 AM Andriy > Redko < > >>>>> >> >>>>> >>> drr...@gmail.com> > >>>>> >> >>>>> >>> >> > >> wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> Hey Jim, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> No, we don't have a branch just yet, > primarily > >>>>> >> >>>>> because we > >>>>> >> >>>>> >>> depend > >>>>> >> >>>>> >>> >> > on > >>>>> >> >>>>> >>> >> > >> the > >>>>> >> >>>>> >>> >> > >> >>> >> few > >>>>> >> >>>>> >>> >> > >> >>> >> snapshots in 3.5.0/master. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> @Colm do you have an idea regarding > xmlschema > >>>>> >> 2.3.0 > >>>>> >> >>>>> release > >>>>> >> >>>>> >>> >> > >> timelines? > >>>>> >> >>>>> >>> >> > >> >>> >> @Dan do you have an idea regarding > neethi 3.2.0 > >>>>> >> >>>>> release > >>>>> >> >>>>> >>> >> > timelines? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> At worst, you could create a new branch > for this > >>>>> >> >>>>> feature, > >>>>> >> >>>>> >>> or > >>>>> >> >>>>> >>> >> > submit > >>>>> >> >>>>> >>> >> > >> a > >>>>> >> >>>>> >>> >> > >> >>> >> pull request against master which we > should be > >>>>> >> able > >>>>> >> >>>>> to > >>>>> >> >>>>> >>> re-target > >>>>> >> >>>>> >>> >> > >> later > >>>>> >> >>>>> >>> >> > >> >>> >> against the right branch (should be > easy). What do > >>>>> >> >>>>> you > >>>>> >> >>>>> >>> think? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> JM> This is a good idea. I'll send a PR > against the > >>>>> >> >>>>> master, > >>>>> >> >>>>> >>> and > >>>>> >> >>>>> >>> >> > later > >>>>> >> >>>>> >>> >> > >> we > >>>>> >> >>>>> >>> >> > >> >>> can > >>>>> >> >>>>> >>> >> > >> >>> JM> decide the place to merge. > >>>>> >> >>>>> >>> >> > >> >>> JM> Thanks, Andriy. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> Best Regards, > >>>>> >> >>>>> >>> >> > >> >>> >> Andriy Redko > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> JM> Thanks for more updates , Andriy. > >>>>> >> >>>>> >>> >> > >> >>> >> JM> Is there a place/workspace branch, > I can > >>>>> >> send a > >>>>> >> >>>>> PR > >>>>> >> >>>>> >>> for this > >>>>> >> >>>>> >>> >> > >> >>> change? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> JM> On Fri, Sep 3, 2021 at 9:20 PM > Andriy Redko < > >>>>> >> >>>>> >>> >> > drr...@gmail.com> > >>>>> >> >>>>> >>> >> > >> >>> wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> Hey Jim, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> Thanks a lot for taking the lead on > this one. > >>>>> >> >>>>> Just want > >>>>> >> >>>>> >>> to > >>>>> >> >>>>> >>> >> > chime > >>>>> >> >>>>> >>> >> > >> in > >>>>> >> >>>>> >>> >> > >> >>> on a > >>>>> >> >>>>> >>> >> > >> >>> >> >> few points. Indeed, as > >>>>> >> >>>>> >>> >> > >> >>> >> >> per previous discussion in this > thread, it > >>>>> >> seems > >>>>> >> >>>>> like > >>>>> >> >>>>> >>> it make > >>>>> >> >>>>> >>> >> > >> sense > >>>>> >> >>>>> >>> >> > >> >>> to > >>>>> >> >>>>> >>> >> > >> >>> >> >> provide only the subset > >>>>> >> >>>>> >>> >> > >> >>> >> >> of shaded modules with Jakarta > namespace. Also, > >>>>> >> >>>>> it was > >>>>> >> >>>>> >>> >> > confirmed > >>>>> >> >>>>> >>> >> > >> >>> >> yesterday > >>>>> >> >>>>> >>> >> > >> >>> >> >> that Spring Framework > >>>>> >> >>>>> >>> >> > >> >>> >> >> 6 milestones will be available in > November this > >>>>> >> >>>>> year > >>>>> >> >>>>> >>> but the > >>>>> >> >>>>> >>> >> > >> first > >>>>> >> >>>>> >>> >> > >> >>> >> >> snapshots will be out in late > >>>>> >> >>>>> >>> >> > >> >>> >> >> September / early October, looks > pretty > >>>>> >> >>>>> promising. One > >>>>> >> >>>>> >>> >> > >> >>> **unexpected** > >>>>> >> >>>>> >>> >> > >> >>> >> part > >>>>> >> >>>>> >>> >> > >> >>> >> >> of the announcement > >>>>> >> >>>>> >>> >> > >> >>> >> >> is JDK17 baseline for Spring > Framework & Co, > >>>>> >> that > >>>>> >> >>>>> could > >>>>> >> >>>>> >>> be a > >>>>> >> >>>>> >>> >> > >> bummer > >>>>> >> >>>>> >>> >> > >> >>> but > >>>>> >> >>>>> >>> >> > >> >>> >> I > >>>>> >> >>>>> >>> >> > >> >>> >> >> have the feeling that > >>>>> >> >>>>> >>> >> > >> >>> >> >> it will be lowered to JDK11. Thank > you. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> Best Regards, > >>>>> >> >>>>> >>> >> > >> >>> >> >> Andriy Redko > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> Good point, Romain. We need to > look at what > >>>>> >> >>>>> to do > >>>>> >> >>>>> >>> to make > >>>>> >> >>>>> >>> >> > >> sure > >>>>> >> >>>>> >>> >> > >> >>> all > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> artifacts are included and > transformed if > >>>>> >> this > >>>>> >> >>>>> >>> becomes a > >>>>> >> >>>>> >>> >> > cxf > >>>>> >> >>>>> >>> >> > >> >>> module. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> BTW, Spring 6 GA supports > jakarta ee9 will > >>>>> >> >>>>> come in > >>>>> >> >>>>> >>> Q4 > >>>>> >> >>>>> >>> >> > 2022 : > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> > >>>>> >> >>>>> >>> >> > >> >>> >> >> > >>>>> >> >>>>> >>> >> > >> >>> >> > >>>>> >> >>>>> >>> >> > >> >>> > >>>>> >> >>>>> >>> >> > >> > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> > >>>>> >> >>>>> > >>>>> >> > https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6 > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> On Fri, Sep 3, 2021 at 6:20 PM > Romain > >>>>> >> >>>>> Manni-Bucau < > >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com> > >>>>> >> >>>>> >>> >> > >> >>> >> >> JM> wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> Le ven. 3 sept. 2021 à 11:30, Jim > Ma < > >>>>> >> >>>>> >>> mail2ji...@gmail.com> > >>>>> >> >>>>> >>> >> > a > >>>>> >> >>>>> >>> >> > >> >>> écrit > >>>>> >> >>>>> >>> >> > >> >>> >> : > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> On Wed, Aug 25, 2021 at 9:39 PM > Romain > >>>>> >> >>>>> Manni-Bucau < > >>>>> >> >>>>> >>> >> > >> >>> >> >> rmannibu...@gmail.com> > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Le mer. 25 août 2021 à 13:39, > Jim Ma < > >>>>> >> >>>>> >>> >> > mail2ji...@gmail.com> > >>>>> >> >>>>> >>> >> > >> a > >>>>> >> >>>>> >>> >> > >> >>> >> écrit : > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> On Fri, Aug 20, 2021 at 2:10 PM > Romain > >>>>> >> >>>>> >>> Manni-Bucau < > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> rmannibu...@gmail.com> wrote: > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Le jeu. 19 août 2021 à 22:45, > Andriy > >>>>> >> Redko > >>>>> >> >>>>> < > >>>>> >> >>>>> >>> >> > >> drr...@gmail.com> > >>>>> >> >>>>> >>> >> > >> >>> a > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> écrit : > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Hi Romain, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Sorry for the delayed > response. I have > >>>>> >> >>>>> been > >>>>> >> >>>>> >>> thinking > >>>>> >> >>>>> >>> >> > >> about > >>>>> >> >>>>> >>> >> > >> >>> your > >>>>> >> >>>>> >>> >> > >> >>> >> >> (and > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Jim) suggestions > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> and came to surprising > conclusion: do > >>>>> >> we > >>>>> >> >>>>> >>> actually > >>>>> >> >>>>> >>> >> > need to > >>>>> >> >>>>> >>> >> > >> >>> >> >> officially > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> release anything > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> to shade/overwrite javax <-> > jakarta? > >>>>> >> >>>>> >>> Generally, we > >>>>> >> >>>>> >>> >> > could > >>>>> >> >>>>> >>> >> > >> >>> shade > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Spring or/and any other > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> dependency but we would > certainly not > >>>>> >> >>>>> bundle it > >>>>> >> >>>>> >>> as > >>>>> >> >>>>> >>> >> > part > >>>>> >> >>>>> >>> >> > >> of > >>>>> >> >>>>> >>> >> > >> >>> CXF > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> distribution (I hope you > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> would agree), so not really > useful > >>>>> >> unless > >>>>> >> >>>>> we > >>>>> >> >>>>> >>> publish > >>>>> >> >>>>> >>> >> > >> them. > >>>>> >> >>>>> >>> >> > >> >>> As > >>>>> >> >>>>> >>> >> > >> >>> >> such, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> probably the best > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> interim solution is to > document what it > >>>>> >> >>>>> takes > >>>>> >> >>>>> >>> to shade > >>>>> >> >>>>> >>> >> > >> CXF > >>>>> >> >>>>> >>> >> > >> >>> >> (javax > >>>>> >> >>>>> >>> >> > >> >>> >> >> <-> > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta) and let > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> the end users > (application/service > >>>>> >> >>>>> developers) > >>>>> >> >>>>> >>> use > >>>>> >> >>>>> >>> >> > that > >>>>> >> >>>>> >>> >> > >> when > >>>>> >> >>>>> >>> >> > >> >>> >> >> needed? > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> In this case > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> basically CXF, Spring, > Geronimo, > >>>>> >> Swagger, > >>>>> >> >>>>> ... > >>>>> >> >>>>> >>> would > >>>>> >> >>>>> >>> >> > >> follow > >>>>> >> >>>>> >>> >> > >> >>> the > >>>>> >> >>>>> >>> >> > >> >>> >> same > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> shading rules. At > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> least, we could start with > that > >>>>> >> >>>>> (documenting the > >>>>> >> >>>>> >>> >> > shading > >>>>> >> >>>>> >>> >> > >> >>> >> process) > >>>>> >> >>>>> >>> >> > >> >>> >> >> and > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> likely get some > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> early feedback while working > on > >>>>> >> >>>>> full-fledged > >>>>> >> >>>>> >>> support? > >>>>> >> >>>>> >>> >> > >> WDYT? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> This is what is done and makes > it hard > >>>>> >> for > >>>>> >> >>>>> >>> nothing to > >>>>> >> >>>>> >>> >> > >> >>> >> maintain/fix - > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> dont even look at tomee > solution for > >>>>> >> >>>>> shading > >>>>> >> >>>>> >>> please ;) > >>>>> >> >>>>> >>> >> > - > >>>>> >> >>>>> >>> >> > >> >>> IMHO. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> Being said it costs nothing to > cxf to > >>>>> >> >>>>> produce > >>>>> >> >>>>> >>> jakarta > >>>>> >> >>>>> >>> >> > >> jars, > >>>>> >> >>>>> >>> >> > >> >>> that > >>>>> >> >>>>> >>> >> > >> >>> >> it > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> makes it ee 9 compliant and > more > >>>>> >> >>>>> consistent for > >>>>> >> >>>>> >>> all but > >>>>> >> >>>>> >>> >> > >> >>> spring > >>>>> >> >>>>> >>> >> > >> >>> >> >> usage (ee > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> integrators, plain tomcat 10 > users > >>>>> >> >>>>> etc...), I > >>>>> >> >>>>> >>> think it > >>>>> >> >>>>> >>> >> > is > >>>>> >> >>>>> >>> >> > >> >>> worth > >>>>> >> >>>>> >>> >> > >> >>> >> >> doing it, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> at minimum. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> At least a jakarta jaxrs (over > jakarta > >>>>> >> >>>>> servlet) > >>>>> >> >>>>> >>> bundle > >>>>> >> >>>>> >>> >> > >> would > >>>>> >> >>>>> >>> >> > >> >>> be a > >>>>> >> >>>>> >>> >> > >> >>> >> >> good > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> progress, not sure jaxws and > other parts > >>>>> >> >>>>> would be > >>>>> >> >>>>> >>> >> > helpful > >>>>> >> >>>>> >>> >> > >> >>> since > >>>>> >> >>>>> >>> >> > >> >>> >> >> they tend > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> to be in maintainance mode > from what I > >>>>> >> saw. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> So IMHO the best is a > shade/relocation > >>>>> >> in > >>>>> >> >>>>> the > >>>>> >> >>>>> >>> parent to > >>>>> >> >>>>> >>> >> > >> >>> deliver a > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> jakarta artifact for all > module + a few > >>>>> >> >>>>> jakarta > >>>>> >> >>>>> >>> bom. > >>>>> >> >>>>> >>> >> > But > >>>>> >> >>>>> >>> >> > >> if > >>>>> >> >>>>> >>> >> > >> >>> too > >>>>> >> >>>>> >>> >> > >> >>> >> >> much - > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>> which I can see/hear - a > jakarta jaxrs > >>>>> >> >>>>> bundle > >>>>> >> >>>>> >>> would > >>>>> >> >>>>> >>> >> > work > >>>>> >> >>>>> >>> >> > >> too > >>>>> >> >>>>> >>> >> > >> >>> >> short > >>>>> >> >>>>> >>> >> > >> >>> >> >> term. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> I agree to start with something > to > >>>>> >> preview > >>>>> >> >>>>> and > >>>>> >> >>>>> >>> collect > >>>>> >> >>>>> >>> >> > more > >>>>> >> >>>>> >>> >> > >> >>> ideas > >>>>> >> >>>>> >>> >> > >> >>> >> to > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> support ee9. It's good to have > a branch > >>>>> >> to > >>>>> >> >>>>> really > >>>>> >> >>>>> >>> start > >>>>> >> >>>>> >>> >> > >> >>> something > >>>>> >> >>>>> >>> >> > >> >>> >> >> for this > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> topic. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> @Romain, do you have a > prototype with > >>>>> >> >>>>> shading or > >>>>> >> >>>>> >>> other > >>>>> >> >>>>> >>> >> > >> tools > >>>>> >> >>>>> >>> >> > >> >>> for a > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> jakarta jaxrs bundle or just > some basic > >>>>> >> >>>>> idea that > >>>>> >> >>>>> >>> we can > >>>>> >> >>>>> >>> >> > >> have > >>>>> >> >>>>> >>> >> > >> >>> a > >>>>> >> >>>>> >>> >> > >> >>> >> look > >>>>> >> >>>>> >>> >> > >> >>> >> >> at ? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> Not ready for cxf but looking at > >>>>> >> >>>>> meecrowave-core > >>>>> >> >>>>> >>> pom you > >>>>> >> >>>>> >>> >> > >> would > >>>>> >> >>>>> >>> >> > >> >>> have > >>>>> >> >>>>> >>> >> > >> >>> >> >> some > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> idea. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> I just suspect pom deps need some > >>>>> >> refinement > >>>>> >> >>>>> like > >>>>> >> >>>>> >>> >> > >> with/without > >>>>> >> >>>>> >>> >> > >> >>> the > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>> client (it is useless with java > 11 now and > >>>>> >> >>>>> less > >>>>> >> >>>>> >>> and less > >>>>> >> >>>>> >>> >> > >> >>> desired > >>>>> >> >>>>> >>> >> > >> >>> >> >> AFAIK). > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> @Romain Manni-Bucau < > >>>>> >> rmannibu...@gmail.com> > >>>>> >> >>>>> >>> Thanks for > >>>>> >> >>>>> >>> >> > the > >>>>> >> >>>>> >>> >> > >> >>> >> update. I > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> looked at the meecrowave-core pom > and > >>>>> >> >>>>> understood > >>>>> >> >>>>> >>> how it > >>>>> >> >>>>> >>> >> > >> >>> transforms > >>>>> >> >>>>> >>> >> > >> >>> >> >> package > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> names with the shade plugin. > Both shade > >>>>> >> >>>>> plugin or > >>>>> >> >>>>> >>> eclipse > >>>>> >> >>>>> >>> >> > >> >>> >> transformer > >>>>> >> >>>>> >>> >> > >> >>> >> >> tool > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> works for this purpose . > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> I created one prototype project > which pulls > >>>>> >> >>>>> in cxf > >>>>> >> >>>>> >>> >> > >> dependencies, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> transforms to jakarta namespace > and > >>>>> >> installs > >>>>> >> >>>>> to > >>>>> >> >>>>> >>> local > >>>>> >> >>>>> >>> >> > maven > >>>>> >> >>>>> >>> >> > >> >>> >> >> repository : > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> > >>>>> >> https://github.com/jimma/cxf-ee9-transformer > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> This doesn't need more effort and > no need > >>>>> >> the > >>>>> >> >>>>> >>> >> > code/dependency > >>>>> >> >>>>> >>> >> > >> >>> change > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> which breaks/mixes with javax > support > >>>>> >> >>>>> codebase. It > >>>>> >> >>>>> >>> can be > >>>>> >> >>>>> >>> >> > >> simply > >>>>> >> >>>>> >>> >> > >> >>> >> added > >>>>> >> >>>>> >>> >> > >> >>> >> >> with > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> another maven module in cxf repo > to produce > >>>>> >> >>>>> >>> transformed > >>>>> >> >>>>> >>> >> > >> jakata > >>>>> >> >>>>> >>> >> > >> >>> cxf > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>> artifacts or binary > distribution. Your > >>>>> >> >>>>> thoughts ? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> If not all artifacts are proposed > with > >>>>> >> jakarta > >>>>> >> >>>>> >>> support it > >>>>> >> >>>>> >>> >> > is > >>>>> >> >>>>> >>> >> > >> an > >>>>> >> >>>>> >>> >> > >> >>> >> option > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> otherwise it would need a build > module to > >>>>> >> >>>>> >>> synchronize this > >>>>> >> >>>>> >>> >> > >> >>> >> submodule(s) > >>>>> >> >>>>> >>> >> > >> >>> >> >> to > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> ensure none are forgotten - this > is where I > >>>>> >> >>>>> prefer > >>>>> >> >>>>> >>> the > >>>>> >> >>>>> >>> >> > >> classifier > >>>>> >> >>>>> >>> >> > >> >>> >> >> approach > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> even if it has this exclusion > pitfalls - but > >>>>> >> >>>>> cxf has > >>>>> >> >>>>> >>> it > >>>>> >> >>>>> >>> >> > anyway > >>>>> >> >>>>> >>> >> > >> >>> due to > >>>>> >> >>>>> >>> >> > >> >>> >> >> its > >>>>> >> >>>>> >>> >> > >> >>> >> >> >> transitive dependencies so not > worse IMHO > >>>>> >> ;). > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Thanks, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>> Jim > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Thank you. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Best Regards, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> Andriy Redko > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> I'm not sure I see why > you need > >>>>> >> >>>>> spring to > >>>>> >> >>>>> >>> start > >>>>> >> >>>>> >>> >> > this > >>>>> >> >>>>> >>> >> > >> >>> work. > >>>>> >> >>>>> >>> >> > >> >>> >> The > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> expected is > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> there already so spring > module can > >>>>> >> >>>>> still > >>>>> >> >>>>> >>> rely on > >>>>> >> >>>>> >>> >> > >> >>> javax, be > >>>>> >> >>>>> >>> >> > >> >>> >> >> made > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> jakarta > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> friendly using shade > plugin or > >>>>> >> alike > >>>>> >> >>>>> and > >>>>> >> >>>>> >>> that's > >>>>> >> >>>>> >>> >> > it > >>>>> >> >>>>> >>> >> > >> >>> until a > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> spring native > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> integration is there. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> Worse case cxf-spring > will not be > >>>>> >> >>>>> usable > >>>>> >> >>>>> >>> with > >>>>> >> >>>>> >>> >> > >> jakarta - > >>>>> >> >>>>> >>> >> > >> >>> >> which > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> still enabled > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> all other usages, best > case if > >>>>> >> spring > >>>>> >> >>>>> >>> makes the > >>>>> >> >>>>> >>> >> > >> >>> transition > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> smooth is that > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> it will work smoothly > without more > >>>>> >> >>>>> >>> investment > >>>>> >> >>>>> >>> >> > than > >>>>> >> >>>>> >>> >> > >> for > >>>>> >> >>>>> >>> >> > >> >>> the > >>>>> >> >>>>> >>> >> > >> >>> >> >> rest > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> of the > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> build. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> The pro of that options > is that it > >>>>> >> >>>>> will > >>>>> >> >>>>> >>> reduce > >>>>> >> >>>>> >>> >> > the > >>>>> >> >>>>> >>> >> > >> >>> number > >>>>> >> >>>>> >>> >> > >> >>> >> of > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> unofficial cxf > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> RMB> relocations sooner 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. 16 août 2021 à > 23:40, > >>>>> >> Andriy > >>>>> >> >>>>> Redko > >>>>> >> >>>>> >>> < > >>>>> >> >>>>> >>> >> > >> >>> >> drr...@gmail.com> > >>>>> >> >>>>> >>> >> > >> >>> >> >> a > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> écrit : > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Hi Jim, > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> I will try to answer your > questions, > >>>>> >> >>>>> other > >>>>> >> >>>>> >>> guys > >>>>> >> >>>>> >>> >> > will > >>>>> >> >>>>> >>> >> > >> >>> >> definitely > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> share more > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> thoughts, please see mine > inlined. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> What's the task for > JDK-17 LTS > >>>>> >> >>>>> >>> preparation ? > >>>>> >> >>>>> >>> >> > Do we > >>>>> >> >>>>> >>> >> > >> >>> need > >>>>> >> >>>>> >>> >> > >> >>> >> to > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> build 3.5.0 with JDK-17 ? > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Build + All tests are > green. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Apache Karaf 4.3.3 will > support > >>>>> >> JDK17 > >>>>> >> >>>>> so our > >>>>> >> >>>>> >>> OSGi > >>>>> >> >>>>> >>> >> > test > >>>>> >> >>>>> >>> >> > >> >>> suites > >>>>> >> >>>>> >>> >> > >> >>> >> >> will > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> pass. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Besides that, there is > still some > >>>>> >> work > >>>>> >> >>>>> to do > >>>>> >> >>>>> >>> [1] > >>>>> >> >>>>> >>> >> > but > >>>>> >> >>>>> >>> >> > >> at > >>>>> >> >>>>> >>> >> > >> >>> >> least we > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> workarounds. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> For Jakarta ee9 support > branch > >>>>> >> 4.x > >>>>> >> >>>>> with > >>>>> >> >>>>> >>> source > >>>>> >> >>>>> >>> >> > code > >>>>> >> >>>>> >>> >> > >> >>> >> change to > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> support > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> jakarta namespace , we > have to wait > >>>>> >> for > >>>>> >> >>>>> >>> spring and > >>>>> >> >>>>> >>> >> > >> other > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> third party > dependencies jakarta > >>>>> >> ee9 > >>>>> >> >>>>> >>> ready. > >>>>> >> >>>>> >>> >> > Now we > >>>>> >> >>>>> >>> >> > >> >>> don't > >>>>> >> >>>>> >>> >> > >> >>> >> >> know > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> when > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> these dependencies are all > ready and > >>>>> >> >>>>> we can > >>>>> >> >>>>> >>> start > >>>>> >> >>>>> >>> >> > this > >>>>> >> >>>>> >>> >> > >> >>> work. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> This is correct, the > earliest we > >>>>> >> could > >>>>> >> >>>>> expect > >>>>> >> >>>>> >>> >> > >> something > >>>>> >> >>>>> >>> >> > >> >>> is > >>>>> >> >>>>> >>> >> > >> >>> >> >> Q4/2021 > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> (fe > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Spring). > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> Given there is no > features added > >>>>> >> in > >>>>> >> >>>>> >>> Jakarta ee > >>>>> >> >>>>> >>> >> > 9.1 > >>>>> >> >>>>> >>> >> > >> >>> besides > >>>>> >> >>>>> >>> >> > >> >>> >> >> the > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> namespace change, we can > provide the > >>>>> >> >>>>> jakarta > >>>>> >> >>>>> >>> >> > calssfier > >>>>> >> >>>>> >>> >> > >> >>> maven > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> artifacts > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> and binary release in > 3.6.x or > >>>>> >> 4.x > >>>>> >> >>>>> with > >>>>> >> >>>>> >>> >> > >> >>> transformation or > >>>>> >> >>>>> >>> >> > >> >>> >> >> other > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> better > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> approach will be enough.We > provide > >>>>> >> >>>>> jakarta > >>>>> >> >>>>> >>> ee9 > >>>>> >> >>>>> >>> >> > support > >>>>> >> >>>>> >>> >> > >> >>> early, > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> >> then we can get more > feedback on > >>>>> >> >>>>> this > >>>>> >> >>>>> >>> topic. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> It is definitely the > option we have > >>>>> >> >>>>> among > >>>>> >> >>>>> >>> others to > >>>>> >> >>>>> >>> >> > >> >>> discuss. > >>>>> >> >>>>> >>> >> > >> >>> >> I > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> have no > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> doubts that everyone has > rough idea > >>>>> >> of > >>>>> >> >>>>> the > >>>>> >> >>>>> >>> pros and > >>>>> >> >>>>> >>> >> > >> cons > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> each option has, as the > team we are > >>>>> >> >>>>> trying > >>>>> >> >>>>> >>> to pick > >>>>> >> >>>>> >>> >> > the > >>>>> >> >>>>> >>> >> > >> >>> best > >>>>> >> >>>>> >>> >> > >> >>> >> path > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> forward. > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Jakarta EE 10 is coming in > Q1/2022 > >>>>> >> >>>>> [2], we > >>>>> >> >>>>> >>> should > >>>>> >> >>>>> >>> >> > >> keep it > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> in mind as well. > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> Thank you! > >>>>> >> >>>>> >>> >> > > >>>>> >> >>>>> >>> >> > >> >>> >> >> >>>>>>> >> [1] > >>>>> >> >>>>> >>> >
