[
https://issues.apache.org/jira/browse/KAFKA-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17693377#comment-17693377
]
Greg Harris commented on KAFKA-14760:
-------------------------------------
Looking into this more, it appears that this was done previously and then
reverted, because classes in the `tools` jar are run against a classpath
containing potentially extremely old client versions, back to 0.8.2 in system
tests.
It appears that it is unsafe to depend on modern functionality in the tools
jar, at least given the current way that upgrades are being tested and the
tools jar is being used.
Renaming the class and moving it to the clients jar would be depending on
modern functionality, since the renamed class is only present after the
refactor.
So it's possible that we need to duplicate the ThroughputThrottler
functionality, or remove the dependency by replacing it with some other class
rather than moving and renaming the copy in tools.
> Move ThroughputThrottler, break connect-runtime dependency on tools
> -------------------------------------------------------------------
>
> Key: KAFKA-14760
> URL: https://issues.apache.org/jira/browse/KAFKA-14760
> Project: Kafka
> Issue Type: Task
> Components: KafkaConnect, tools
> Reporter: Greg Harris
> Assignee: Greg Harris
> Priority: Major
>
> Currently there is only one dependency on the `tools` module,
> `connect-runtime`.
> This dependency is only for one class, the ThroughputThrottler. This class is
> used by:
> 1. tools main ProducerPerformance
> 2. tools main VerifiableProducer
> 3. runtime main SchemaSourceConnector
> 4. runtime main VerifiableSourceConnector
> 5. runtime test MonitorableSourceConnector
> For KAFKA-14627, I want to be able to have `tools` (test) depend on
> `connect-runtime` (test). This is because we are adding a connect-specific
> command-line utility, and wish to re-use some of the existing connect test
> infrastructure to unit test the new command-line utility. Unfortunately
> naively adding this new dependency to tools causes a circular dependency that
> prevents the project from building.
> Instead of refactoring the connect-specific test utilities out to a new
> package that both runtime and tools can depend on, it appears to make more
> sense to move the more generic `ThroughputThrottler` class into some common
> package.
> This common package could be:
> 1. clients
> 2. server common
> 3. some other existing package which would be a new dependency for tools
> 4. a new package consisting of just the `ThroughputThrottler` class
> I'm not sure which one of these makes the most sense, and would appreciate
> guidance on what would make the most sense for ownership and maintenance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
