[infinispan-dev] Best practices for Netty version clashes

[Dan Berindei]

The application POM could use dependency convergence [1], but we probably
can't (and shouldn't) use the plugin in the BOM and enforce it's usage in
applications.

Dan

[1]:
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

On Thu, Feb 15, 2018 at 12:52 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> This is actually how the dependency resolution (strike it out and replace
> with hell) works.
>
> In this particular example, Netty 4.1.9 is "closer" to the project you're
> building than Netty 4.1.17 [1]. This happened since Maven just copy-past
> the Dependency Management section from imported bom. So effectively Netty
> from Infinispan BOM got into the Dependency Management section of your
> project.
>
> Of course, if you hit an integration problem like this, you may declare
> Netty version directly in your Dependency Management. This way you will
> enforce Maven to you what you want.
>
> IMO, the end user can do nothing about such errors (and this is really
> sad). Your particular problem is about Netty but I can easily imagine users
> who got the same problem with Apache Commons (although the chances are
> smaller since they are backwards compatible... opposed to Netty). Maybe
> someday the Jigsaw will solve it... But for now - just don't use BOM or
> declare Netty version in your Dependency Management section.
>
> Thanks,
> Sebastian
>
> [1] https://maven.apache.org/guides/introduction/
> introduction-to-dependency-mechanism.html
>
> On Thu, Feb 15, 2018 at 1:26 PM Galder Zamarreño <galder at redhat.com>
> wrote:
>
>> Hi,
>>
>> I was playing around with GRPC for a talk next month and made a mistake
>> that threw me a little bit and wanted to share it here to see if we can
>> do something about it.
>>
>> My demo uses GRPC and Infinispan embedded cache (9.2.0.CR1), so I added
>> my GRPC dependencies and Infinispan bom dependency [1].
>>
>> This combo resulted in breaking my GRPC demos.
>>
>> The bom imports Netty 4.1.9.Final while GRPC requires 4.1.17.Final. The
>> dependency tree showed GRPC using 4.1.9.Final which lead to the
>> failure. This failure does not seem present in 4.1.17.Final.
>>
>> Should we have an embedded bom where no client libraries are depended
>> upon? This would work for my particular use case...
>>
>> However, someone might develop a GRPC server (which I *think* it still
>> requires netty) and they could then use Infinispan remote client to
>> bridge over to Infinispan sever. For example: this could be way to move
>> clients over a new client while other clients use an older protocol.
>>
>> How should a user solve this clash? I can only see exclusions and
>> depending on latest Netty version as solution. Any other solutions
>> though?
>>
>> Cheers,
>>
>> [1] https://gist.github.com/galderz/300cc2708eab76b9861985c216b90136
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20180215/e494bd72/attachment-0001.html