[
https://issues.apache.org/jira/browse/CAMEL-21049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141151#comment-18141151
]
Claus Ibsen commented on CAMEL-21049:
-------------------------------------
A concrete case of the version cycle described here: CAMEL-22857 (PR
https://github.com/apache/camel/pull/29461) makes Jackson 3 the primary Jackson
line in 4.24. In Camel JBang, camel-kamelet-main brings camel-jackson3, so the
json, avroJackson and protobufJackson data formats resolve to Jackson 3.
Camel 4.24.0 would ship with the 4.23.0 Kamelets catalog
(camel-kamelets-catalog-version in parent/pom.xml). Several of those Kamelets
use Jackson 2 classes, for example unmarshalType:
com.fasterxml.jackson.databind.JsonNode in json-deserialize-action, and the
same in json-serialize-action, the avro and protobuf (de)serialize actions, the
S3, Ceph and Azure Storage Blob event-based sources, resolve-pojo-schema-action
and the kafka field actions. A plain camel run on 4.24.0 would have them broken
out of the box, unless a Kamelets release comes out ahead of Camel 4.24.0.
With the Kamelets in this repository, the same PR would have updated them, and
CI would have caught the breakage.
Claude Code on behalf of davsclaus
> Consider moving Kamelets to Camel
> ---------------------------------
>
> Key: CAMEL-21049
> URL: https://issues.apache.org/jira/browse/CAMEL-21049
> Project: Camel
> Issue Type: Improvement
> Components: camel-kamelet
> Reporter: Christoph Deppisch
> Priority: Major
> Fix For: 4.x
>
>
> Kamelets represent declarative route templates in Apache Camel. The Kamelets
> were born out of Camel K but soon became part of the Apache Camel project,
> too. This means today you can use Kamelets in Apache Camel also without Camel
> K being involved.
> Kamelets are still kind of separated from the Camel core project. The
> Kamelets live in a separate GitHub project repository
> (https://github.com/apache/camel-kamelets) and follow a separate release
> lifecycle. This means we do a follow-up release of the Kamelet catalog after
> each Apache Camel release in order to keep the Kamelets aligned with the most
> recent Camel versions.
> In addition to that, writing and maintaining Kamelets is no fun as it boils
> down to writing YAML files manually. Testing and verifying the Kamelets is
> separated from the Camel core project, too.
> Problems that arise due to separate GitHub repositories for Apache Camel and
> Kamelets:
> * Separate Kamelet catalog release lifecycle
> * camel-kamelets-utils library that provides useful exchange body
> manipulation utilities (e.g. hoist-flied) is only available with Kamelets
> * Cyclic dependency between project versions:
> Kamelets → Apache Camel → Camel JBang → Kamelets
> * Separate issue tracking system: Camel JIRA vs. GitHub issues
> * Testing and verification of Kamelets separate from Camel release. It is
> hard to sense changes in Camel components that affect Kamelets and potential
> issues are revealed and fixed late in the release life cycle
> Problems with YAML as Kamelet definition:
> * No compile time checks
> * Poor code assistance
> * Writing YAML files is cumbersome
> * Separated from usual Camel component development
> The proposal is to bring Kamelets to the Camel core project in order to make
> them a natural part of the Camel components.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
