fix(kafka): expose kafka-clients and okapi-core as api deps#47
Merged
Conversation
KafkaMessageDeliverer's public constructor takes Producer<String, String>, so kafka-clients types appear in okapi-kafka's public API. Same for okapi-core types returned from public methods. Both need api scope so consumers don't have to add transitive deps manually.
endrju19
force-pushed
the
fix-okapi-kafka-api-scope
branch
from
44864aa to
48ae631
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
KafkaMessageDeliverer's public constructor takesProducer<String, String>, which meanskafka-clientstypes appear inokapi-kafka's public API. Similarly,okapi-coretypes (OutboxStore,OutboxPublisher, etc.) leak into public method signatures.Both deps were previously scoped as
compileOnly/implementationrespectively, forcing consumers to addkafka-clientsmanually to their build and giving them surprising classpath failures onokapi-coretypes.This PR switches both to
apiso consumers transitively get the types they need just by depending onokapi-kafka.Changes
okapi-kafka/build.gradle.kts:implementation(project(":okapi-core"))→api(project(":okapi-core"))compileOnly(libs.kafkaClients)+testImplementation(libs.kafkaClients)→api(libs.kafkaClients)(with rationale comment)Test plan
./gradlew :okapi-kafka:buildpassesokapi-kafkacan instantiateKafkaMessageDeliverer(...)without explicitly depending onkafka-clients