A deletion is a change too. In a build file, it can move a classpath without anyone noticing. This pull request removed three lines from Kafka's build.gradle, and almost all of it was about proving that nothing else moved.
The duplicates
- core: libs.apachedsCoreApi, declared at lines 1221 and 1230
- connect:runtime: project(':server-common'), at lines 3842 and 3847
- connect:runtime: project(':server'), at lines 3840 and 3848
Gradle resolves a configuration as a set, so the second declaration of each pair is a no-op. That is the theory. I wanted the measurement.
The proof
./gradlew :connect:runtime:dependencies --configuration testCompileClasspath
./gradlew :connect:runtime:dependencies --configuration testRuntimeClasspath
./gradlew :core:dependencies --configuration testCompileClasspath
./gradlew :core:dependencies --configuration testRuntimeClasspathThe four reports are byte-identical before and after, at 241, 418, 498 and 760 lines, and the resolved module sets match exactly at 73, 104, 125 and 171 modules.
The detail that mattered
In each pair I removed the later declaration, not the earlier one. Dropping core line 1221 instead of 1230 moves apachedsCoreApi behind libs.apacheda in declaration order, and the dependency report then lists api-all before apacheds-core-api. Same set, different order. Removing the later line keeps every position, and therefore the classpath order, exactly as it was.
Both test source sets compile, the check tasks pass with checkstyle, spotbugs and spotless, rat passes at the root, and as a spot check WorkerTest ran its 140 tests with no failure.
What I take from it
In a project the size of Kafka, a cleanup is only welcome if it costs the reviewer nothing to trust. The diff was three red lines. The pull request was the evidence that they were safe to delete.
Ayoub Hammoudi, Software engineer, full-stack and AI platforms. github.com/Ayoubhm07
