Basic module structure for Camel K projects

[nicolaferraro]

Going forward version 1.0.0 we should think about how people will organize complex integrations that they will run in production. We strongly want to keep a single file model for the integrations, but often you need to provide resources, like:

• Properties
• API definitions
• Transformation and mapping files
• Test files (yet to come)

That means that even in a simple project composed of few integrations that interact together, it will be difficult to understand what resources belong to what integration.

E.g. When you have multiple integrations, which one does an application.properties file refer to?

We need to define some module structure for integrations. It may be something encoded in the kamel CLI (e.g. kamel scaffold name) or simply a best practice we propose also in the examples.

The simplest model I can imagine is creating as less structure as possible, keeping a minimum of visual order in a project.

e.g.

module1
  module1integration.groovy
  application.properties
  trasnform.xslt

module2
  tests
    moduletest.feature
    moduletest2.feature
    moduletest3.feature
  module2integration1.groovy
  module2integration2.groovy
  application.properties
  README.md

rootmoduleintegration.groovy

Questions:

• Is that the best structure we can have for integrations?
• Should we provide some tools to scaffold it (e.g. create the basic quickstart)?
• Should we provide some tools in the CLI to run a module?
• Should we define a module configuration (as in the comments Allow to configure kamel CLI with env vars and configuration files #1133)
• Other ideas?

@lburgazzoli , @davsclaus, @astefanutti , @jamesnetherton, @valdar, @oscerd

[davesargrad]

@nicolaferraro I was about to ask this. So is it true that I currently cant create an integration that uses several java classes defined in several files? Is this a major limitation, or can I simply place all those class definitions into a single ".java" file?

I would think that many meaningful routes may have a handful of classes, and modularity suggests that these should go in separate files.

An example of an atomikos springboot application, that i am working to find a kamel equivalent of (still using atomikos, just not using springboot) is found here

If you look particularly at the AccountService, one can imagine createAccountAndNotify as a kamel enabled RESTful route that implements a kamel-enabled route both to a jdbc endpoint, and to a jms endpoint. The composite createAccountAndNotify transaction would then be protected via camels support for XA transactions, and atomikos implementation of an XA transaction manager.

The atomikos application is clean, and you'd hope that a kamel variant still preserves the essence of the class structure.

[davesargrad]

One thing I absolutely could do is to put the building block classes into a "jar" file that is then loaded as a maven dependency. I know how to do this, and that may be the proper way to go, and to live with the single file, per integration, restriction in kamel

[nicolaferraro]

You can run multiple files in a Camel K integration, it works also if they are written in different languages. Just run:

kamel run --name thename Routes1.java Routes2.java others.xml

It runs as a single integration named thename.

The "single file model" is the default model we're pushing for, but if it makes sense, I think there are no problems in collapsing multiple integration files into a single integration (often it makes sense for a performance point of view, to save some CPU/memory since it uses a single JVM).

I feel that generic supporting methods and classes are better placed in an external "jar", so that one separates the glue (routes) from the business logic.

[davesargrad]

@nicolaferraro Wow.. thats cool. Sounds like we have a couple of good options, and our options will be enhanced as you solidify your support for an integration structure that includes multiple resources/files.

[nicolaferraro]

Outdated

[samuelhnrq]

Wait what happened, still curious to know how is this going to be handled? Outdated why?