+1 Camel K is not GA yet so lets keep innovating at a fast pace and cleanup / remove stuff that its not working out etc.
On Tue, Apr 23, 2019 at 11:45 PM Luca Burgazzoli <[email protected]> wrote: > > Hello everyone, > > In the past months we have introduced a number of features such has the > possibility to create integration based on spring boot or creating an > integration image in addition to the integration context one but they > have quite a few limitations so I do propose to deprecate them quickly > and remove them in the next minor release. > > I've opened a few issues: > > - Deprecate integration image creation > https://github.com/apache/camel-k/issues/627 > > The rationale behind deprecating this is that it is not so easy to > have an image that contains everything and mounting a configmap/secret > may still be required and still to have a partial support for this > feature we need go through some conditions that make the code quite > ugly and not easy to maintain and evolve. > > A more practical reason is that creating an image per integration does > not play very well with the goal fo having a fast deployment and to > reuse as much as possible. > > - Remove spring boot support > https://github.com/apache/camel-k/issues/534 > > The motivation here is similar to the issue above as supporting spring > boot is not easy and requires lot of work with very minimal benefits. > > If spring-boot is needed I would say that a more traditional way of > deploying integration should be recommended. > > - Drop support for knative < 0.4 > https://github.com/apache/camel-k/issues/552 > > The motivation here is that knative < 0.4 does not support mounting > config maps and secrets to pods so we had to implement quite a few > hacks to make it possible to read integration sources, application > configurations and resources from environment variables. > > What do you think ? > > > --- > Luca Burgazzoli -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
