Claus Ibsen created CAMEL-25148:
-----------------------------------
Summary: 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
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)
