You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
ksqldb-api-client pulls in too many dependencies, despite this comment in the POM:
A note on dependencies.
The Java client module has a different approach to dependencies than server modules.
The client is embedded in a user's application so it's really important that:
* It's small. We don't want to drag in a load of dependencies and make our user's apps big and
bloated. Also, the user's app might be a lightweight microservice running on a cloud or similar
where binary size can really matter.
* We minimise the probability of version conflicts. The more libraries that we depend on the
greater the risk of a version conflict with a different version of the same library already
used in the user's app. Version conflicts are a real pain for user's to resolve. It gets worse
if we're pulling in commonly used libraries such as Apache commons, Guava, Google stuff, etc.
as the probability of a conflict gets even higher. These ones in particular should really be avoided.
The POM still defaults to including io.confluent.broker-plugins (via its parent POM), which pulls in many, many unnecessary libraries. Not to mention, some of these libraries break JPMS rules by multiple JARs exporting the same packages, therefore being impossible to use in a modular Java project.
Expected behavior
Properly configured POM that does not pull in many unnecessary libraries.
Actual behaviour
Improperly configured POM that pulls in many unnecessary libraries.
The text was updated successfully, but these errors were encountered:
Describe the bug
ksqldb-api-client pulls in too many dependencies, despite this comment in the POM:
The POM still defaults to including io.confluent.broker-plugins (via its parent POM), which pulls in many, many unnecessary libraries. Not to mention, some of these libraries break JPMS rules by multiple JARs exporting the same packages, therefore being impossible to use in a modular Java project.
Expected behavior
Properly configured POM that does not pull in many unnecessary libraries.
Actual behaviour
Improperly configured POM that pulls in many unnecessary libraries.
The text was updated successfully, but these errors were encountered: