dependencies management

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

dependencies management

Romain Manni-Bucau
Hi everyone,

CXF dependency management is based on being self contained.
Was not working bad years ago when it was using geronimo bundles but since
some years it becomes more and more work to integrate each cxf release
because dependencies became greedy.

Here are the main challenges:

1. spec jars are using jakarta (whereas the app/soft can use javax,
geronimo, smix and other flavors)
2. most modules leak not required dependencies (thinking to jta, jms, rmi
out of my head)
3. some java 11 oriented dependencies are popping up whereas they are not
needed in 80% of the cases (activation, jaxb for ex)
4. module rarely/never mark not required dependencies as being
optional/provided

To give you an idea, it is not uncommon to have ~15 exclusions to all cxf
modules when importing them.

Is it something identified? Any plan to enhance this (like having
aggregator poms "cxf-spec", "cxf-dep-optional", "cxf-java9" to ease the
exclusions? making it provided and having aggregator pom with the
depencencies marked as required (strict module vs consumed pom modules))?

Side note: explosing cxf-core can also help, it contains a lot of optional
stuff which can also make this work harder to maintain.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Reply | Threaded
Open this post in threaded view
|

Re: dependencies management

Andriy Redko
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>

Reply | Threaded
Open this post in threaded view
|

Re: dependencies management

Romain Manni-Bucau
Hi Andriy,

Sure, here is a public pom - a few excludes are likely no more needed like
javax ones but overall it is working as expected like that, ie
dependency:tree is minimal and functional:
https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/pom.xml#L139

Le mer. 11 nov. 2020 à 23:07, Andriy Redko <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: dependencies management

Andriy Redko
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 <[hidden email]> 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
>> >