davsclaus opened a new pull request, #26623:
URL: https://github.com/apache/camel/pull/26623
## Description
The transform/groovy example of camel-jbang-examples imports
`org.apache.commons.validator.routines.EmailValidator` in a Groovy expression.
Without the dependency declared, the run failed with the compiler's `unable to
resolve class ...` and nothing else, while a `#class:` bean of the same library
is downloaded by the Camel CLI on first use. Found in the round-2 local-model
benchmark; a person gets the same.
Everything the CLI needed already existed for Java:
`KnownDependenciesResolver.mavenGavForClass`, the
`DependencyDownloaderClassResolver`, and `JavaKnownImportsDownloader`, a
`CompilePreProcessor` that scans a Java source's imports before compiling and
downloads the known ones. Groovy compiled through a GroovyShell on the
application class loader, which asks no resolver and runs no pre-processor.
**camel-groovy** (runtime-neutral, no CLI knowledge):
- inline expressions, the language's `evaluate` and the script compiler run
the registered `CompilePreProcessor`s on the script before `parseClass`, as
`JavaRoutesBuilderLoader` does;
- a compilation failure on `unable to resolve class X` becomes *Groovy
cannot resolve the class X: it is not on the classpath. Add the library that
provides it as a dependency of the application (a Maven dependency; with the
Camel CLI camel.jbang.dependencies=... or a //DEPS line); a class of your own
goes in a .groovy or .java file next to the route.*
**camel-kamelet-main**:
- the import scanner accepts Groovy imports: no semicolon, `import static
a.b.C.member` (the class is `a.b.C`), wildcards;
- `org.apache.commons.validator =
commons-validator:commons-validator:${commons-validator-version}` in the known
third-party list, the version from the parent pom like the other entries.
With that, `camel run` on the groovy example with its
`camel.jbang.dependencies` line removed downloads commons-validator when the
expression is compiled and logs the accepted and rejected orders (verified).
The example keeps teaching the explicit declaration as the portable form.
**camel validate** (camel-jbang-core, new `GroovyImportChecks`): the imports
inside the Groovy expressions of a YAML route, block scalars included. An
import that is not JDK, Groovy, Camel, a class of the project (the Java files
next to the route) or a known library is reported with how to declare a
dependency. A known library is reported with its pom dependency when the
runtime is a Maven one (main, spring-boot, quarkus); with the CLI it is
downloaded on compile, so nothing is said. The runtime is a parameter, wired to
the CLI value in the validate path; the MCP tool can pass its runtime next.
## Tests
- camel-groovy `GroovyCompilePreProcessorTest`: a registered pre-processor
sees the script; the message on an unresolved class. Module tests 105 green.
- camel-kamelet-main `JavaKnownImportsDownloaderTest`: Java and Groovy
imports, static, wildcard.
- camel-jbang-core `GroovyImportChecksTest`: CLI (unknown reported, known
silent, JDK/Camel/project skipped), Maven runtime (known named with the pom
dependency), inline expression. The `commands.ai` package green.
- The groovy example run through the CLI without its dependency line, as
above.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01Bp3538HRBPMQkb5ta9xRaj
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
