chore(deps): stop shipping okhttp for the plugins that use it - #207
Merged
Merged
Conversation
No class here imports okhttp3. The declaration existed so that Fess would carry okhttp-jvm in WEB-INF/lib for two data store plugins to pick up at run time, and its comment said so. Those plugins now carry it themselves, so the 2.9 MiB it brings - okhttp-jvm, okio-jvm and kotlin-stdlib - leaves the distribution. The comment named only fess-ds-microsoft365, which calls okhttp from its own code. fess-ds-box needed it too, and silently: seventeen classes of box-java-sdk call okhttp, and the SDK was getting Fess's 5.x rather than the 4.12.0 it asks for, because WEB-INF/lib precedes WEB-INF/plugin. Both plugins now declare okhttp-jvm at the version fess-parent pins and shade it in, so they agree on one version and neither depends on what the war happens to hold. Nothing else needed it. fess-llm-gemini, -ollama and -openai pull okhttp only through MockWebServer at test scope; fess-webapp-multimodal and fess-crawler-playwright were inheriting it from here without using it; Fess itself only uses it in its own tests. Both plugin releases have to go out before this, or an installation that upgrades the war first loses okhttp under a plugin that still expects it. The full suite passes apart from test_doHead_accessTimeoutTarget, which asserts that a one-second timeout interrupts a two-second sleep and fails under load on a different client each run - Hc4 and Ftp here, Hc5 on an unmodified checkout of main, which also errored in SmbClient. Run alone it passes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No class here imports
okhttp3. The declaration existed so that Fess would carryokhttp-jvminWEB-INF/libfor data store plugins to pick up at run time, and its comment said so. Those plugins now carry it themselves, so 2.93 MiB leaves every Fess distribution:okhttp-jvm(0.92),kotlin-stdlib(1.64),okio-jvm(0.37).Fess's
WEB-INF/libgoes from 220 jars to 217.The comment was narrower than the truth
It named only fess-ds-microsoft365, which calls okhttp from its own code. fess-ds-box needed it too, and silently: seventeen classes of
box-java-sdkcall okhttp, and the SDK was getting Fess's 5.x rather than the 4.12.0 it asks for, becauseWEB-INF/libprecedesWEB-INF/plugin. Nothing in either pom recorded that.Both plugins now declare
okhttp-jvmat the version fess-parent pins and shade it in, so they agree on one version and neither depends on what the war happens to hold:Nothing else was using it
Checked across every plugin repository in the workspace:
src/testonlyOrdering
Both plugin PRs have to be released before this merges. An installation that upgrades the war first would lose okhttp under a plugin still built the old way.
Verification
Full suite: 2,057 tests, one failure —
test_doHead_accessTimeoutTarget, which asserts that a one-second timeout interrupts a two-second sleep. It fails on a different client each run and is not related to this change:Hc4HttpClientTest.test_doHead_accessTimeoutTargetFtpClientTest.test_doHead_accessTimeoutTargetHc5HttpClientTest.test_doHead_accessTimeoutTargetplus an error inSmbClientTest.test_resolveSidsDisabledRun on its own,
Hc4HttpClientTestpasses 3 times out of 3 on this branch. This module has no okhttp reference at all — no import, no MockWebServer, no test dependency — so there is no path from this change to those tests.On the Fess side, with this build installed: 7,470 tests, 0 failures, 0 errors, and no
NoClassDefFoundErroranywhere in the output.