[ 
https://issues.apache.org/jira/browse/CAMEL-25241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121727#comment-18121727
 ] 

Claus Ibsen commented on CAMEL-25241:
-------------------------------------

Analysis (2026-10-01):

* The model classes (camel-core-model) and the Java DSL parser (camel-java-io) 
are on the TUI classpath already (via camel-jbang-core), so the methods can be 
read with reflection.
* What follows a dot depends on the definition the chain is on, not on the 
lines above: after .split(body()) the chain is on SplitDefinition (its options 
and every EIP), .to(..) returns the same type (so .streaming() after it still 
compiles), .end() goes back to the parent, .choice().when(..) is on 
ChoiceDefinition.
* Approach: read the statement from from( to the cursor (works while the file 
does not parse), resolve each call with reflection starting at RouteDefinition, 
and keep a stack of open blocks: a block EIP opens one, end() closes it, 
endChoice()/endDoTry() close to the choice/try, an ExpressionClause 
(.split().simple(..)) returns to its definition. Same semantics the parser has 
at runtime (ChainReplayer uses the returned object).
* Offered after a dot: the options of the current definition first (methods 
declared below ProcessorDefinition, overloads merged, signatures in the 
details), then the EIPs and end*. Filter: the parser's isAllowed rule (public, 
org.apache.camel.model.*, no CamelContext), returns a definition or 
ExpressionClause (drops void internals like addOutput/preCreateProcessor and 
getters), no copyDefinition/toString, no deprecated. A get/set prefix rule 
would be wrong (setBody, setHeader are DSL). Docs from the catalog EIP models; 
a few built-in lines for end, endChoice, endDoTry...
* Risks: the chain walk (nested blocks, choice/when/otherwise, doTry/doCatch, 
expression clause, comments and strings); the method list follows the TUI's 
Camel version, the catalog docs the project's (as the Java parser).
* Check: recall over the Java routes of the repo: at every dot in a chain, the 
method written next must be among the offered ones.
* Out of scope at first: expression builders in arguments 
(body().tokenize(..)), routes in local variables, the REST DSL, lambdas.

_Claude Code on behalf of davsclaus_

> camel-jbang - source editor completion for the Java DSL route chain
> -------------------------------------------------------------------
>
>                 Key: CAMEL-25241
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25241
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jbang
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> Sibling of CAMEL-25240 (XML element and attribute completion).
> The source editor of camel-jbang completes endpoint uris in the strings of 
> Java routes (CAMEL-25208) and simple expressions (CAMEL-25219), but not the 
> Java DSL itself: Tab after a . in a route chain offers nothing, while YAML 
> routes complete EIP names and options from the catalog.
> Add Tab completion for the Java DSL route chain, kept to Camel (not general 
> Java completion, which an IDE does):
> * after . in a route chain: the EIPs from the catalog, by their Java DSL 
> method names (mostly the model names: setBody, split, choice, when; the few 
> that differ taken from the model classes);
> * after an EIP call: that EIP's options as the fluent methods that follow it 
> (.split(body()).parallelProcessing(), .streaming()...);
> * the documentation of each in the details panel, as for YAML.
> Read the position in the chain from the lines above the cursor, so it works 
> while the file does not parse; when it parses, the Java DSL parser 
> (LwJavaParser / RouteNodes) can tell which EIP the chain is on.
> Useful mostly for writing routes in the source editor without an IDE, by 
> people and local models.
> Tests in camel-jbang-plugin-tui; help (source.md) and the source editor doc 
> page updated.
> _Claude Code on behalf of davsclaus_



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

Reply via email to