search

Netflix / ribbon

Ribbon is a Inter Process Communication (remote procedure calls) library with built in software load balancers. The primary usage model involves REST calls with various serialization scheme support.
Apache License 2.0
4.58k stars 1.24k forks source link

Ribbon on Java 9+ (JPMS/Jigsaw) #387

Open ghost opened 6 years ago

ghost commented 6 years ago

Ribbon makes extensive use of split packages (e.g. package com.netflix.client being both in ribbon-core and ribbon-loadbalancer, or package com.netflix.client.http in both ribbon-httpclient and ribbon-core).

This is no longer allowed with Java9+ JPMS/Jigsaw and e.g. on IntelliJ breaks the internal build process on modularized projects (that is having an module-info.java). The only workaround would be to fork the ribbon source and clean up the packages or merge ribbon modules together.

Is there any intention to tackle this problem "officially"?

mattnelson commented 6 years ago

Is this only a problem if ribbon is on the module path?

spencergibb commented 6 years ago

That's my guess. The module path likely won't be feasible until the whole graph of open source dependencies are modules.

fenixcitizen commented 4 years ago

Hi,

is there any roadmap to address the split packages in Ribbon at this point? I find this blog post very informative on top of this overview.

Split packages are a problem that can be addressed with simple but disruptive refactoring (package structure has to change). Ideally, Automatic-Module-Name entry should be added to all manifests matching the base package for each subproject. There is no need to modularize Ribbon so that it could be used by modular applications.

aalmiray commented 1 year ago

Please consider removing split packages and adding a full module descriptor.

Plugin org.jonnyzzz.java9c may be used to find which packages are split. Plugin org.moditect.gradleplugin may be used to generate a module-info.class while keeping compatibility with Java 8.