CAMEL-21208: Replace manual string-based code generation with FreeMarker templates#22200
CAMEL-21208: Replace manual string-based code generation with FreeMarker templates#22200
Conversation
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
💡 Manual integration tests recommended:
|
| String ftlName = "Dockerfile" + javaVersion + ".ftl"; | ||
| String context; | ||
| try { | ||
| Map<String, Object> model = new HashMap<>(); |
There was a problem hiding this comment.
can this be extracted to avoid code duplication?
There was a problem hiding this comment.
Claude Code on behalf of Guillaume Nodet
Good catch. Looking at this more carefully — the Dockerfile template rendering now uses FreeMarker through the base class, and the Quarkus override handles the fast-jar vs uber-jar distinction which genuinely needs different logic. So the apparent duplication in Export.java line 311 is the shared base implementation. Will add a clarifying comment.
|
Hey AI agent, please rebase and resolve the conflict |
a02cd76 to
2870d10
Compare
orpiske
left a comment
There was a problem hiding this comment.
Thanks for looking at this ... it's great to see this cleanup on the code base.
| * @param model the data model | ||
| * @return the processed template output | ||
| */ | ||
| public static String processTemplate(String templateName, Map<String, Object> model) throws IOException { |
There was a problem hiding this comment.
Maybe cover this one with a brief test to ensure future work doesn't break it?
There was a problem hiding this comment.
Added TemplateHelperTest with 6 tests covering: simple interpolation, license header stripping, conditional rendering ([#if]), list rendering ([#list]), Maven expression pass-through (${...}), and missing template error handling.
Claude Code on behalf of Guillaume Nodet
|
What's the status? Is it ready for another review round? If yes, you should re-request a review from Croway so that he can be aware of it |
Yes it is. |
|
@gnodet I just did a rerun of all the jobs, by any chance did you run dsl/camel-jbang/camel-jbang-it tests? otherwise we can go YOLO and test on the Jenkins CI directly |
|
Claude Code on behalf of Guillaume Nodet @Croway Yes, I ran the ExportITCase results: 11 tests run, 0 failures, 0 errors, 2 skipped (the skipped tests require custom Quarkus system properties or container-only tags). All export scenarios pass — Spring Boot, Quarkus, Camel Main, export with files, export with agent, export with JMX management, export with CLI connector, and export with Camel config. |
696d7c8 to
8a25f22
Compare
|
Claude Code on behalf of Guillaume Nodet CI failures are unrelated to this PR — |
…ker templates in camel-jbang
- Add FreeMarker 2.3.34 dependency to camel-jbang-core
- Create TemplateHelper utility using square bracket syntax ([=var], [#if]...[/#if])
to avoid conflicts with ${...} (Maven) and <...> (XML) in generated content
- Convert all 23 .tmpl template files to .ftl FreeMarker templates
- Refactor Export*, Run, and Init commands to use TemplateHelper instead of
manual StringBuilder/replaceAll/replaceFirst code generation
- Extract shared helpers (buildRepositoryList, buildDependencyList, formatBuildProperties,
mavenGavComparator) into ExportBaseCommand
- Maintain backward compatibility for catalog-provided templates in ExportSpringBoot
- Remove 4 unreferenced templates (main-docker-*.tmpl, main-jkube-pom.tmpl)
- Keep deprecated bind templates (.tmpl) used by TemplateProvider
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add backward compat check for old .tmpl catalog template name in ExportSpringBoot - Remove dead model variables (CamelVersion, QuarkusManagementPort) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Remove unnecessary bare block in Run.generateOpenApi (leftover from try-with-resources) - Deduplicate model building in Export.copyDockerFiles Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Comprehensive test coverage for all 23 FreeMarker templates:
- FreeMarker-processed templates (processTemplate): code-java, main,
spring-boot-main, Dockerfile21/25, readme, readme.native,
rest-dsl.yaml, run-custom-camel-version, main-pom (with deps,
repos, jib/jkube), spring-boot-pom, quarkus-pom
- Init templates (raw text loading): java, yaml, xml, kamelet
source/sink/action, pipe, integration
Tests verify: license header stripping, placeholder resolution,
conditional rendering, list iteration, Maven ${} passthrough,
Kamelet {{}} passthrough, and missing template error handling.
Also regenerate jbang command docs after rebase.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
8a25f22 to
c482a0d
Compare
JIRA: CAMEL-21208
Summary
.tmplfiles with.ftlFreeMarker templates using square-bracket syntax ([=var],[#if],[#list]) to avoid conflicts with Maven${...}and XML<...>syntaxTemplateHelperutility class that configures FreeMarker withSQUARE_BRACKET_INTERPOLATION_SYNTAXandSQUARE_BRACKET_TAG_SYNTAX, and strips<#-- -->license headers from outputExportCamelMain,ExportSpringBoot,ExportQuarkus,Export,Run, andKubernetesExportto build model maps and callTemplateHelper.processTemplate()instead of manual regex/string replacementsExportBaseCommand:buildRepositoryList(),buildDependencyList(),formatBuildProperties()main-pom.ftlExportSpringBootfor catalog-provided.tmpltemplates (falls back to legacy regex processing)Init.javafor both old{{ .Name }}and new[=Name]placeholder syntax.tmplwithTemplateProviderinterface) unchanged — separate subsystem${...}passthrough, Kamelet{{...}}passthrough, and error handlingTest plan
TemplateHelper.processTemplate()${...}expressions pass through untouched in POM templates{{...}}expressions pass through untouched in kamelet templatesIOException