Migrate camel-k-runtime quarkus extensions into camel-quarkus

[claudio4j]

camel-k-runtime used to host some camel components and its quarkus extensions suitable for camel-k project, however today all camel components are already in camel, only the quarkus extensions remained in camel-k-runtime project.

It seems appropriate to move all camel-k-runtime quarkus extensions into camel-quarkus project.

[claudio4j]

I plan to work on this on a personal branch and later requesting review.

[claudio4j]

Inspecting the camel-k-runtime project, these are the structure and aspects to be migrated to camel-quarkus

• docs: These pages lists the languages and how it works in Camel K, this is specific to Camel K and should not me migrated to camel-quarkus, but shoud go to Camel K documentation. They are published in Camel K website
• examples: Migrate to https://github.com/apache/camel-quarkus-examples
• camel-k-* quarkus extensions: Migrate to camel-quarkus, some of them like cloudevents, cron, knative, master, webhook already exists in camel-quarkus, but are different. Other extensions as resume-kafka, runtime, are not present. These migrations are expected to be the main effort to bring into camel-quarkus
• itests: Migrate as the quarkus extensions above.
• catalog: Adapt to the camel-quarkus catalog and extend it whenever necessary.

There are some aspects relevant only to Camel K and we should not add these concerns to camel-quarkus, but look for ways to adapt Camel K to use camel-quarkus directly, this is yet to be discovered along the migration process.

[jamesnetherton]

examples: Migrate to https://github.com/apache/camel-quarkus-examples

I don't see those camel-k-runtime example projects adding any real value given that we have camel-k-examples.

[claudio4j]

I don't see those camel-k-runtime example projects adding any real value given that we have camel-k-examples.

I haven't look in detail the camel-k-runtime examples yet, but if they are perceived as not relevant for camel-quarkus, we are going to see another home for them.

[lburgazzoli]

We can remove them, they were mainly meant to provide some quickstart to test/debug things

[lburgazzoli]

* `catalog`: Adapt to the camel-quarkus catalog and extend it whenever necessary.

Note that this is not the same catalog as the camel one, it is used by camel-k to resolve artifacts and other capabilities. There is also a plugin to generate it.

[claudio4j]

I noticed most of the projects remaining in camel-k-runtime/support were built targeting camel-k, I am still investigating how to migrate them to camel quarkus, any ideas are welcome.

[claudio4j]

A description of each module (comprising of code), worth migrating.

Component name | Notes -- | -- camel-k-cloudevents | There is no customization in ck-runtime. Don't migrate. camel-k-cron | @LoaderInterceptor @ConfigurerThere is CronShutdownStrategy to stop the camel context when there is a completed or failed event. Migrate CronShutdownStrategy to camel-quarkus and set a parameter to enable it ? camel-k-knative | @LoaderInterceptor @Configurer contain code to automatically set the sinkbinding. camel-k-master | @Customizer, @LoaderInterceptor \@Configurer contain code to use the kubernetes lease mechanism to control the master route. camel-k-resume-kafka | \@Customizer resume strategy to resume processing of camel routes. camel-k-runtimecamel-k-core | There are similar implementations in camel-quarkus, move them accordingly. camel-k-webhook | Unsure if it's relevant to camel-quarkus or camel-k. support/  camel-k-annotations  camel-k-apt | What would be the augmentation in the build phase to generate the camel marker files ? support/  camel-k-catalog  camel-k-catalog-model  camel-k-maven-plugin | The Yaml catalog is the artifact used by camel-k-operator to resolve dependencies.The camel-k-maven-plugin generates the yaml catalog file. camel-k-maven-logging | Structural log of maven output camel-k-runtime-bom | This BOM is imported in the generated integration project created by camel-k-operator

[zbendhiba]

camel-k-master, there's a PR that has been merged already https://github.com/apache/camel-quarkus/commit/17c9fdcfed19b14b12cbde928cd88aad31bb50ff

[claudio4j]

I migrated the camel-k-core and camel-k-runtime and their respective tests my camel-quarkus repository, branch merge_ckr for an early review

[claudio4j]

There are some parts that requires more investigation, like the use an existing camel-quarkus Runtime interface, instead of the one in the k-core/api package Also, there are some tests disabled due to failures in the CamelContextCustomizer tests, which I am investigating. There is the ApplicationConfigSourceProvider which I will see if it is really necessary to depend on microprofile config. Any feedback is welcome.

[jamesnetherton]

Wont do for now. The initial work was reverted in https://github.com/apache/camel-quarkus/pull/6388.

We have backups in the form the 3.14.x branch and the previous release tags.