[jira] [Assigned] (CAMEL-25148) camel-java-io - Lightweight Java DSL source to model parser (no compilation)

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

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

Claus Ibsen reassigned CAMEL-25148:
-----------------------------------

    Assignee: Claus Ibsen

> camel-java-io - Lightweight Java DSL source to model parser (no compilation)
> ----------------------------------------------------------------------------
>
>                 Key: CAMEL-25148
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25148
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>
> Camel can turn XML into the route model and back (camel-xml-io, with a generated ModelParser). It can load YAML into the model (camel-yaml-dsl) and write it back (camel-yaml-io). For Java it can only write the model as Java (camel-java-io, LwModelToJavaDumper). The missing direction is Java DSL source -> model without compiling it.
> h3. Today
> * camel transform route foo.java --format=yaml gets the exact model, but it compiles the RouteBuilder, runs configure() in Camel Main, needs the full classpath (it may download dependencies), takes seconds and runs the user's code. Good as an opt-in precise mode; too heavy for tooling.
> * The source-level project overview (CAMEL-25143) and the capability view (CAMEL-25147) read Java routes by pattern matching on string literals. Constants, string concatenation and the endpoint DSL are invisible, nesting is lost (a doCatch is not seen as an error path), route boundaries are guessed, and the Java REST DSL is not read.
> h3. Proposal
> A lightweight parser (e.g. LwJavaParser) in camel-java-io, next to the dumper, so the module works in both directions like camel-xml-io:
> * *Fluent chains, not all of Java.* Find configure() and parse the statements that start with from(, rest(, onException(, errorHandler(, routeTemplate(, interceptFrom( and the like. Each is a chain of calls with arguments: string literals, static final constants of the same class, string concatenation, nested calls (simple("..."), header("x"), kafka("orders")). Lambdas and anonymous processors are kept as opaque steps.
> * *Mapping generated from the model.* Like ModelXmlParserGeneratorMojo, generate the table of fluent method -> model class from the model metadata: which methods open a block (closed by end(), endChoice(), endDoTry()), which take an expression, which language builders map to which language. New EIPs are picked up automatically.
> * *Endpoint DSL.* Factory methods map to component schemes, and builder calls map to endpoint options via the catalog. For example .to(kafka("orders").brokers("b:9092")) becomes kafka:orders?brokers=b:9092.
> * *Real model objects out* (RouteDefinition, RestDefinition, ...) with source line numbers. What cannot be resolved (values from helper methods, routes built in loops) is marked as unknown rather than guessed, so tools can tell a result is partial.
> h3. Why
> * *Round-trip test corpus for free.* Dump the thousands of YAML/XML test routes as Java with LwModelToJavaDumper, parse the Java back, and compare the two models (as YAML). That covers every EIP from the start.
> * *Java doc examples checked in the build.* Today only YAML and XML examples are checked; Java examples only get an import check. With the parser, their EIPs, options and endpoint URIs can be checked like the other DSLs.
> * *One analysis path.* The project overview can work on the model for all three DSLs instead of its own readers, which removes the Java limits listed above.
> * *Java routes for every tool.* Java -> model -> YAML lets the TUI, AI prompts, camel transform and diagram tools show Java routes without compiling them.
> h3. Limits (by design)
> It is not a Java compiler. Runtime-computed values, routes built in loops or in methods of other classes, and generated code are out of reach, apart from possibly inlining simple private helper methods of the same class. The aim is to cover how people usually write routes, and to say clearly when a result is partial.
> _Claude Code on behalf of davsclaus_



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