Re: [infinispan-dev] Best practices for Netty version clashes

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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev