[camel-k] code base clean-up

[Luca Burgazzoli <lb...@gmail.com>]

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

Re: [camel-k] code base clean-up

[Claus Ibsen <cl...@gmail.com>]

+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 <lb...@gmail.com> 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