search

linkedin / li-apache-kafka-clients

li-apache-kafka-clients is a wrapper library for the Apache Kafka vanilla clients. It provides additional features such as large message support and auditing to the Java producer and consumer in the open source Apache Kafka.
BSD 2-Clause "Simplified" License
131 stars 52 forks source link

split into multiple modules #79

Closed radai-rosenblatt closed 6 years ago

radai-rosenblatt commented 6 years ago

this splits the code into 3 modules:

  1. li-apache-kafka-clients - main codebase
  2. kafka-test-harness - contains the test harness code. depends on 1
  3. integration-tests - uses the test harness code (2) to test 1

we expect to publish 1 and 2 as artifacts. 3 is our own integration tests and had to be factored out to avoid a circular dependency, but shouldnt be used by anyone else.

mockitoguy commented 6 years ago

Can you write a short description what is driving the changes?

This will help me review the changes! Thank you!

becketqin commented 6 years ago

@radai-rosenblatt Thanks for the patch. LGTM. The only comment I have is that it might be better to keep the idea plugin so people who are familiar with that can still use it.

@mockitoguy It's great to have some expert to look at this :)

radai-rosenblatt commented 6 years ago

@mockitoguy - i've updated the commit msg. here is the new one:

split to multiple modules, use tag-driven versioning

this codebase contains 2 usable artifats already - the clients, and the test harness base classes, which before this patch were included in a test artifact.
a test artifact is awkward to produce, publish and depend upon so this splits the project up into li-apache-kafka-clients (which contains the clients, as t always has)
and kafka-test-harness, which holds the base classes for the test harness. these classes are useful in starting/stopping embedded ZK and kafka for integration tests.
there's also a 3rd module which uses the test harness to run integration tests for the clients. this 3rd module does not produce any artifact for downstream users.

this change also gets rid of the version property and instead uses a gradle plugin to deduce the version based on the "nearest" git tag

hopefully this explains the changes and the reasoning behind them

lindong28 commented 6 years ago

@radai-rosenblatt @mockitoguy It seems that this commit breaks gradle idea with the following error:

* What went wrong:
A problem occurred evaluating root project 'buildSrc'.
> No signature of method: build_4kafg6gltq7e3kb5renv2ehpm8$_run_closure1.id() is applicable for argument types: (java.lang.String) values: [java-gradle-plugin]
  Possible solutions: is(java.lang.Object), is(java.lang.Object), find(), find(), find(groovy.lang.Closure), find(groovy.lang.Closure)

I am not able to fix it myself. Do you know how to fix it?