You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iceberg.apache.org by Robin Moffatt via dev <de...@iceberg.apache.org> on 2026/01/22 17:20:31 UTC
Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Hi,
Currently, the version of the Iceberg connector for Kafka Connect
on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
through an ad-hoc process, which we would like to help the Apache Iceberg
community formalise.
Previously, Tabular owned the connector, and its inclusion in Confluent Hub
was managed through the commercial partnership between the two companies.
I've put together a draft PR [1] with a script that builds and packages the
connector for submission to Confluent Hub [2] (now called Confluent
Marketplace).
Please review the PR's proposed process, and let me know what you think.
I'm happy to liaise between the community and the Confluent team here to
find a process that works for everyone.
thanks,
Robin
1: https://github.com/apache/iceberg/pull/15113
2: https://hub.confluent.io
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Kevin Liu <ke...@apache.org>.
I dont see a github workflow to publish docker image in the PR. But I think
it would be good to publish with this feature enabled.
We can include in the iceberg-rest-fixture docker publish github workflow,
https://github.com/apache/iceberg/blob/main/.github/workflows/publish-iceberg-rest-fixture-docker.yml
On Fri, Feb 20, 2026 at 8:47 AM Robin Moffatt via dev <
dev@iceberg.apache.org> wrote:
> Great. I'm happy to have a go at adding that.
> Do you think that should be a pre-req for this PR [1]? Or done
> subsequently?
>
> [1]: https://github.com/apache/iceberg/pull/15212
>
> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
>
>> Sounds like a good idea to incorporate trivy. There are other apache
>> projects using trivy as part of their build/publish step for docker
>> containers. Heres one from apache/superset,
>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>>
>> We can emulate that in our pipeline
>>
>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
>> dev@iceberg.apache.org> wrote:
>>
>>> Hi Dan,
>>> Thanks for the review on the PR.
>>>
>>> One thing that's come up internally is that the Confluent team use trivy
>>> [1] to scan for CVEs as a mandatory step before listing a connector. This
>>> has flagged CVEs previously (e.g. [2]) that needed patching.
>>>
>>> Can you suggest what the best way to incorporate this into the release
>>> workflow might be?
>>> As it stands, it's only the finalised release that's sent to Confluent
>>> and then scanned; should the trivy step be further upstream in the release
>>> process so that CVEs are patched before the final release is made?
>>>
>>> thanks, Robin.
>>>
>>> [1] https://trivy.dev/
>>> [2] https://github.com/apache/iceberg/pull/14985
>>>
>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>>
>>>> I'll take a look tomorrow. This would be great to land and validate
>>>> with the 1.11 release.
>>>>
>>>> -Dan
>>>>
>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>>>>
>>>>> Hi Dan,
>>>>> I've addressed your comments on the PR, could you take another look
>>>>> please?
>>>>>
>>>>> Thanks, Robin
>>>>>
>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>>
>>>>>> Hey Robin,
>>>>>>
>>>>>> Sorry for not responding to the last email, but this looks like the
>>>>>> right approach. A couple small comments on the PR, but other than that
>>>>>> this looks good.
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>
>>>>>>> I've reworked the process based on the feedback into:
>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>>
>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>>
>>>>>>> thanks, Robin.
>>>>>>>
>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>>> released artifacts and provenance angle here.
>>>>>>>>
>>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>>> artifact as part of the gradle release command?
>>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>>
>>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>>
>>>>>>>> thanks, Robin
>>>>>>>>
>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>>>> good to highlight this here.
>>>>>>>>>
>>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>>> are part of the release process.
>>>>>>>>>
>>>>>>>>> It might be good to include the instructions on how this fits into
>>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/>
>>>>>>>>> so we understand the full workflow along with the script.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>>
>>>>>>>>>> thanks, Robin.
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>
>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka
>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff manually
>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help
>>>>>>>>>>> the Apache Iceberg community formalise.
>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>>> two companies.
>>>>>>>>>>>
>>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>>
>>>>>>>>>>> Please review the PR's proposed process, and let me know what
>>>>>>>>>>> you think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Robin
>>>>>>>>>>>
>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Great. I'm happy to have a go at adding that.
Do you think that should be a pre-req for this PR [1]? Or done subsequently?
[1]: https://github.com/apache/iceberg/pull/15212
On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
> Sounds like a good idea to incorporate trivy. There are other apache
> projects using trivy as part of their build/publish step for docker
> containers. Heres one from apache/superset,
> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>
> We can emulate that in our pipeline
>
> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
> dev@iceberg.apache.org> wrote:
>
>> Hi Dan,
>> Thanks for the review on the PR.
>>
>> One thing that's come up internally is that the Confluent team use trivy
>> [1] to scan for CVEs as a mandatory step before listing a connector. This
>> has flagged CVEs previously (e.g. [2]) that needed patching.
>>
>> Can you suggest what the best way to incorporate this into the release
>> workflow might be?
>> As it stands, it's only the finalised release that's sent to Confluent
>> and then scanned; should the trivy step be further upstream in the release
>> process so that CVEs are patched before the final release is made?
>>
>> thanks, Robin.
>>
>> [1] https://trivy.dev/
>> [2] https://github.com/apache/iceberg/pull/14985
>>
>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>
>>> I'll take a look tomorrow. This would be great to land and validate
>>> with the 1.11 release.
>>>
>>> -Dan
>>>
>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>>>
>>>> Hi Dan,
>>>> I've addressed your comments on the PR, could you take another look
>>>> please?
>>>>
>>>> Thanks, Robin
>>>>
>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>
>>>>> Hey Robin,
>>>>>
>>>>> Sorry for not responding to the last email, but this looks like the
>>>>> right approach. A couple small comments on the PR, but other than that
>>>>> this looks good.
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>> dev@iceberg.apache.org> wrote:
>>>>>
>>>>>> I've reworked the process based on the feedback into:
>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>
>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>
>>>>>> thanks, Robin.
>>>>>>
>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>> released artifacts and provenance angle here.
>>>>>>>
>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>> artifact as part of the gradle release command?
>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>
>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>
>>>>>>> thanks, Robin
>>>>>>>
>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>>> good to highlight this here.
>>>>>>>>
>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>> are part of the release process.
>>>>>>>>
>>>>>>>> It might be good to include the instructions on how this fits into
>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/>
>>>>>>>> so we understand the full workflow along with the script.
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>
>>>>>>>>> thanks, Robin.
>>>>>>>>>
>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>
>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>>>>>> community formalise.
>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>> two companies.
>>>>>>>>>>
>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>
>>>>>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Robin
>>>>>>>>>>
>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Daniel Weeks <da...@gmail.com>.
Robin,
I think we should probably just go with the non-blocking approach initially
and see if there's any real friction. Maybe the 1.11 release would be a
good candidate to test this workflow with.
If we complete a release but find a vulnerability before pushing the
artifacts, we could follow up quickly with a patch release.
-Dan
On Mon, Mar 9, 2026 at 2:26 AM Robin Moffatt via dev <de...@iceberg.apache.org>
wrote:
> Hi Dan,
>
> Following up on this - let me know if you have any more thoughts/questions
> on it.
>
> thanks, Robin.
>
> On Mon, 2 Mar 2026 at 12:18, Robin Moffatt <ro...@confluent.io> wrote:
>
>> Hi Dan,
>>
>> These are good questions, ones to which I don't necessarily have the
>> answers :) I'm looking to release managers to guide me here on what would
>> be good practice really.
>>
>> > How do we ensure that this doesn't become a problem for CI (looks like
>> it's report only right now, so a new CVE doesn't start failing all builds)
>> and how do we prevent releasing with CVEs that would then block publishing
>> the artifacts.
>>
>> My suggestion would be:
>> 1. PRs: Don't fail the build. Add a comment to the PR highlighting any
>> CVEs present.
>> 2. Push: Fail the build. Trivy supports .trivyignore [1] if we need to
>> override it for CVEs that do not apply
>>
>> > Is this all manual at this point (release manager needs to validate
>> CVEs)?
>>
>> CVEs introduced by dependency changes would get caught at the PR stage.
>> Newly disclosed CVEs against existing dependencies would show up on push
>> to main (or via a periodic scan if we add one), and RMs would need to
>> manually validate during the release process.
>>
>> WDYT?
>>
>> thanks, Robin.
>>
>> [1] https://trivy.dev/docs/latest/configuration/filtering/#trivyignore
>>
>>
>>
>> On Fri, 27 Feb 2026 at 17:31, Daniel Weeks <dw...@apache.org> wrote:
>>
>>> I agree that if the CVE scan is a requirement for publishing, we should
>>> incorporate it into the CI/release process.
>>>
>>> However, I've run into situations in the past where CVE scanners flags
>>> things that do not apply and create friction during release.
>>>
>>> How do we ensure that this doesn't become a problem for CI (looks like
>>> it's report only right now, so a new CVE doesn't start failing all builds)
>>> and how do we prevent releasing with CVEs that would then block publishing
>>> the artifacts.
>>>
>>> Is this all manual at this point (release manager needs to validate
>>> CVEs)?
>>>
>>> I'm just trying to understand what this workflow will look like in
>>> practice.
>>>
>>> -Dan
>>>
>>>
>>>
>>> On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev <
>>> dev@iceberg.apache.org> wrote:
>>>
>>>> I've raised a second PR [1] that adds a trivy step to the existing
>>>> Kafka Connect workflow [2].
>>>> This would flag CVEs both during PR CI (catching vulnerabilities in
>>>> current dependencies) and when a release candidate tag is created (catching
>>>> newly-disclosed CVEs against previously merged code).
>>>>
>>>> This PR and the previous one [3] are related but not dependent on each
>>>> other.
>>>>
>>>> thanks, Robin.
>>>>
>>>> [1]: https://github.com/apache/iceberg/pull/15430
>>>> [2]:
>>>> https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml
>>>> [3]: https://github.com/apache/iceberg/pull/15212
>>>>
>>>> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
>>>>
>>>>> Sounds like a good idea to incorporate trivy. There are other apache
>>>>> projects using trivy as part of their build/publish step for docker
>>>>> containers. Heres one from apache/superset,
>>>>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>>>>>
>>>>> We can emulate that in our pipeline
>>>>>
>>>>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
>>>>> dev@iceberg.apache.org> wrote:
>>>>>
>>>>>> Hi Dan,
>>>>>> Thanks for the review on the PR.
>>>>>>
>>>>>> One thing that's come up internally is that the Confluent team use
>>>>>> trivy [1] to scan for CVEs as a mandatory step before listing a connector.
>>>>>> This has flagged CVEs previously (e.g. [2]) that needed patching.
>>>>>>
>>>>>> Can you suggest what the best way to incorporate this into the
>>>>>> release workflow might be?
>>>>>> As it stands, it's only the finalised release that's sent to
>>>>>> Confluent and then scanned; should the trivy step be further upstream in
>>>>>> the release process so that CVEs are patched before the final release is
>>>>>> made?
>>>>>>
>>>>>> thanks, Robin.
>>>>>>
>>>>>> [1] https://trivy.dev/
>>>>>> [2] https://github.com/apache/iceberg/pull/14985
>>>>>>
>>>>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>>>>>
>>>>>>> I'll take a look tomorrow. This would be great to land and validate
>>>>>>> with the 1.11 release.
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Dan,
>>>>>>>> I've addressed your comments on the PR, could you take another look
>>>>>>>> please?
>>>>>>>>
>>>>>>>> Thanks, Robin
>>>>>>>>
>>>>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey Robin,
>>>>>>>>>
>>>>>>>>> Sorry for not responding to the last email, but this looks like
>>>>>>>>> the right approach. A couple small comments on the PR, but other than that
>>>>>>>>> this looks good.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> I've reworked the process based on the feedback into:
>>>>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle
>>>>>>>>>> release
>>>>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>>>>>
>>>>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>>>>>
>>>>>>>>>> thanks, Robin.
>>>>>>>>>>
>>>>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Daniel,
>>>>>>>>>>>
>>>>>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>>>>>> released artifacts and provenance angle here.
>>>>>>>>>>>
>>>>>>>>>>> So would the right direction here be to include the Kafka
>>>>>>>>>>> Connect artifact as part of the gradle release command?
>>>>>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>>>>>
>>>>>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>>>>>
>>>>>>>>>>> thanks, Robin
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I added some comments to this effect in the PR, but it's
>>>>>>>>>>>> probably good to highlight this here.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think we should be generating new artifacts to upload
>>>>>>>>>>>> to connect/hub, but rather referencing the voted and released artifacts
>>>>>>>>>>>> that are part of the release process.
>>>>>>>>>>>>
>>>>>>>>>>>> It might be good to include the instructions on how this fits
>>>>>>>>>>>> into the release process
>>>>>>>>>>>> <https://iceberg.apache.org/how-to-release/> so we understand
>>>>>>>>>>>> the full workflow along with the script.
>>>>>>>>>>>>
>>>>>>>>>>>> -Dan
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could I ask for input on this please, or a review of the
>>>>>>>>>>>>> PR[1]?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks, Robin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <
>>>>>>>>>>>>> robin@confluent.io> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka
>>>>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff manually
>>>>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help
>>>>>>>>>>>>>> the Apache Iceberg community formalise.
>>>>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>>>>>> two companies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've put together a draft PR [1] with a script that builds
>>>>>>>>>>>>>> and packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review the PR's proposed process, and let me know what
>>>>>>>>>>>>>> you think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>> Robin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>>
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi Dan,
Following up on this - let me know if you have any more thoughts/questions
on it.
thanks, Robin.
On Mon, 2 Mar 2026 at 12:18, Robin Moffatt <ro...@confluent.io> wrote:
> Hi Dan,
>
> These are good questions, ones to which I don't necessarily have the
> answers :) I'm looking to release managers to guide me here on what would
> be good practice really.
>
> > How do we ensure that this doesn't become a problem for CI (looks like
> it's report only right now, so a new CVE doesn't start failing all builds)
> and how do we prevent releasing with CVEs that would then block publishing
> the artifacts.
>
> My suggestion would be:
> 1. PRs: Don't fail the build. Add a comment to the PR highlighting any
> CVEs present.
> 2. Push: Fail the build. Trivy supports .trivyignore [1] if we need to
> override it for CVEs that do not apply
>
> > Is this all manual at this point (release manager needs to validate
> CVEs)?
>
> CVEs introduced by dependency changes would get caught at the PR stage.
> Newly disclosed CVEs against existing dependencies would show up on push
> to main (or via a periodic scan if we add one), and RMs would need to
> manually validate during the release process.
>
> WDYT?
>
> thanks, Robin.
>
> [1] https://trivy.dev/docs/latest/configuration/filtering/#trivyignore
>
>
>
> On Fri, 27 Feb 2026 at 17:31, Daniel Weeks <dw...@apache.org> wrote:
>
>> I agree that if the CVE scan is a requirement for publishing, we should
>> incorporate it into the CI/release process.
>>
>> However, I've run into situations in the past where CVE scanners flags
>> things that do not apply and create friction during release.
>>
>> How do we ensure that this doesn't become a problem for CI (looks like
>> it's report only right now, so a new CVE doesn't start failing all builds)
>> and how do we prevent releasing with CVEs that would then block publishing
>> the artifacts.
>>
>> Is this all manual at this point (release manager needs to validate CVEs)?
>>
>> I'm just trying to understand what this workflow will look like in
>> practice.
>>
>> -Dan
>>
>>
>>
>> On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev <
>> dev@iceberg.apache.org> wrote:
>>
>>> I've raised a second PR [1] that adds a trivy step to the existing Kafka
>>> Connect workflow [2].
>>> This would flag CVEs both during PR CI (catching vulnerabilities in
>>> current dependencies) and when a release candidate tag is created (catching
>>> newly-disclosed CVEs against previously merged code).
>>>
>>> This PR and the previous one [3] are related but not dependent on each
>>> other.
>>>
>>> thanks, Robin.
>>>
>>> [1]: https://github.com/apache/iceberg/pull/15430
>>> [2]:
>>> https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml
>>> [3]: https://github.com/apache/iceberg/pull/15212
>>>
>>> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
>>>
>>>> Sounds like a good idea to incorporate trivy. There are other apache
>>>> projects using trivy as part of their build/publish step for docker
>>>> containers. Heres one from apache/superset,
>>>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>>>>
>>>> We can emulate that in our pipeline
>>>>
>>>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
>>>> dev@iceberg.apache.org> wrote:
>>>>
>>>>> Hi Dan,
>>>>> Thanks for the review on the PR.
>>>>>
>>>>> One thing that's come up internally is that the Confluent team use
>>>>> trivy [1] to scan for CVEs as a mandatory step before listing a connector.
>>>>> This has flagged CVEs previously (e.g. [2]) that needed patching.
>>>>>
>>>>> Can you suggest what the best way to incorporate this into the release
>>>>> workflow might be?
>>>>> As it stands, it's only the finalised release that's sent to Confluent
>>>>> and then scanned; should the trivy step be further upstream in the release
>>>>> process so that CVEs are patched before the final release is made?
>>>>>
>>>>> thanks, Robin.
>>>>>
>>>>> [1] https://trivy.dev/
>>>>> [2] https://github.com/apache/iceberg/pull/14985
>>>>>
>>>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>>>>
>>>>>> I'll take a look tomorrow. This would be great to land and validate
>>>>>> with the 1.11 release.
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Dan,
>>>>>>> I've addressed your comments on the PR, could you take another look
>>>>>>> please?
>>>>>>>
>>>>>>> Thanks, Robin
>>>>>>>
>>>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hey Robin,
>>>>>>>>
>>>>>>>> Sorry for not responding to the last email, but this looks like the
>>>>>>>> right approach. A couple small comments on the PR, but other than that
>>>>>>>> this looks good.
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>
>>>>>>>>> I've reworked the process based on the feedback into:
>>>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle
>>>>>>>>> release
>>>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>>>>
>>>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>>>>
>>>>>>>>> thanks, Robin.
>>>>>>>>>
>>>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Daniel,
>>>>>>>>>>
>>>>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>>>>> released artifacts and provenance angle here.
>>>>>>>>>>
>>>>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>>>>> artifact as part of the gradle release command?
>>>>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>>>>
>>>>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>>>>
>>>>>>>>>> thanks, Robin
>>>>>>>>>>
>>>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I added some comments to this effect in the PR, but it's
>>>>>>>>>>> probably good to highlight this here.
>>>>>>>>>>>
>>>>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>>>>> are part of the release process.
>>>>>>>>>>>
>>>>>>>>>>> It might be good to include the instructions on how this fits
>>>>>>>>>>> into the release process
>>>>>>>>>>> <https://iceberg.apache.org/how-to-release/> so we understand
>>>>>>>>>>> the full workflow along with the script.
>>>>>>>>>>>
>>>>>>>>>>> -Dan
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks, Robin.
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka
>>>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff manually
>>>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help
>>>>>>>>>>>>> the Apache Iceberg community formalise.
>>>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>>>>> two companies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review the PR's proposed process, and let me know what
>>>>>>>>>>>>> you think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>> Robin
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>
>>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi Dan,
These are good questions, ones to which I don't necessarily have the
answers :) I'm looking to release managers to guide me here on what would
be good practice really.
> How do we ensure that this doesn't become a problem for CI (looks like
it's report only right now, so a new CVE doesn't start failing all builds)
and how do we prevent releasing with CVEs that would then block publishing
the artifacts.
My suggestion would be:
1. PRs: Don't fail the build. Add a comment to the PR highlighting any CVEs
present.
2. Push: Fail the build. Trivy supports .trivyignore [1] if we need to
override it for CVEs that do not apply
> Is this all manual at this point (release manager needs to validate CVEs)?
CVEs introduced by dependency changes would get caught at the PR stage.
Newly disclosed CVEs against existing dependencies would show up on push to
main (or via a periodic scan if we add one), and RMs would need to manually
validate during the release process.
WDYT?
thanks, Robin.
[1] https://trivy.dev/docs/latest/configuration/filtering/#trivyignore
On Fri, 27 Feb 2026 at 17:31, Daniel Weeks <dw...@apache.org> wrote:
> I agree that if the CVE scan is a requirement for publishing, we should
> incorporate it into the CI/release process.
>
> However, I've run into situations in the past where CVE scanners flags
> things that do not apply and create friction during release.
>
> How do we ensure that this doesn't become a problem for CI (looks like
> it's report only right now, so a new CVE doesn't start failing all builds)
> and how do we prevent releasing with CVEs that would then block publishing
> the artifacts.
>
> Is this all manual at this point (release manager needs to validate CVEs)?
>
> I'm just trying to understand what this workflow will look like in
> practice.
>
> -Dan
>
>
>
> On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev <
> dev@iceberg.apache.org> wrote:
>
>> I've raised a second PR [1] that adds a trivy step to the existing Kafka
>> Connect workflow [2].
>> This would flag CVEs both during PR CI (catching vulnerabilities in
>> current dependencies) and when a release candidate tag is created (catching
>> newly-disclosed CVEs against previously merged code).
>>
>> This PR and the previous one [3] are related but not dependent on each
>> other.
>>
>> thanks, Robin.
>>
>> [1]: https://github.com/apache/iceberg/pull/15430
>> [2]:
>> https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml
>> [3]: https://github.com/apache/iceberg/pull/15212
>>
>> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
>>
>>> Sounds like a good idea to incorporate trivy. There are other apache
>>> projects using trivy as part of their build/publish step for docker
>>> containers. Heres one from apache/superset,
>>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>>>
>>> We can emulate that in our pipeline
>>>
>>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
>>> dev@iceberg.apache.org> wrote:
>>>
>>>> Hi Dan,
>>>> Thanks for the review on the PR.
>>>>
>>>> One thing that's come up internally is that the Confluent team use
>>>> trivy [1] to scan for CVEs as a mandatory step before listing a connector.
>>>> This has flagged CVEs previously (e.g. [2]) that needed patching.
>>>>
>>>> Can you suggest what the best way to incorporate this into the release
>>>> workflow might be?
>>>> As it stands, it's only the finalised release that's sent to Confluent
>>>> and then scanned; should the trivy step be further upstream in the release
>>>> process so that CVEs are patched before the final release is made?
>>>>
>>>> thanks, Robin.
>>>>
>>>> [1] https://trivy.dev/
>>>> [2] https://github.com/apache/iceberg/pull/14985
>>>>
>>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>>>
>>>>> I'll take a look tomorrow. This would be great to land and validate
>>>>> with the 1.11 release.
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io>
>>>>> wrote:
>>>>>
>>>>>> Hi Dan,
>>>>>> I've addressed your comments on the PR, could you take another look
>>>>>> please?
>>>>>>
>>>>>> Thanks, Robin
>>>>>>
>>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>>>
>>>>>>> Hey Robin,
>>>>>>>
>>>>>>> Sorry for not responding to the last email, but this looks like the
>>>>>>> right approach. A couple small comments on the PR, but other than that
>>>>>>> this looks good.
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>
>>>>>>>> I've reworked the process based on the feedback into:
>>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>>>
>>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>>>
>>>>>>>> thanks, Robin.
>>>>>>>>
>>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>>>> released artifacts and provenance angle here.
>>>>>>>>>
>>>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>>>> artifact as part of the gradle release command?
>>>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>>>
>>>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>>>
>>>>>>>>> thanks, Robin
>>>>>>>>>
>>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>>>>> good to highlight this here.
>>>>>>>>>>
>>>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>>>> are part of the release process.
>>>>>>>>>>
>>>>>>>>>> It might be good to include the instructions on how this fits
>>>>>>>>>> into the release process
>>>>>>>>>> <https://iceberg.apache.org/how-to-release/> so we understand
>>>>>>>>>> the full workflow along with the script.
>>>>>>>>>>
>>>>>>>>>> -Dan
>>>>>>>>>>
>>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>>>
>>>>>>>>>>> thanks, Robin.
>>>>>>>>>>>
>>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka
>>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff manually
>>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help
>>>>>>>>>>>> the Apache Iceberg community formalise.
>>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>>>> two companies.
>>>>>>>>>>>>
>>>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>>>
>>>>>>>>>>>> Please review the PR's proposed process, and let me know what
>>>>>>>>>>>> you think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Robin
>>>>>>>>>>>>
>>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>
>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Daniel Weeks <dw...@apache.org>.
I agree that if the CVE scan is a requirement for publishing, we should
incorporate it into the CI/release process.
However, I've run into situations in the past where CVE scanners flags
things that do not apply and create friction during release.
How do we ensure that this doesn't become a problem for CI (looks like it's
report only right now, so a new CVE doesn't start failing all builds) and
how do we prevent releasing with CVEs that would then block publishing the
artifacts.
Is this all manual at this point (release manager needs to validate CVEs)?
I'm just trying to understand what this workflow will look like in practice.
-Dan
On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev <
dev@iceberg.apache.org> wrote:
> I've raised a second PR [1] that adds a trivy step to the existing Kafka
> Connect workflow [2].
> This would flag CVEs both during PR CI (catching vulnerabilities in
> current dependencies) and when a release candidate tag is created (catching
> newly-disclosed CVEs against previously merged code).
>
> This PR and the previous one [3] are related but not dependent on each
> other.
>
> thanks, Robin.
>
> [1]: https://github.com/apache/iceberg/pull/15430
> [2]:
> https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml
> [3]: https://github.com/apache/iceberg/pull/15212
>
> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
>
>> Sounds like a good idea to incorporate trivy. There are other apache
>> projects using trivy as part of their build/publish step for docker
>> containers. Heres one from apache/superset,
>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>>
>> We can emulate that in our pipeline
>>
>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
>> dev@iceberg.apache.org> wrote:
>>
>>> Hi Dan,
>>> Thanks for the review on the PR.
>>>
>>> One thing that's come up internally is that the Confluent team use trivy
>>> [1] to scan for CVEs as a mandatory step before listing a connector. This
>>> has flagged CVEs previously (e.g. [2]) that needed patching.
>>>
>>> Can you suggest what the best way to incorporate this into the release
>>> workflow might be?
>>> As it stands, it's only the finalised release that's sent to Confluent
>>> and then scanned; should the trivy step be further upstream in the release
>>> process so that CVEs are patched before the final release is made?
>>>
>>> thanks, Robin.
>>>
>>> [1] https://trivy.dev/
>>> [2] https://github.com/apache/iceberg/pull/14985
>>>
>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>>
>>>> I'll take a look tomorrow. This would be great to land and validate
>>>> with the 1.11 release.
>>>>
>>>> -Dan
>>>>
>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>>>>
>>>>> Hi Dan,
>>>>> I've addressed your comments on the PR, could you take another look
>>>>> please?
>>>>>
>>>>> Thanks, Robin
>>>>>
>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>>
>>>>>> Hey Robin,
>>>>>>
>>>>>> Sorry for not responding to the last email, but this looks like the
>>>>>> right approach. A couple small comments on the PR, but other than that
>>>>>> this looks good.
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>
>>>>>>> I've reworked the process based on the feedback into:
>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>>
>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>>
>>>>>>> thanks, Robin.
>>>>>>>
>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>>> released artifacts and provenance angle here.
>>>>>>>>
>>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>>> artifact as part of the gradle release command?
>>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>>
>>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>>
>>>>>>>> thanks, Robin
>>>>>>>>
>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>>>> good to highlight this here.
>>>>>>>>>
>>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>>> are part of the release process.
>>>>>>>>>
>>>>>>>>> It might be good to include the instructions on how this fits into
>>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/>
>>>>>>>>> so we understand the full workflow along with the script.
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>>
>>>>>>>>>> thanks, Robin.
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>
>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka
>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff manually
>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help
>>>>>>>>>>> the Apache Iceberg community formalise.
>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>>> two companies.
>>>>>>>>>>>
>>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>>
>>>>>>>>>>> Please review the PR's proposed process, and let me know what
>>>>>>>>>>> you think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Robin
>>>>>>>>>>>
>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>
> --
> *Robin Moffatt*
> *Sr. Principal Advisor, Streaming Data Technologies*
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
I've raised a second PR [1] that adds a trivy step to the existing Kafka
Connect workflow [2].
This would flag CVEs both during PR CI (catching vulnerabilities in current
dependencies) and when a release candidate tag is created (catching
newly-disclosed CVEs against previously merged code).
This PR and the previous one [3] are related but not dependent on each
other.
thanks, Robin.
[1]: https://github.com/apache/iceberg/pull/15430
[2]:
https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml
[3]: https://github.com/apache/iceberg/pull/15212
On Fri, 20 Feb 2026 at 15:02, Kevin Liu <ke...@apache.org> wrote:
> Sounds like a good idea to incorporate trivy. There are other apache
> projects using trivy as part of their build/publish step for docker
> containers. Heres one from apache/superset,
> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
>
> We can emulate that in our pipeline
>
> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
> dev@iceberg.apache.org> wrote:
>
>> Hi Dan,
>> Thanks for the review on the PR.
>>
>> One thing that's come up internally is that the Confluent team use trivy
>> [1] to scan for CVEs as a mandatory step before listing a connector. This
>> has flagged CVEs previously (e.g. [2]) that needed patching.
>>
>> Can you suggest what the best way to incorporate this into the release
>> workflow might be?
>> As it stands, it's only the finalised release that's sent to Confluent
>> and then scanned; should the trivy step be further upstream in the release
>> process so that CVEs are patched before the final release is made?
>>
>> thanks, Robin.
>>
>> [1] https://trivy.dev/
>> [2] https://github.com/apache/iceberg/pull/14985
>>
>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>>
>>> I'll take a look tomorrow. This would be great to land and validate
>>> with the 1.11 release.
>>>
>>> -Dan
>>>
>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>>>
>>>> Hi Dan,
>>>> I've addressed your comments on the PR, could you take another look
>>>> please?
>>>>
>>>> Thanks, Robin
>>>>
>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>>
>>>>> Hey Robin,
>>>>>
>>>>> Sorry for not responding to the last email, but this looks like the
>>>>> right approach. A couple small comments on the PR, but other than that
>>>>> this looks good.
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>>> dev@iceberg.apache.org> wrote:
>>>>>
>>>>>> I've reworked the process based on the feedback into:
>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>>
>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>>
>>>>>> thanks, Robin.
>>>>>>
>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>>> released artifacts and provenance angle here.
>>>>>>>
>>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>>> artifact as part of the gradle release command?
>>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>>
>>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>>
>>>>>>> thanks, Robin
>>>>>>>
>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>>> good to highlight this here.
>>>>>>>>
>>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>>> are part of the release process.
>>>>>>>>
>>>>>>>> It might be good to include the instructions on how this fits into
>>>>>>>> the release process <https://iceberg.apache.org/how-to-release/>
>>>>>>>> so we understand the full workflow along with the script.
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>>
>>>>>>>>> thanks, Robin.
>>>>>>>>>
>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>>
>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>>>>>> community formalise.
>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>>> two companies.
>>>>>>>>>>
>>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>>> Confluent Marketplace).
>>>>>>>>>>
>>>>>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Robin
>>>>>>>>>>
>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
--
*Robin Moffatt*
*Sr. Principal Advisor, Streaming Data Technologies*
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Kevin Liu <ke...@apache.org>.
Sounds like a good idea to incorporate trivy. There are other apache
projects using trivy as part of their build/publish step for docker
containers. Heres one from apache/superset,
https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119
We can emulate that in our pipeline
On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev <
dev@iceberg.apache.org> wrote:
> Hi Dan,
> Thanks for the review on the PR.
>
> One thing that's come up internally is that the Confluent team use trivy
> [1] to scan for CVEs as a mandatory step before listing a connector. This
> has flagged CVEs previously (e.g. [2]) that needed patching.
>
> Can you suggest what the best way to incorporate this into the release
> workflow might be?
> As it stands, it's only the finalised release that's sent to Confluent and
> then scanned; should the trivy step be further upstream in the release
> process so that CVEs are patched before the final release is made?
>
> thanks, Robin.
>
> [1] https://trivy.dev/
> [2] https://github.com/apache/iceberg/pull/14985
>
> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
>
>> I'll take a look tomorrow. This would be great to land and validate with
>> the 1.11 release.
>>
>> -Dan
>>
>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>>
>>> Hi Dan,
>>> I've addressed your comments on the PR, could you take another look
>>> please?
>>>
>>> Thanks, Robin
>>>
>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>>
>>>> Hey Robin,
>>>>
>>>> Sorry for not responding to the last email, but this looks like the
>>>> right approach. A couple small comments on the PR, but other than that
>>>> this looks good.
>>>>
>>>> -Dan
>>>>
>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>>> dev@iceberg.apache.org> wrote:
>>>>
>>>>> I've reworked the process based on the feedback into:
>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>>
>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>>
>>>>> thanks, Robin.
>>>>>
>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io>
>>>>> wrote:
>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>>> released artifacts and provenance angle here.
>>>>>>
>>>>>> So would the right direction here be to include the Kafka Connect
>>>>>> artifact as part of the gradle release command?
>>>>>> Then once the release has passed, the artifact on maven can be
>>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>>
>>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>>
>>>>>> thanks, Robin
>>>>>>
>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>>>>>>
>>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>>> good to highlight this here.
>>>>>>>
>>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>>> are part of the release process.
>>>>>>>
>>>>>>> It might be good to include the instructions on how this fits into
>>>>>>> the release process <https://iceberg.apache.org/how-to-release/> so
>>>>>>> we understand the full workflow along with the script.
>>>>>>>
>>>>>>> -Dan
>>>>>>>
>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>>
>>>>>>>> thanks, Robin.
>>>>>>>>
>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>>
>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>>>>> community formalise.
>>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>>> two companies.
>>>>>>>>>
>>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>>> Confluent Marketplace).
>>>>>>>>>
>>>>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>>>>> here to find a process that works for everyone.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Robin
>>>>>>>>>
>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi Dan,
Thanks for the review on the PR.
One thing that's come up internally is that the Confluent team use trivy
[1] to scan for CVEs as a mandatory step before listing a connector. This
has flagged CVEs previously (e.g. [2]) that needed patching.
Can you suggest what the best way to incorporate this into the release
workflow might be?
As it stands, it's only the finalised release that's sent to Confluent and
then scanned; should the trivy step be further upstream in the release
process so that CVEs are patched before the final release is made?
thanks, Robin.
[1] https://trivy.dev/
[2] https://github.com/apache/iceberg/pull/14985
On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <dw...@apache.org> wrote:
> I'll take a look tomorrow. This would be great to land and validate with
> the 1.11 release.
>
> -Dan
>
> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
>
>> Hi Dan,
>> I've addressed your comments on the PR, could you take another look
>> please?
>>
>> Thanks, Robin
>>
>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>>
>>> Hey Robin,
>>>
>>> Sorry for not responding to the last email, but this looks like the
>>> right approach. A couple small comments on the PR, but other than that
>>> this looks good.
>>>
>>> -Dan
>>>
>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>>> dev@iceberg.apache.org> wrote:
>>>
>>>> I've reworked the process based on the feedback into:
>>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>>
>>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>>
>>>> thanks, Robin.
>>>>
>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io> wrote:
>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> I appreciate your input and guidance. I'd definitely missed the
>>>>> released artifacts and provenance angle here.
>>>>>
>>>>> So would the right direction here be to include the Kafka Connect
>>>>> artifact as part of the gradle release command?
>>>>> Then once the release has passed, the artifact on maven can be
>>>>> submitted to Confluent Hub directly by the release manager.
>>>>>
>>>>> If this sounds right I'm happy to put together a PR for it.
>>>>>
>>>>> thanks, Robin
>>>>>
>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>>>>>
>>>>>> I added some comments to this effect in the PR, but it's probably
>>>>>> good to highlight this here.
>>>>>>
>>>>>> I don't think we should be generating new artifacts to upload to
>>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>>> are part of the release process.
>>>>>>
>>>>>> It might be good to include the instructions on how this fits into the
>>>>>> release process <https://iceberg.apache.org/how-to-release/> so we
>>>>>> understand the full workflow along with the script.
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>>> dev@iceberg.apache.org> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>>
>>>>>>> thanks, Robin.
>>>>>>>
>>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>>
>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>>>> community formalise.
>>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>>> two companies.
>>>>>>>>
>>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>>> Confluent Marketplace).
>>>>>>>>
>>>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>>>> here to find a process that works for everyone.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Robin
>>>>>>>>
>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>>> 2: https://hub.confluent.io
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Daniel Weeks <dw...@apache.org>.
I'll take a look tomorrow. This would be great to land and validate with
the 1.11 release.
-Dan
On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <ro...@confluent.io> wrote:
> Hi Dan,
> I've addressed your comments on the PR, could you take another look please?
>
> Thanks, Robin
>
> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
>
>> Hey Robin,
>>
>> Sorry for not responding to the last email, but this looks like the right
>> approach. A couple small comments on the PR, but other than that this
>> looks good.
>>
>> -Dan
>>
>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
>> dev@iceberg.apache.org> wrote:
>>
>>> I've reworked the process based on the feedback into:
>>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>>> 2. The version from Maven is what gets sent to Confluent Hub
>>>
>>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>>
>>> thanks, Robin.
>>>
>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io> wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> I appreciate your input and guidance. I'd definitely missed the
>>>> released artifacts and provenance angle here.
>>>>
>>>> So would the right direction here be to include the Kafka Connect
>>>> artifact as part of the gradle release command?
>>>> Then once the release has passed, the artifact on maven can be
>>>> submitted to Confluent Hub directly by the release manager.
>>>>
>>>> If this sounds right I'm happy to put together a PR for it.
>>>>
>>>> thanks, Robin
>>>>
>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>>>>
>>>>> I added some comments to this effect in the PR, but it's probably good
>>>>> to highlight this here.
>>>>>
>>>>> I don't think we should be generating new artifacts to upload to
>>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>>> are part of the release process.
>>>>>
>>>>> It might be good to include the instructions on how this fits into the
>>>>> release process <https://iceberg.apache.org/how-to-release/> so we
>>>>> understand the full workflow along with the script.
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>>> dev@iceberg.apache.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>>
>>>>>> thanks, Robin.
>>>>>>
>>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>>
>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>>> community formalise.
>>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>>> two companies.
>>>>>>>
>>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>>> Confluent Marketplace).
>>>>>>>
>>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>>> here to find a process that works for everyone.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Robin
>>>>>>>
>>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>>> 2: https://hub.confluent.io
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>> --
>>> *Robin Moffatt*
>>> *Sr. Principal Advisor, Streaming Data Technologies*
>>>
>>
>
> --
> *Robin Moffatt*
> *Sr. Principal Advisor, Streaming Data Technologies*
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi Dan,
I've addressed your comments on the PR, could you take another look please?
Thanks, Robin
On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <dw...@apache.org> wrote:
> Hey Robin,
>
> Sorry for not responding to the last email, but this looks like the right
> approach. A couple small comments on the PR, but other than that this
> looks good.
>
> -Dan
>
> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <
> dev@iceberg.apache.org> wrote:
>
>> I've reworked the process based on the feedback into:
>> 1. Add the Kafka Connect artifact to maven as part of gradle release
>> 2. The version from Maven is what gets sent to Confluent Hub
>>
>> Please take a look: https://github.com/apache/iceberg/pull/15212
>>
>> thanks, Robin.
>>
>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io> wrote:
>>
>>> Hi Daniel,
>>>
>>> I appreciate your input and guidance. I'd definitely missed the released
>>> artifacts and provenance angle here.
>>>
>>> So would the right direction here be to include the Kafka Connect
>>> artifact as part of the gradle release command?
>>> Then once the release has passed, the artifact on maven can be submitted
>>> to Confluent Hub directly by the release manager.
>>>
>>> If this sounds right I'm happy to put together a PR for it.
>>>
>>> thanks, Robin
>>>
>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>>>
>>>> I added some comments to this effect in the PR, but it's probably good
>>>> to highlight this here.
>>>>
>>>> I don't think we should be generating new artifacts to upload to
>>>> connect/hub, but rather referencing the voted and released artifacts that
>>>> are part of the release process.
>>>>
>>>> It might be good to include the instructions on how this fits into the
>>>> release process <https://iceberg.apache.org/how-to-release/> so we
>>>> understand the full workflow along with the script.
>>>>
>>>> -Dan
>>>>
>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>>> dev@iceberg.apache.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>>
>>>>> thanks, Robin.
>>>>>
>>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>>
>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>>> community formalise.
>>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>>> two companies.
>>>>>>
>>>>>> I've put together a draft PR [1] with a script that builds and
>>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>>> Confluent Marketplace).
>>>>>>
>>>>>> Please review the PR's proposed process, and let me know what you
>>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>>> here to find a process that works for everyone.
>>>>>>
>>>>>> thanks,
>>>>>> Robin
>>>>>>
>>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>>> 2: https://hub.confluent.io
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>> --
>> *Robin Moffatt*
>> *Sr. Principal Advisor, Streaming Data Technologies*
>>
>
--
*Robin Moffatt*
*Sr. Principal Advisor, Streaming Data Technologies*
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Daniel Weeks <dw...@apache.org>.
Hey Robin,
Sorry for not responding to the last email, but this looks like the right
approach. A couple small comments on the PR, but other than that this
looks good.
-Dan
On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev <de...@iceberg.apache.org>
wrote:
> I've reworked the process based on the feedback into:
> 1. Add the Kafka Connect artifact to maven as part of gradle release
> 2. The version from Maven is what gets sent to Confluent Hub
>
> Please take a look: https://github.com/apache/iceberg/pull/15212
>
> thanks, Robin.
>
> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io> wrote:
>
>> Hi Daniel,
>>
>> I appreciate your input and guidance. I'd definitely missed the released
>> artifacts and provenance angle here.
>>
>> So would the right direction here be to include the Kafka Connect
>> artifact as part of the gradle release command?
>> Then once the release has passed, the artifact on maven can be submitted
>> to Confluent Hub directly by the release manager.
>>
>> If this sounds right I'm happy to put together a PR for it.
>>
>> thanks, Robin
>>
>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>>
>>> I added some comments to this effect in the PR, but it's probably good
>>> to highlight this here.
>>>
>>> I don't think we should be generating new artifacts to upload to
>>> connect/hub, but rather referencing the voted and released artifacts that
>>> are part of the release process.
>>>
>>> It might be good to include the instructions on how this fits into the
>>> release process <https://iceberg.apache.org/how-to-release/> so we
>>> understand the full workflow along with the script.
>>>
>>> -Dan
>>>
>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>>> dev@iceberg.apache.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Could I ask for input on this please, or a review of the PR[1]?
>>>>
>>>> thanks, Robin.
>>>>
>>>> [1] https://github.com/apache/iceberg/pull/15113
>>>>
>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>>> community formalise.
>>>>> Previously, Tabular owned the connector, and its inclusion
>>>>> in Confluent Hub was managed through the commercial partnership between the
>>>>> two companies.
>>>>>
>>>>> I've put together a draft PR [1] with a script that builds and
>>>>> packages the connector for submission to Confluent Hub [2] (now called
>>>>> Confluent Marketplace).
>>>>>
>>>>> Please review the PR's proposed process, and let me know what you
>>>>> think. I'm happy to liaise between the community and the Confluent team
>>>>> here to find a process that works for everyone.
>>>>>
>>>>> thanks,
>>>>> Robin
>>>>>
>>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>>> 2: https://hub.confluent.io
>>>>>
>>>>
>>>>
>>>>
>>
>
> --
> *Robin Moffatt*
> *Sr. Principal Advisor, Streaming Data Technologies*
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
I've reworked the process based on the feedback into:
1. Add the Kafka Connect artifact to maven as part of gradle release
2. The version from Maven is what gets sent to Confluent Hub
Please take a look: https://github.com/apache/iceberg/pull/15212
thanks, Robin.
On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <ro...@confluent.io> wrote:
> Hi Daniel,
>
> I appreciate your input and guidance. I'd definitely missed the released
> artifacts and provenance angle here.
>
> So would the right direction here be to include the Kafka Connect artifact
> as part of the gradle release command?
> Then once the release has passed, the artifact on maven can be submitted
> to Confluent Hub directly by the release manager.
>
> If this sounds right I'm happy to put together a PR for it.
>
> thanks, Robin
>
> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
>
>> I added some comments to this effect in the PR, but it's probably good to
>> highlight this here.
>>
>> I don't think we should be generating new artifacts to upload to
>> connect/hub, but rather referencing the voted and released artifacts that
>> are part of the release process.
>>
>> It might be good to include the instructions on how this fits into the
>> release process <https://iceberg.apache.org/how-to-release/> so we
>> understand the full workflow along with the script.
>>
>> -Dan
>>
>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
>> dev@iceberg.apache.org> wrote:
>>
>>> Hi,
>>>
>>> Could I ask for input on this please, or a review of the PR[1]?
>>>
>>> thanks, Robin.
>>>
>>> [1] https://github.com/apache/iceberg/pull/15113
>>>
>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io> wrote:
>>>
>>>> Hi,
>>>>
>>>> Currently, the version of the Iceberg connector for Kafka Connect
>>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>>> community formalise.
>>>> Previously, Tabular owned the connector, and its inclusion in Confluent
>>>> Hub was managed through the commercial partnership between the two
>>>> companies.
>>>>
>>>> I've put together a draft PR [1] with a script that builds and packages
>>>> the connector for submission to Confluent Hub [2] (now called Confluent
>>>> Marketplace).
>>>>
>>>> Please review the PR's proposed process, and let me know what you
>>>> think. I'm happy to liaise between the community and the Confluent team
>>>> here to find a process that works for everyone.
>>>>
>>>> thanks,
>>>> Robin
>>>>
>>>> 1: https://github.com/apache/iceberg/pull/15113
>>>> 2: https://hub.confluent.io
>>>>
>>>
>>>
>>>
>
--
*Robin Moffatt*
*Sr. Principal Advisor, Streaming Data Technologies*
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi Daniel,
I appreciate your input and guidance. I'd definitely missed the released
artifacts and provenance angle here.
So would the right direction here be to include the Kafka Connect artifact
as part of the gradle release command?
Then once the release has passed, the artifact on maven can be submitted
to Confluent Hub directly by the release manager.
If this sounds right I'm happy to put together a PR for it.
thanks, Robin
On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <dw...@apache.org> wrote:
> I added some comments to this effect in the PR, but it's probably good to
> highlight this here.
>
> I don't think we should be generating new artifacts to upload to
> connect/hub, but rather referencing the voted and released artifacts that
> are part of the release process.
>
> It might be good to include the instructions on how this fits into the
> release process <https://iceberg.apache.org/how-to-release/> so we
> understand the full workflow along with the script.
>
> -Dan
>
> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
> dev@iceberg.apache.org> wrote:
>
>> Hi,
>>
>> Could I ask for input on this please, or a review of the PR[1]?
>>
>> thanks, Robin.
>>
>> [1] https://github.com/apache/iceberg/pull/15113
>>
>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io> wrote:
>>
>>> Hi,
>>>
>>> Currently, the version of the Iceberg connector for Kafka Connect
>>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>>> through an ad-hoc process, which we would like to help the Apache Iceberg
>>> community formalise.
>>> Previously, Tabular owned the connector, and its inclusion in Confluent
>>> Hub was managed through the commercial partnership between the two
>>> companies.
>>>
>>> I've put together a draft PR [1] with a script that builds and packages
>>> the connector for submission to Confluent Hub [2] (now called Confluent
>>> Marketplace).
>>>
>>> Please review the PR's proposed process, and let me know what you think.
>>> I'm happy to liaise between the community and the Confluent team here to
>>> find a process that works for everyone.
>>>
>>> thanks,
>>> Robin
>>>
>>> 1: https://github.com/apache/iceberg/pull/15113
>>> 2: https://hub.confluent.io
>>>
>>
>>
>>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Daniel Weeks <dw...@apache.org>.
I added some comments to this effect in the PR, but it's probably good to
highlight this here.
I don't think we should be generating new artifacts to upload to
connect/hub, but rather referencing the voted and released artifacts that
are part of the release process.
It might be good to include the instructions on how this fits into the
release process <https://iceberg.apache.org/how-to-release/> so we
understand the full workflow along with the script.
-Dan
On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev <
dev@iceberg.apache.org> wrote:
> Hi,
>
> Could I ask for input on this please, or a review of the PR[1]?
>
> thanks, Robin.
>
> [1] https://github.com/apache/iceberg/pull/15113
>
> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io> wrote:
>
>> Hi,
>>
>> Currently, the version of the Iceberg connector for Kafka Connect
>> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
>> through an ad-hoc process, which we would like to help the Apache Iceberg
>> community formalise.
>> Previously, Tabular owned the connector, and its inclusion in Confluent
>> Hub was managed through the commercial partnership between the two
>> companies.
>>
>> I've put together a draft PR [1] with a script that builds and packages
>> the connector for submission to Confluent Hub [2] (now called Confluent
>> Marketplace).
>>
>> Please review the PR's proposed process, and let me know what you think.
>> I'm happy to liaise between the community and the Confluent team here to
>> find a process that works for everyone.
>>
>> thanks,
>> Robin
>>
>> 1: https://github.com/apache/iceberg/pull/15113
>> 2: https://hub.confluent.io
>>
>
>
>
Re: Update the version of the Iceberg connector for Kafka Connect on Confluent Hub
Posted by Robin Moffatt via dev <de...@iceberg.apache.org>.
Hi,
Could I ask for input on this please, or a review of the PR[1]?
thanks, Robin.
[1] https://github.com/apache/iceberg/pull/15113
On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <ro...@confluent.io> wrote:
> Hi,
>
> Currently, the version of the Iceberg connector for Kafka Connect
> on Confluent Hub is outdated (1.9.2). Confluent staff manually uploaded it
> through an ad-hoc process, which we would like to help the Apache Iceberg
> community formalise.
> Previously, Tabular owned the connector, and its inclusion in Confluent
> Hub was managed through the commercial partnership between the two
> companies.
>
> I've put together a draft PR [1] with a script that builds and packages
> the connector for submission to Confluent Hub [2] (now called Confluent
> Marketplace).
>
> Please review the PR's proposed process, and let me know what you think.
> I'm happy to liaise between the community and the Confluent team here to
> find a process that works for everyone.
>
> thanks,
> Robin
>
> 1: https://github.com/apache/iceberg/pull/15113
> 2: https://hub.confluent.io
>