oscerd opened a new issue, #1787: URL: https://github.com/apache/camel-kafka-connector/issues/1787
## Description The `connectors/` directory contains 202 generated connector modules with 588 Java files. Nearly 100% of each module is boilerplate — the Connector and Task classes are structurally identical across all modules (only the class name and component-name string differ). The pom.xml, assembly descriptor, LICENSE, and NOTICE files are identical copies. The only truly unique data per connector is the list of Camel component/kamelet options in the ConnectorConfig class, which comes from the Camel Catalog at generation time. This creates a large maintenance surface and makes PRs that touch the generator hard to review (hundreds of files change). ## Current state Each generated connector module (e.g. `camel-aws2-iam-kafka-connector`) contains: - **Connector class** (~7 lines of real code) — delegates `config()` and `taskClass()`, identical structure across all 202 modules - **Task class** (~10 lines) — returns component name as default config, identical structure - **ConnectorConfig class** (~200+ lines) — static `String`/`Boolean` constants for every endpoint option plus a `conf()` method registering them with Kafka's `ConfigDef`. This is the only file with connector-specific content, but follows a mechanical pattern - **pom.xml** — generated from FreeMarker template, declares Kafka Connect API + single Camel component dependency - **package.xml, LICENSE.txt, NOTICE.txt** — identical boilerplate across all modules The generation is driven by `camel-kafka-connector-generator-maven-plugin` (in `tooling/`), which iterates over the Camel Catalog and Kamelets Catalog using FreeMarker templates. ## Improvement ideas ### Option A: Consolidate Connector/Task into base classes The generated Connector and Task classes contain no unique logic — they just return a class name and a component name string. These could be replaced by a single generic base class in `core` that takes the component name as a constructor parameter, eliminating 404 generated Java files (2 per connector × 202 connectors). ### Option B: Move ConnectorConfig to a descriptor-driven approach Instead of generating a Java class with hundreds of static constants, generate a JSON/YAML descriptor that a generic `CamelConnectorConfig` base class reads at runtime. This would: - Eliminate the largest generated file per connector - Make config changes a data-only change (no recompilation needed) - Simplify the generator significantly ### Option C: Reduce identical file duplication - Share a single `LICENSE.txt` and `NOTICE.txt` at the parent level instead of copying into each module - Use Maven's assembly plugin inheritance to share `package.xml` ### Option D: Generator improvements - The generator has a TODO at `GenerateCamelKafkaConnectorsMojo.java:206` for adding kamelet include filtering — implementing this would let developers regenerate a subset during development - Improve FreeMarker templates to reduce diff noise when the generator changes ## Recommended approach Start with Option A (highest impact, lowest risk) — consolidate Connector/Task into parameterized base classes. Then evaluate Option B for ConnectorConfig consolidation. Options C and D are incremental improvements that can happen independently. -- 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]
