That's indeed a good one, thanks Romain! RMB> Hi Andriy,
RMB> Sure, here is a public pom - a few excludes are likely no more needed like RMB> javax ones but overall it is working as expected like that, ie RMB> dependency:tree is minimal and functional: RMB> https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/pom.xml#L139 RMB> Le mer. 11 nov. 2020 à 23:07, Andriy Redko <[email protected]> a écrit : >> Hey Romain, >> I think it is worth the efforts to do housekeeping work and cleanup >> the dependencies. I am not sure we could do this as one big bang change >> but delivering iterative improvements with each release should work. The >> idea with grouping dependencies into separate POMs/BOMs should be >> implementable. >> Do you have examples of the exclusions you have seen people do most often, >> may >> be would could target those first? >> AFAIK we try to use optional dependencies whenever possible, indentifying >> which >> modules do not follow and fixing that would be definitely useful. Anyway, >> I think >> the exclusions should be more like an exception than a rule, if they are >> required >> in most cases, this is not good. >> Thanks. >> Best Regards, >> Andriy Redko >> RMB> Hi everyone, >> RMB> CXF dependency management is based on being self contained. >> RMB> Was not working bad years ago when it was using geronimo bundles but >> since >> RMB> some years it becomes more and more work to integrate each cxf release >> RMB> because dependencies became greedy. >> RMB> Here are the main challenges: >> RMB> 1. spec jars are using jakarta (whereas the app/soft can use javax, >> RMB> geronimo, smix and other flavors) >> RMB> 2. most modules leak not required dependencies (thinking to jta, jms, >> rmi >> RMB> out of my head) >> RMB> 3. some java 11 oriented dependencies are popping up whereas they are >> not >> RMB> needed in 80% of the cases (activation, jaxb for ex) >> RMB> 4. module rarely/never mark not required dependencies as being >> RMB> optional/provided >> RMB> To give you an idea, it is not uncommon to have ~15 exclusions to all >> cxf >> RMB> modules when importing them. >> RMB> Is it something identified? Any plan to enhance this (like having >> RMB> aggregator poms "cxf-spec", "cxf-dep-optional", "cxf-java9" to ease >> the >> RMB> exclusions? making it provided and having aggregator pom with the >> RMB> depencencies marked as required (strict module vs consumed pom >> modules))? >> RMB> Side note: explosing cxf-core can also help, it contains a lot of >> optional >> RMB> stuff which can also make this work harder to maintain. >> 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 >> >
