Consider removing quarkus-langchain4j usage from LangChain4j extensions

[jamesnetherton]

One of the challenges we face is to ensure we have consistent UX when users start prototyping with UI designers like Kaoto / Camel JBang and then export their apps to the chosen runtime.

This becomes difficult if the runtime enforces additional requirements and constraints on top of the vanilla Camel component UX. E.g requiring additional runtime specific configuration properties, CDI beans, dependencies etc.

Therefore, it may be desirable to stop depending on quarkus-langchain4j and just use the Camel component functionality as-is so that the UX stays identical across all runtimes.

Some things to consider:

• We'd have to implement native support
• We loose some build time optimisations
• We loose dev mode support for starting containerized local LLMs like Ollama
• We need to ensure we stay compatible with the LangChain4j version used in the Quarkus Platform (this is an existing concern TBH)
• We'd probably have to deprecate / remove camel-quarkus-langchain4j. See Deprecate camel-quarkus-langchain4j extension #7586.

I can do some initial investigation into how difficult it is to remove quarkus-langchain4j and restore native mode support.

We should try to make a decision on whether we want to go ahead with this change before the 3.27.0 LTS. Maybe even for 3.26.0 but I'm not sure there's time...

[jamesnetherton]

/CC @orpiske @zbendhiba @aldettinger

[jamesnetherton]

I put together a POC PR #7592.

[orpiske]

Thanks @jamesnetherton. I have been thinking about this (with the bean library in mind) and I am under the impression this would make it easier to leverage the bean library.

There are some things I'm considering proposing for it, such as handling prompts, model configuration, etc ... that I feel like would be easier to do if we stick purely with the camel-langchain4j-* components.