As we're discussing around Camel K 2.0 and the possibility to make it runtime-generic, and as we're discovering we may need full source at build time in order to build natively, here a possible proposal to enable such features.

Disclaimer: this is a very high level design, any development will require a further and low level assessment. I'd like to discuss the "what" without thinking too much in the "how" (at least at this stage).

At this stage the project generation is done just before the build of the project. But the build is generic as the original scope was to have a base maven project containing the set of dependencies (jars) required by the IntegrationKit to build the container image required at runtime. The source developed by the user was later "injected" into the Camel context by Camel K Runtime project. This approach is limiting us to enable anything else but Camel K Runtime applications. Moreover with this approach the pod build strategy requires a circular reference to the Camel K container image to be able to reuse an hidden kamel builder command.

It follows a diagram with my proposal:

I propose to separate the project generation and the build so that we can generate the project or even upload the project (ie, from a git repository or from a camel export). We can try to reuse (and eventually maintain) the same Camel JBang export in order to have the same output as the user had locally. We can introduce a reconciliation loop on a new Project CR: once the project is generated/uploaded (Project status Ready) we'd move to the Build phase that has to know the project (probably the location which may be in Project.Status).

The Build should be more or less how it is now, and the rest of the flow probably similar as well. Probably we'll need to start supporting the kind of project we support now (Camel K runtime/Camel Quarkus) and verifying the compatibility of the incremental image/reuse of previous IntegrationKits. Once this is smooth enough we can start supporting any further generic Camel application (main, SB) leveraging the same mechanism of IntegrationKits inheritance.