My first Apache Kafka PR deleted three lines. I almost deleted the wrong one.

Description and use

Deleting a duplicate dependency line in a Gradle file can alter classpath order even though the resolved set is unchanged. The author removed the later line of each duplicate pair, preserved order, and the PR was merged.

Problem

Removing a duplicate dependency declaration in a Gradle build file can change classpath order and break tests, yet the change appears to be a no‑op.

Outcome

The PR was merged after demonstrating that deleting the later duplicate lines preserved classpath order and test success.

Workflow

• 1. Identified duplicate test dependency declarations in build.gradle.
• 2. Chose which line to delete based on visual inspection (initially removed the earlier line).
• 3. Generated dependency reports for both test configurations before and after the change.
• 4. Compared reports to check for differences in resolved modules and order.
• 5. Noted that removing the earlier line altered the order of resolved artifacts, potentially affecting classpath precedence.
• 6. Decided to delete the later line of each duplicate pair instead.
• 7. Re‑generated dependency reports to confirm byte‑identical outputs.
• 8. Ran tests (WorkerTest) to ensure no failures.
• 9. Updated PR description to explain the rationale.
• 10. Awaited committer approval and merge.

Evidence

In build.gradle, three test dependencies were declared twice inside the same block: core libs.apachedsCoreApi lines 1221 and 1230 connect:runtime project(':server-common') lines 3842 and 3847 connect:runtime project(':server') lines 3840 and 3848

Source

The resolved sets were identical: 73, 104, 125 and 171 modules, not one difference.

Source

The :core report was not. Fifteen lines had moved. org.apache.directory.api:api-all jumped from position 150 to 87, ahead of apacheds-core-api.

Source

The four reports came back byte-identical, at 241, 418, 498 and 760 lines. Both modules compiled their tests, check passed without the test task, rat passed at the root, and WorkerTest ran 140 tests with no failures as a spot check on the connect side.

Source