CAMEL-20333 Camel Kotlin API

[iMashtak]

Checklist:

• Wrappers for EIPs
• Tests (anyway i will add some more)
• Autogenerated Endpoint DSL
• Autogenerated Dataformat DSL
• REST
• Bean registration
• Intercepts and exception handling
• Documentation
• Sourcecheck, format, etc

Questions:

• What do you think about this? Is it sutable with Camel development vision?
• Should i implement route templates and kamelet EIP in this PR? Can i delay that functionality for later time? As far as i understand, kamelet is purposed for calling route templates, am i right?

[iMashtak]

I added some documentation for all of this, may be that will be helpful in undestanding whats going on in this PR

[iMashtak]

As far as i can see from logs, there is a problem in generate-all-dsl-mojo. It needs a camel-core-model dependency but if i do so, there is a cyclic dependency problem. That because i generate DataFormat DSL, not write it manually, and need some reflection over camel-core-model classes.
So... i will use magic of class loader as described here: link. Will make custom class loader. It is safe approach cause camel-kotlin-api depends on camel-core-model and will be built only after it. That means that we will certainly have compiled classes of camel-core-model at the camel-kotlin-api compilation moment.

[davsclaus]

This is a massive PR. Can you tell more what is the purpose. Can you make an example of what you can do today with camel and kotlin, and say why you need this, and what it will make better.

Kotlin has java interoperability so I would assume it works fine with existing java api, endpintdsl and whatnot.

[iMashtak]

This is just yet another DSL for Camel, nothing more.

I looked at what is done in existing Camel Kotlin DSL and found that Kotlin type-safe builders are used for defining beans and REST parts of configuration and arent used in other places. "Why?" - i had thought. And made fully Kotlin-ish thing. Massiveness comes only from huge number of components and EIPs - code is just copy-paste.

There is nothing you cant do in Kotlin with Camel cause of Java interop. But this PR makes Camel more "native" for Kotlin ecosystem of tools. Also it provides an abitily to define routes using only CamelContext as input, without need in explicit RouteBuilder instantiation.
I dont think i need this PR, it may be considered as an experiment.

So i consider the first question of that PR: is it suitable with Camel development vision? It not, PR should be rejected as irrelevant, i think.

[oscerd]

This look interesting, my only point is related to maintenance. We could merge this and make it available to users, but who will maintain this Koltin DSL? My concern is related to the fact we might not have the capacity to support this DSL too. Nevertheless for me this should be part of the DSLs as experimental and it would be interesting to see it in action in a guest blog post on Camel website. What others think?

[davsclaus]

Yes its massive and great work to generate the DSLs and update the regular DSL to be more Kotlin like. But the users get the best experience with the standard DSLs that we have tooling and you can find the most examples and help with.

[davsclaus]

@iMashtak are you interrested to stay active in the Camel community and keep contributing, and become a committer, and help maintain this Kotlin DSL and whatelse.

[iMashtak]

Thank you for offer, i am interested. What should i do to become committer?

[davsclaus]

Sounds good. You keep contributing and doing great. The Camel PMC will then invite you in as a committer later.

[davsclaus]

We have updated the model DSL a little bit with more variables stuff. Not sure if this PR needs to be regenerated and updated.

[davsclaus]

Also in camel-kotlin-api/pom.xml can you set

<supportLevel>Experimental</supportLevel>

If not already done

[iMashtak]

Support level has already been set, made regen, variableName added for languages where needed.

[davsclaus]

We have done a bit more work on the model with the languages - so this PR maybe needs to be updated.

[iMashtak]

Fixed all issues with languages

I have broken time in WSL, so my commits come from future :D
Found how to fix it, but too late

[iMashtak]

I made Language DSL - autogen for all existing languages. Will commit tomorrow. Seems like i cant generate only model classes - EIPs and so on.

As for EIPs. Feels like i need handmaided config that will describe which classes (inheritors of ProcessorDefinition) i should analyze. Maybe later i will find the way.

[iMashtak]

Ok, language DSL is done, nothing more to commit

[davsclaus]

We did some changes in the model today

• throttler
• languages

Can this PR be updated and generated with latest code

[davsclaus]

and btw those are the last expected model changes. So after that we should be ready for your PR

[davsclaus]

Thanks, can you update the PR as there was a new option so there is uncommitred code changes and the CI cannot do a full test.

• public fun sinkBinding(sinkBinding: String) {
• it.property("sinkBinding", sinkBinding)
• }

[davsclaus]

I wonder if you can make the maven plugin to only output "Generating Language DSL for simple" ... when there was some changes. Its very verbose when nothing is changed. We are doing this for the other DSLs

[davsclaus]

Also your unit test classes should be renamed from xxTests to xxTest otherwise they do not run when doing maven test