[infinispan-dev] Best practices for Netty version clashes

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

[infinispan-dev] Best practices for Netty version clashes

Galder Zamarreno
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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


On Thu, Feb 15, 2018 at 1:26 PM Galder Zamarreño <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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


On Thu, Feb 15, 2018 at 1:26 PM Galder Zamarreño <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev