[jira] [Assigned] (CAMEL-24913) camel-jev-starter: hand-craft the Spring Boot starter so the jev language can be configured

["Ramu (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ramu reassigned CAMEL-24913:
----------------------------

    Assignee: Ramu

> camel-jev-starter: hand-craft the Spring Boot starter so the jev language can be configured
> -------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24913
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24913
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-ai, camel-spring-boot-starters
>            Reporter: Claus Ibsen
>            Assignee: Ramu
>            Priority: Major
>             Fix For: 4.23.0
>
>
> h2. Background
> CAMEL-24871 added {{camel-jev}} (merged to main as ee626c6e9307, Camel 4.23.0). Besides the component, it ships a {{jev}} language that is exposed through the generic {{LanguageExpression}} model rather than a dedicated model in camel-core, using the new {{@Language(modelName = "language")}} attribute.
> h2. Problem
> Spring Boot starters are source-generated in {{apache/camel-spring-boot}}, and the generated {{*LanguageConfiguration}} class is derived from the language's JSON model. Because {{jev}} reuses the generic model, its language JSON only carries the generic {{LanguageExpression}} properties:
> {{id}}, {{language}}, {{expression}}, {{trim}}, {{resolveResource}}
> None of the options that actually configure a Jev evaluation are there. Those live on the component/endpoint:
> {{apiKey}}, {{model}}, {{questions}}, {{state}}, {{threshold}}, {{uncertainty}}, {{uncertaintyPolicy}}, {{baseUrl}}, {{requestTimeout}}, {{maxConcurrentRequests}}
> So a purely generated {{camel-jev-starter}} would produce a {{JevLanguageConfiguration}} under {{camel.language.jev.*}} that exposes nothing useful — there is no way to set the API key or the question through it. Code generation cannot close this gap, because the generator has no jev-specific model to read from.
> h2. Proposal
> Hand-craft {{camel-jev-starter}} rather than relying on the generated output, the way {{camel-platform-http-starter}} is maintained today. That starter carries eight hand-written classes in {{src/main/java}}, including its own {{PlatformHttpComponentConfiguration}} and {{PlatformHttpComponentAutoConfiguration}}, plus a full test suite. Around 25 starters already carry hand-written code, so this is an established pattern rather than a new exception — for example {{camel-jetty-starter}}, {{camel-jasypt-starter}}, {{camel-core-starter}}, {{camel-mcp-server-starter}}.
> Scope to work out:
> * Write {{JevLanguageConfiguration}} / {{JevLanguageAutoConfiguration}} by hand so the jev options are settable from Spring Boot properties, and decide the namespace — hand-written {{camel.language.jev.*}} covering the jev options, or document {{camel.component.jev.*}} as the single source of configuration with the language resolving against it.
> * Determine how the starter is kept out of regeneration so the hand-written classes are not clobbered on the next sync. The exact opt-out mechanism used by {{camel-platform-http-starter}} still needs to be identified — it is not simply a flag in that module's pom.
> * Add Spring Boot tests covering a route that uses the {{jev}} language configured purely from {{application.properties}}.
> * Document the resulting property set in the component docs.
> h2. Related
> CAMEL-24914 tracks the generator-side question: {{jev}} is the first language to use {{@Language(modelName = "language")}}, so the starter generator has never seen a language backed by the generic model. That matters for future components regardless of how {{camel-jev-starter}} itself is built.
> _Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)