This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Under DiscussionAccepted

Discussion thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

We only have one tool with this issue (kafka.tools.StateChangeLogMerger), which is tracked in KAFKA-7735. This tool has been broken since 2.0 release, so it means that there is not much interest and we should simply deprecate.

However, the work for migrating and fixing this tool is on-going, but not included in the scope of this KIP.

Core dependency

Most tools communicate via Kafka protocol by using client classes, so they can be migrated without dependencies on core. Instead, tools with non-trivial dependencies on core (e.g. log message parsers) should wait until all required dependencies are migrated. If present, we should set related tasks as blockers for the tool migration sub-task.

...

• One option to address the missing wrapper issue and SPI argument issues would be to create a :tools:deprecated sub module hosting all deprecated classes and interfaces with the old package name. This is mainly driven by the single root package checkstyle limitation.
• Another option to address the missing wrapper issue would be to let the kafka-run-class script do the redirection by going through all input parameters and replacing the old package name with the new one. This is a bit hacky and introduces unnecessary adds some delay to every command.