[WMK666666]

Follow-up to #29594, as suggested in its review: outputFormat still lists html_split_page in its enums, and that value cannot produce anything.

• With useDoclingServe=true, camel-docling: return DocTags content and reject html_split_page on docling-serve #29594 makes the request fail, because DocumentResponse has no field for the split pages.
• On the CLI path the option is never read either: every operation passes its own format (DoclingProducer.java:309-353, :717).

So the option description now says so, and the component metadata is regenerated.

@Metadata(description = "Output format for document conversion. The html_split_page value is rejected
          when useDoclingServe is true, as docling-serve returns no split pages, and the CLI operations
          pass their own format; use html instead", ...)

Merge order: this only documents the behaviour that #29594 introduces, so it should go in after #29594. On its own the description would be a step ahead of main.

On the regenerated file: docling.json gains exactly the same sentence in both places the option is described (componentProperties and properties), nothing else. I ran the generator and then kept only the two strings this change touches — the 4.24.0-SNAPSHOT plugin I have locally also re-adds an empty deprecationNote to every property, which main's committed file does not carry, so a full regeneration from my side would have added ~143 lines of generator-version noise to this PR.

formatter:validate and impsort:check pass, and the module compiles.

[gnodet-bot]

The description update correctly documents the broken value, but html_split_page is still listed in enums — the catalog will still advertise it as a valid option alongside the warning. Users who rely on IDE autocomplete or the catalog UI will see it as a valid choice and have to read the full description to discover it doesn't work.

Consider removing html_split_page from the enums list (or annotating it with @Deprecated if the enum type supports it), so the catalog stops presenting it as a valid option. The enums attribute drives autocomplete and validation; leaving a broken value there is at best confusing and at worst silently corrupts routes that use it on the CLI path (mapToDoclingFormat has no case for html_split_page and silently falls back to md).

If removing it would break backward compatibility for users who have outputFormat=html_split_page in their configs, an explicit validation on startup (throw IllegalArgumentException) would be better than silent fallback to markdown — users would at least know their config is wrong.

One further note: this PR is explicitly marked as a follow-up to #29594, which is not yet merged. Without #29594, the useDoclingServe=true rejection behavior referenced in the description doesn't exist on main yet, so this description would be ahead of the actual behavior. The merge order dependency is noted in the PR body, but it's worth confirming before merging.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

⚠️ html_split_page is still listed in enums, so the catalog and IDE autocomplete will continue to present it as a valid choice. The description now says it doesn't work, but users who rely on catalog-driven configuration rather than reading the full description will still pick it and get unexpected behaviour.

Consider removing it from enums, or throwing an explicit IllegalArgumentException during configuration validation rather than silently falling back to markdown (which is what the CLI path does in mapToDoclingFormat — there is no case for html_split_page, so it defaults to "md" without any warning).

Suggested change

	defaultValue = "markdown",
	@Metadata(description = "Output format for document conversion. The html_split_page value is not supported"
	+ " and will be removed in a future release; use html instead.",
	defaultValue = "markdown",
	enums = "md,json,html,text,doctags")

[oscerd]

Good follow-up to #29594, and the description text itself is accurate: html_split_page is rejected under useDoclingServe=true and the CLI operations each pass their own format, so documenting "use html instead" on outputFormat is the right move.

One thing to fix before this can go green: the regeneration is incomplete. The edit to @Metadata(description = ...) on outputFormat is in DoclingConfiguration.java and in the component's own META-INF/.../docling.json, but the two generated mirrors that the same description feeds were not regenerated:

• catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/components/docling.json still carries the old "Output format for document conversion".
• DoclingEndpointBuilderFactory (and the docling component builder factory) still have the old Javadoc for the option.

This is coming from a fork, so CI has not run yet, but when it does the uncommitted-changes check will fail on exactly those files. Regenerating and committing brings all four copies into step: building the module regenerates its own JSON, and the camel-catalog copy and the endpoint-dsl factory are regenerated from the same metadata. The source edit and the wording are fine, it is only the generated mirrors that need to catch up.

Claude Code on behalf of oscerd