Re: [DISCUSS] CXF 3.5.x and beyond

[Andriy Redko]

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 
JM> wrote:




>> Le ven. 3 sept. 2021 à 11:30, Jim Ma  a écrit :



>>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau 
>>> wrote:



 Le mer. 25 août 2021 à 13:39, Jim Ma  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  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  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 

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma]

Good point, Romain. We need to look at what to do to make sure all
artifacts are included and transformed if this becomes a cxf module.

BTW, Spring 6 GA  supports jakarta ee9 will come in Q4 2022 :
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

On Fri, Sep 3, 2021 at 6:20 PM Romain Manni-Bucau 
wrote:

>
>
>
> Le ven. 3 sept. 2021 à 11:30, Jim Ma  a écrit :
>
>>
>>
>> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau 
>> wrote:
>>
>>>
>>>
>>> Le mer. 25 août 2021 à 13:39, Jim Ma  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  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  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

[GitHub] [cxf] reta merged pull request #844: CXF-8588: Micrometer operation UNKNOWN for clients

[GitBox]

reta merged pull request #844:
URL: https://github.com/apache/cxf/pull/844


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] CXF 3.5.x and beyond

[Romain Manni-Bucau]

Le ven. 3 sept. 2021 à 11:30, Jim Ma  a écrit :

>
>
> On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau 
> wrote:
>
>>
>>
>> Le mer. 25 août 2021 à 13:39, Jim Ma  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  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  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  |  Blog
> RMB>  | Old Blog
> RMB>  | Github <
> https://github.com/rmannibucau> |
> RMB> LinkedIn  | Book
> RMB> <
> 

Re: [DISCUSS] CXF 3.5.x and beyond

[Jim Ma]

On Wed, Aug 25, 2021 at 9:39 PM Romain Manni-Bucau 
wrote:

>
>
> Le mer. 25 août 2021 à 13:39, Jim Ma  a écrit :
>
>>
>>
>> On Fri, Aug 20, 2021 at 2:10 PM Romain Manni-Bucau 
>> wrote:
>>
>>>
>>>
>>> Le jeu. 19 août 2021 à 22:45, Andriy Redko  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  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 ?





>
>
>> 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  |  Blog
 RMB>  | Old Blog
 RMB>  | Github <
 https://github.com/rmannibucau> |
 RMB> LinkedIn  | Book
 RMB> <
 https://www.packtpub.com/application-development/java-ee-8-high-performance
 >


 RMB> Le lun. 16 août 2021 à 23:40, Andriy Redko  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.