Utility to generate/scaffold an extension for a camel component

[lburgazzoli]

We should have an utility like https://github.com/apache/camel-spring-boot#creating--deleting-starters to generate/scaffold an extension out of a camel component

[lburgazzoli]

Depends on https://issues.apache.org/jira/browse/CAMEL-14394

[lburgazzoli]

Would be nice if such tool could automatically create the quarkus-extension.yaml taking info from the Apache Camel Catalog

[lburgazzoli]

/cc @ppalaga

[ppalaga]

I have the tool in a state where it is generating what I think is the right code. Now let's discuss the tree structure.

JVM-only Extensions

As I said I'd prefer to have the JVM-only extensions in a separate directory.

Current:

.
├── ...
├── extensions
├── extensions-core
├── extensions-support
└── ...

Proposed:

.
├── ...
├── extensions
├── extensions-core
├── extensions-support
├── extensions-JVM
└── ...

Itests of JVM-only Extensions

I am not 100% sure what would be the best solution. I prefer having the itest as close as possible in the source tree to the corresponding extension to eliminate as much scrolling and clicking in the IDE. The most straightforward way to reach it would be

├── ...
├── extensions-jvm
│   ├── extension-1
│   │   ├── deployment
│   │   ├── runtime
│   │   └── integration-test
│   ├── extension-2
│   │   ├── deployment
│   │   ├── runtime
│   │   └── integration-test
│   ├── ...
└── ...

Pros/cons:

• Easy to move the whole extension to the appropriate directory when promoting from the JVM-only state to the full support.
• Wild idea: We should have isolated per extension tests for all new and existing extensions. The grouping of itests, that we currently do to reduce the CI times should be done by a tool that would merge several isolated itests into one. The isolated itests should be run by the CI regularly at least in the JVM mode to make sure that the dependencies are correct. The isolated itests should be run in the native mode on demand, e.g. before the release.

WDYT?

[lburgazzoli]

No objection on my side, we can also think about moving individual extension integrations tests to the extension them-self and leave in the integration-tests folders only aggregate tests

[ppalaga]

mvn cq:create -N -Dcq.artifactIdBase=foo fulfills the named requirements, IMO. Can we close this @lburgazzoli ?