fix(#713): add missing transitive dependencies to camel-tika feature - #716
Open
jbonofre wants to merge 2 commits into
Open
fix(#713): add missing transitive dependencies to camel-tika feature#716jbonofre wants to merge 2 commits into
jbonofre wants to merge 2 commits into
Conversation
…ature The camel-tika feature was missing the transitive runtime dependencies of tika-parser-html-module (jsoup, commons-codec) and tika-parser-text-module (commons-csv, juniversalchardet). Without them, tika operations such as tika:detect/tika:parse fail at runtime with NoClassDefFoundError (e.g. org.apache.tika.parser.txt.UniversalEncodingListener needs org.mozilla.universalchardet.*). jsoup, commons-codec and commons-csv are already proper OSGi bundles and are added as plain mvn: bundles. com.github.albfernandez:juniversalchardet 2.5.0 ships without OSGi metadata, so it is installed via wrap:. The stale, unused juniversalchardet-version property (1.0.3, the old com.googlecode groupId) is bumped to 2.5.0 to match the version Tika 3.2.3 pulls in. Adds a Pax Exam integration test (tests/features/camel-tika) that parses a plain-text body through tika:parse, exercising the text parser and its juniversalchardet dependency at runtime.
The camel-tika itest asserted that tika:parse extracts text, but in Karaf tika:parse returns empty content: Tika's AutoDetectParser discovers parsers through the JDK ServiceLoader, which does not cross OSGi bundle boundaries. Wiring Tika's parser SPI for OSGi is out of scope for issue apache#713, whose fix is the missing juniversalchardet bundle so tika-parser-text-module resolves. Scope the test to what apache#713 fixes: the feature installs and the tika:parse route processes one exchange end-to-end (expectedMessageCount(1)). Before the fix the tika-parser-text-module bundle could not wire (missing org.mozilla.universalchardet), so the route never started and no message reached the mock.
|
commons-codec dependency is included in camel-core feature |
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
2 participants
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.
Summary
Fixes #713. The
camel-tikafeature was missing several transitive runtime dependencies of the Tika parser modules it installs, so thetika-parser-*bundles could not wire in OSGi (e.g.org.apache.tika.parser.txt.UniversalEncodingListenerneedsorg.mozilla.universalchardet.*from juniversalchardet), leaving the feature effectively broken at runtime.Dependency tree of
camel-tika(Tika 3.2.3):org.jsoup:jsoupmvn:commons-codec:commons-codecmvn:org.apache.commons:commons-csvmvn:com.github.albfernandez:juniversalchardetwrap:Changes
features/src/main/feature/camel-features.xml— addjsoup,commons-codec,commons-csv(plain bundles) andjuniversalchardet(viawrap:, as it ships no OSGi metadata) to thecamel-tikafeature.pom.xml— bump the stale, previously-unusedjuniversalchardet-versionfrom1.0.3(the oldcom.googlecode.juniversalchardetgroupId) to2.5.0, matching what Tika 3.2.3 pulls in (com.github.albfernandez).tests/features/camel-tika— new Pax Exam integration test (direct → tika:parse → mock) plus the<module>entry. The test verifies the feature installs and the route runs end-to-end: before this fix thetika-parser-text-modulebundle could not wire (missingorg.mozilla.universalchardet), so the route never started and no message reached the mock.Note on
tika:parsein OSGiThe itest intentionally does not assert on the extracted text. In Karaf,
tika:parsecurrently returns empty content regardless of input: Tika'sAutoDetectParserdiscovers parsers through the JDKServiceLoader, which does not cross OSGi bundle boundaries (adding thespiflyfeature alone is not sufficient — the parser modules also need SPI-Provider wiring). Making Tika fully functional in OSGi is a separate concern beyond the scope of #713 and is tracked in #727.Verification
mvn -pl features process-resources(karafverifygoal) resolves the feature cleanly:The new integration test passes in a real Karaf/Pax Exam container:
(The unrelated
camel-chatscript/camel-docling/camel-jacksonxml/camel-langchain4j-chat/camel-torchservefailures in a full local run are a pre-existingjackson-annotation2.21 vs 2.20.1 mismatch in the local repo, not affected by this change.)