[infinispan-dev] Best practices for Netty version clashes

[Sebastian Laskawiec]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20180215/de82cac7/attachment.html