Add codestart for camel-quarkus-kotlin

[jamesnetherton]

POC of a basic Camel Quarkus codestart. I thought we could try it on a 'low traffic' extension initially and then evaluate expanding it to other extensions.

The codestart will bootstrap a project with some basic routes and a JVM mode test that leverages CamelQuarkusTestSupport.

Feedback is welcome. If we think this is worthwhile, I would need to make some tweaks to the cq-maven-plugin before this PR is merged, so that the codestart config is preserved in the extension metadata.

[aldettinger]

Nice experiment :+1: Might be interesting for very few select topics. Like, it could improve the very first experience for new CQ users.

On the other hand, we would need to take care at the maintenance cost. Like, how do we ensure that generated codestarts can run at each version without manual testing ?

There is also the question of how well codestart behaves when mixing multiple extensions as this the main scenario when building Camel integrations. Maybe we could integrate a single code start per DSL and that's all... Need a bit more thinking.

[ppalaga]

how do we ensure that generated codestarts can run at each version without manual testing ?

There is a test called KotlinCodestartTest in this PR https://github.com/apache/camel-quarkus/pull/5020/files#diff-93ae7fb045df527f7bf6084da75695a312f6665471fe730534b8286594b96211

There is also the question of how well codestart behaves when mixing multiple extensions as this the main scenario when building Camel integrations. Maybe we could integrate a single code start per DSL and that's all...

That's a valid concern. IIRC, it was mentioned very early when the CodeStarts were introduced that the composability might be an issue. OTOH, do our extensions really require amending some file provided by some other extension? Maybe application.properties? Otherwise each extension could provide its own route definition file in some particular DSL. Maybe for some extensions, it would be hard to write such without timer. But it would be easy for others.

[aldettinger]

how do we ensure that generated codestarts can run at each version without manual testing ?

There is a test called KotlinCodestartTest in this PR https://github.com/apache/camel-quarkus/pull/5020/files#diff-93ae7fb045df527f7bf6084da75695a312f6665471fe730534b8286594b96211

It looks like assertion that content is well generated. Does it also check that the generated code is runnable ?

There is also the question of how well codestart behaves when mixing multiple extensions as this the main scenario when building Camel integrations. Maybe we could integrate a single code start per DSL and that's all...

That's a valid concern. IIRC, it was mentioned very early when the CodeStarts were introduced that the composability might be an issue. OTOH, do our extensions really require amending some file provided by some other extension? Maybe application.properties? Otherwise each extension could provide its own route definition file in some particular DSL. Maybe for some extensions, it would be hard to write such without timer. But it would be easy for others.

More than composability related technical issues that might be solved or not, there is the subject of how much it would make sense to code start multiple extensions together. Like code starting an app with jms + jdbc, what route does it make sense to generate from(timer).to(jms) + from(timer.to(jdbc) route ? from(jms).to(jdbc) ?

[jamesnetherton]

Thanks all for the feedback! I forgot I even opened this PR :stuck_out_tongue:

It looks like assertion that content is well generated. Does it also check that the generated code is runnable ?

The test framework can run the tests in the generated project.

There is also the question of how well codestart behaves when mixing multiple extensions

Yes, composability is a tricky problem. It needs more thought, but you can have quite complex logic in the codestart templates to help with that.

Like code starting an app with jms + jdbc, what route does it make sense to generate from(timer).to(jms) + from(timer.to(jdbc) route ? from(jms).to(jdbc) ?

I don't think creating routes for specialized components is ever going to be achievable for a codestart. There could be multiple endpoint URI options required, CDI beans needed, configuration properties etc. I saw the initial goal as being able to bootstrap a simple app with a basic RouteBuilder, together with a test. It's for the user to deal with the specifics of their app.

[aldettinger]

I don't think creating routes for specialized components is ever going to be achievable for a codestart. There could be multiple endpoint URI options required, CDI beans needed, configuration properties etc. I saw the initial goal as being able to bootstrap a simple app with a basic RouteBuilder, together with a test. It's for the user to deal with the specifics of their app. Yes, so maybe it's just a code start for each DSL generating a basic route. And then maybe the generated route is run on ci during cq tests or alike.

[jamesnetherton]

I'll close this for now. I may revisit it in the future.