Onboard Camel K Runtime fixups

[ppalaga]

Some enhancements on top of #5117

[jamesnetherton]

Are we proposing to merge this for 3.2.0?

[ppalaga]

Are we proposing to merge this for 3.2.0?

That's a good question. I think it would be very practical to have this in the LTS. Any opinion, @claudio4j?

[jamesnetherton]

I think it would be very practical to have this in the LTS

I was thinking the reverse 🙂. We are effectively done with 3.2.0, not sure I like introducing a change like this at this stage. Safer to defer for 3.3.0 IMO.

[ppalaga]

I was thinking the reverse 🙂. We are effectively done with 3.2.0, not sure I like introducing a change like this at this stage. Safer to defer for 3.3.0 IMO.

I won't stand in a way then.

[claudio4j]

Thanks Peter.
@jamesnetherton This onboard to a camel-quarkus release will give us a important opportunity to decrease dependency of camel-k-runtime. Also, given that camel-k-runtime extension should not be visible or usable for regular camel-quarkus, I would say this onboard has very minimal risk to disrupt anything in camel-quarkus applications.

[zhfeng]

I'm also not confident to introduce such a big change in last minute before releasing 3.2.0. I think @zbendhiba is preparing for the new release this week. WDYT?

[zbendhiba]

I was thinking of releasing 3.3.0 very soon after 3.2.0, so that we go back to the release cadence we used to have before. The 2 versions will be based on Camel 4, but 3.2.0 is an LTS.
I also think it makes sense to have the experimental stuff for 3.3.0 and Camel k team will have quickly 3.3.0 to start experimenting stuff. is that makes sense for you @claudio4j ?

[zhfeng]

It looks like camel-k-runtime tests are failing on windows build due to lack of Docker environment.

[zhfeng]

@zbendhiba For releasing 3.3.0, please make sure we have all changes in

• Upgrade to Quarkus 3.3.0 #5190

[aldettinger]

With Camel-K 2.0, we should already have less coupling between Camel Quarkus and Camel-K ? So that should be ok to merge this pr in next 3.3.0 release ?

[ppalaga]

It looks like camel-k-runtime tests are failing on windows build due to lack of Docker environment.

Thanks for having a look @zhfeng! I am away for a RH event today and I'll be able to address this only tomorrow.

[ppalaga]

866fe21:

• Rebased
• Squashed all commits
• Added skip-testcontainers-tests profile to the new Camel K test module

        <profile>
            <id>skip-testcontainers-tests</id>
            <activation>
                <property>
                    <name>skip-testcontainers-tests</name>
                </property>
            </activation>
            <properties>
                <skipTests>true</skipTests>
            </properties>
        </profile>

[claudio4j]

I was thinking of releasing 3.3.0 very soon after 3.2.0, so that we go back to the release cadence we used to have before. The 2 versions will be based on Camel 4, but 3.2.0 is an LTS. I also think it makes sense to have the experimental stuff for 3.3.0 and Camel k team will have quickly 3.3.0 to start experimenting stuff. is that makes sense for you @claudio4j ?

Sounds good to me, thanks for the feedback everyone.

[ppalaga]

So there seems to exist an agreement that this PR should aim 3.3.0.
Hence I am going to rebase this after we release 3.2.0.

[ppalaga]

5c4c745:

• Rebased
• Addressed the feedback from @zbendhiba