build time filtering? same amount of module physically in the source tree but let say we have a module "jaxrs" then central would see:
- jaxrs (full) - jaxrs-core (name is bad but you get it) - jaxrs-spring - jaxrs-blueprint Did it for [jcs] jcache module to include or not cdi with success (from one module i deploy the bundle, the cdi only part, the "not cdi" part) Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-09-23 15:47 GMT+02:00 Sergey Beryozkin <[email protected]>: > That would bring unwanted dependencies to either JAX-WS or JAX-RS > frontends - example, JAX-WS Spring extends non-Spring JAX-WS. Etc > > Sergey > On 23/09/16 14:44, Romain Manni-Bucau wrote: > >> why not having a cxf-spring, cxf-blueprint etc... with everything? >> Shouldnt >> be a big deal to activate the integration only if classes are there no? >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2016-09-23 15:38 GMT+02:00 Daniel Kulp <[email protected]>: >> >> My biggest concern would be the “jar explosion” that would occur if you >>> add a -blueprint and -spring jar for each of the jars that contains >>> those. >>> We already have a ton of jars, not sure adding another 30-40 is the best >>> idea. >>> >>> Several years ago, I also started experimenting a bit: >>> https://github.com/apache/cxf/tree/split-spring < >>> https://github.com/apache/cxf/tree/split-spring> >>> >>> But didn’t really pursue it much further. >>> >>> >>> >>> >>> On Sep 23, 2016, at 8:31 AM, Christian Schneider < >>>> >>> [email protected]> wrote: >>> >>>> >>>> On 23.09.2016 14:03, Sergey Beryozkin wrote: >>>> >>>>> IMHO the most important thing is to preserve the CXF stability. >>>>> >>>>> FYI, CommomUtil helpers which can use Spring are heavily used - some of >>>>> >>>> them in JAX-WS and a lot in JAX-RS. >>> >>>> >>>>> For example, JAX-RS SpringBoot starter does depend a lot on the >>>>> >>>> ClassScanner Spring, and JAX-RS runtime depends in various places on >>> ClassHelper to help with dealing with Spring proxified beans. The code >>> which refers to these helpers can not afford to start referring to Spring >>> variants because of course not all CXF users are Spring users. >>> >>>> >>>>> One needs to be aware that Spring (and now SpringBoot) is very much a >>>>> >>>> major platform for many CXF users. >>> >>>> We should definitely keep the good support for spring that we currently >>>> >>> have. What I am not sure of is if we still need the pretty extensive xml >>> namespaces in the future. The modern spring platform is now almost >>> completely annotation based. So I can imagine that cxf 4 might drop xml >>> namespaces in favor of comprehensive annotation based spring support. >>> >>>> >>>>> Personally I'd like see a very clear and concrete plan first: >>>>> - How to preserve the runtime code portability which depends on >>>>> >>>> CommonUtil helpers such that it works as before in/out of Spring >>> >>>> I am not yet at the stage where I have a concrete plan. My first attempt >>>> >>> was just to find out how deeply spring is wired into CXF. As it seems the >>> unwrapping of proxies seems to be the most problematic part. So one first >>> task is to find a good way to make this still work while having a >>> separate >>> module for the spring support. >>> >>>> - How to keep CXF Spring user code which depends on Spring Namespace >>>>> >>>> support (starting from cxf:bus and then for all other modules) >>> operating. >>> >>>> As a first step I would simply add the new cxf-core-spring jar to all >>>> >>> modules that define namespaces. That might then not provide the full >>> advantage of the separation but it should guarantee that all modules work >>> as before. This change should make sure that refreshs only happen to >>> modules that provide namespaces. >>> >>>> As a second step we should then check if we can improve on that. This >>>> >>> all of course depends if we find a feasible solution and if the changes >>> have the desired effect. >>> >>>> In any case I will make sure that we keep all problematic changes in a >>>> >>> branch so we can decide about them before they reach the master. >>> >>>> >>>> Christian >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> >>>> >>> -- >>> Daniel Kulp >>> [email protected] <mailto:[email protected]> - http://dankulp.com/blog < >>> http://dankulp.com/blog> >>> Talend Community Coder - http://coders.talend.com < >>> http://coders.talend.com/> >>> >>> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ >
