[PROPOSAL] Refactoring and new maintenance of camel-karaf

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi guys,

I worked on several changes on camel-karaf that I would like to
propose as PR asap:

Short term (now):

1. Remove platform module to directly use features module
I've removed the platform maven module, and moved camel-karaf features
directly in a new features module (as we do directly in Karaf).

2. Add whiteboard support in the core
The idea is to add CamelContext and Route whiteboard support directly
in camel-core-osgi. The core will directly have a whiteboard for
CamelContext and RouteBuilder services.
It means that the users won't have to create the CamelContext
explicitly but just register a CamelContext service. For the
RouteBuilder, it's possible to use a single CamelContext for all
routes, or to define a CamelContext ID, controlling the routes
register in each CamelContext.

3. Extending itests
I added a bunch of itests, at least testing camel component features
deployment and, when possible, simple test case. Those itests are not
executed by default but by a dedicated profile.

Mid term (during summer):

4. As already proposed, I created a tool that creates "uber" camel
component bundles, using a descriptor. The purpose is to avoid
maintenance/creation of camel component features, and use a single
classloader for the component in Karaf (that allows us to work with
any component, OSGi compliant or not). For licensing reasons, we won't
provide directly the binary bundle, but the descriptor of the
component that will be created at build time or runtime.
For instance, deploying camel-azure-cosmosdb won't require a feature
anymore, just:

bundle:install bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json

I'm testing right now if I can use the component pom.xml directly
(instead of having a dedicated json file).
I'm currently testing the deployment (runtime/buildtime/static). I
will provide more details.
I will use this approach as replacement of ServiceMix Bundles too.

I'm still working on this one, but you have the rough idea.

5. As part of camel-karaf, I will introduce a new tooling named
karamel. The purpose is to create Karaf4 (and later Karaf5) runtime
with routes easily.
Basically, you can do something like:
$ karamel build --style k4 myroute1.jar myroute2.xml ...
It creates a tar.gz karamel runtime (karaf with camel) ready to run.
You can also do:
$ karamel image myroute1.jar myroute2.xml ...
Then it creates a docker image on the local docker daemon, ready to be run.

Thoughts ?

If there's no objection, I will move forward on the "short term" tasks.

If you have any questions/comments, please let me know.

As you can see, we are "restarting" camel-karaf with new cool stuff ;)

Thanks,
Regards
JB

Re: [PROPOSAL] Refactoring and new maintenance of camel-karaf

[Matt Pavlovich <ma...@gmail.com>]

Hey JB-

These sound really good! Especially whiteboard support and simplified deployment of dependencies.

Thanks!
Matt Pavlovich

> On May 2, 2022, at 8:07 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi guys,
> 
> I worked on several changes on camel-karaf that I would like to
> propose as PR asap:
> 
> Short term (now):
> 
> 1. Remove platform module to directly use features module
> I've removed the platform maven module, and moved camel-karaf features
> directly in a new features module (as we do directly in Karaf).
> 
> 2. Add whiteboard support in the core
> The idea is to add CamelContext and Route whiteboard support directly
> in camel-core-osgi. The core will directly have a whiteboard for
> CamelContext and RouteBuilder services.
> It means that the users won't have to create the CamelContext
> explicitly but just register a CamelContext service. For the
> RouteBuilder, it's possible to use a single CamelContext for all
> routes, or to define a CamelContext ID, controlling the routes
> register in each CamelContext.
> 
> 3. Extending itests
> I added a bunch of itests, at least testing camel component features
> deployment and, when possible, simple test case. Those itests are not
> executed by default but by a dedicated profile.
> 
> Mid term (during summer):
> 
> 4. As already proposed, I created a tool that creates "uber" camel
> component bundles, using a descriptor. The purpose is to avoid
> maintenance/creation of camel component features, and use a single
> classloader for the component in Karaf (that allows us to work with
> any component, OSGi compliant or not). For licensing reasons, we won't
> provide directly the binary bundle, but the descriptor of the
> component that will be created at build time or runtime.
> For instance, deploying camel-azure-cosmosdb won't require a feature
> anymore, just:
> 
> bundle:install bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json
> 
> I'm testing right now if I can use the component pom.xml directly
> (instead of having a dedicated json file).
> I'm currently testing the deployment (runtime/buildtime/static). I
> will provide more details.
> I will use this approach as replacement of ServiceMix Bundles too.
> 
> I'm still working on this one, but you have the rough idea.
> 
> 5. As part of camel-karaf, I will introduce a new tooling named
> karamel. The purpose is to create Karaf4 (and later Karaf5) runtime
> with routes easily.
> Basically, you can do something like:
> $ karamel build --style k4 myroute1.jar myroute2.xml ...
> It creates a tar.gz karamel runtime (karaf with camel) ready to run.
> You can also do:
> $ karamel image myroute1.jar myroute2.xml ...
> Then it creates a docker image on the local docker daemon, ready to be run.
> 
> Thoughts ?
> 
> If there's no objection, I will move forward on the "short term" tasks.
> 
> If you have any questions/comments, please let me know.
> 
> As you can see, we are "restarting" camel-karaf with new cool stuff ;)
> 
> Thanks,
> Regards
> JB

Re: [PROPOSAL] Refactoring and new maintenance of camel-karaf

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Claus,

I agree, it sounds good to me.

Let me move forward on the PRs, and we will merge timing wise ;)

Thanks,
Regards
JB

On Sun, May 8, 2022 at 10:40 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> Hi JB
>
> We are closing in towards the next LTS release of Apache Camel that
> will be 3.18.0 to be released in July 2022.
> Next week we finish up the bits to be ready for doing the 3.17.0 release.
>
> In light of this then I suggest that your work is targeted after the
> 3.18 LTS release, which gives you the 2H 2022 to work on
> all of this and to get it stabilized and in a good qualify for the
> next LTS by end of 2022. In between there are plenty
> of public non LTS release that gives community users good time to try
> out and provide feedback on your work.
>
> So in other worlds let's keep what we have now "as-is" for the 3.18 LTS release.
> This release is also the release to have official support for Java 17
> so Camel end users would like to have a camel-karaf "as of today" that
> works on Java 11 and 17.
>
>
>
> On Fri, May 6, 2022 at 10:03 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > Hi guys,
> >
> > As I didn't receive any objections about this one, I will move forward
> > and open the PRs.
> >
> > Regards
> > JB
> >
> > On Mon, May 2, 2022 at 3:07 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> > >
> > > Hi guys,
> > >
> > > I worked on several changes on camel-karaf that I would like to
> > > propose as PR asap:
> > >
> > > Short term (now):
> > >
> > > 1. Remove platform module to directly use features module
> > > I've removed the platform maven module, and moved camel-karaf features
> > > directly in a new features module (as we do directly in Karaf).
> > >
> > > 2. Add whiteboard support in the core
> > > The idea is to add CamelContext and Route whiteboard support directly
> > > in camel-core-osgi. The core will directly have a whiteboard for
> > > CamelContext and RouteBuilder services.
> > > It means that the users won't have to create the CamelContext
> > > explicitly but just register a CamelContext service. For the
> > > RouteBuilder, it's possible to use a single CamelContext for all
> > > routes, or to define a CamelContext ID, controlling the routes
> > > register in each CamelContext.
> > >
> > > 3. Extending itests
> > > I added a bunch of itests, at least testing camel component features
> > > deployment and, when possible, simple test case. Those itests are not
> > > executed by default but by a dedicated profile.
> > >
> > > Mid term (during summer):
> > >
> > > 4. As already proposed, I created a tool that creates "uber" camel
> > > component bundles, using a descriptor. The purpose is to avoid
> > > maintenance/creation of camel component features, and use a single
> > > classloader for the component in Karaf (that allows us to work with
> > > any component, OSGi compliant or not). For licensing reasons, we won't
> > > provide directly the binary bundle, but the descriptor of the
> > > component that will be created at build time or runtime.
> > > For instance, deploying camel-azure-cosmosdb won't require a feature
> > > anymore, just:
> > >
> > > bundle:install bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json
> > >
> > > I'm testing right now if I can use the component pom.xml directly
> > > (instead of having a dedicated json file).
> > > I'm currently testing the deployment (runtime/buildtime/static). I
> > > will provide more details.
> > > I will use this approach as replacement of ServiceMix Bundles too.
> > >
> > > I'm still working on this one, but you have the rough idea.
> > >
> > > 5. As part of camel-karaf, I will introduce a new tooling named
> > > karamel. The purpose is to create Karaf4 (and later Karaf5) runtime
> > > with routes easily.
> > > Basically, you can do something like:
> > > $ karamel build --style k4 myroute1.jar myroute2.xml ...
> > > It creates a tar.gz karamel runtime (karaf with camel) ready to run.
> > > You can also do:
> > > $ karamel image myroute1.jar myroute2.xml ...
> > > Then it creates a docker image on the local docker daemon, ready to be run.
> > >
> > > Thoughts ?
> > >
> > > If there's no objection, I will move forward on the "short term" tasks.
> > >
> > > If you have any questions/comments, please let me know.
> > >
> > > As you can see, we are "restarting" camel-karaf with new cool stuff ;)
> > >
> > > Thanks,
> > > Regards
> > > JB
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: [PROPOSAL] Refactoring and new maintenance of camel-karaf

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

Hi JB

We are closing in towards the next LTS release of Apache Camel that
will be 3.18.0 to be released in July 2022.
Next week we finish up the bits to be ready for doing the 3.17.0 release.

In light of this then I suggest that your work is targeted after the
3.18 LTS release, which gives you the 2H 2022 to work on
all of this and to get it stabilized and in a good qualify for the
next LTS by end of 2022. In between there are plenty
of public non LTS release that gives community users good time to try
out and provide feedback on your work.

So in other worlds let's keep what we have now "as-is" for the 3.18 LTS release.
This release is also the release to have official support for Java 17
so Camel end users would like to have a camel-karaf "as of today" that
works on Java 11 and 17.



On Fri, May 6, 2022 at 10:03 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi guys,
>
> As I didn't receive any objections about this one, I will move forward
> and open the PRs.
>
> Regards
> JB
>
> On Mon, May 2, 2022 at 3:07 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> >
> > Hi guys,
> >
> > I worked on several changes on camel-karaf that I would like to
> > propose as PR asap:
> >
> > Short term (now):
> >
> > 1. Remove platform module to directly use features module
> > I've removed the platform maven module, and moved camel-karaf features
> > directly in a new features module (as we do directly in Karaf).
> >
> > 2. Add whiteboard support in the core
> > The idea is to add CamelContext and Route whiteboard support directly
> > in camel-core-osgi. The core will directly have a whiteboard for
> > CamelContext and RouteBuilder services.
> > It means that the users won't have to create the CamelContext
> > explicitly but just register a CamelContext service. For the
> > RouteBuilder, it's possible to use a single CamelContext for all
> > routes, or to define a CamelContext ID, controlling the routes
> > register in each CamelContext.
> >
> > 3. Extending itests
> > I added a bunch of itests, at least testing camel component features
> > deployment and, when possible, simple test case. Those itests are not
> > executed by default but by a dedicated profile.
> >
> > Mid term (during summer):
> >
> > 4. As already proposed, I created a tool that creates "uber" camel
> > component bundles, using a descriptor. The purpose is to avoid
> > maintenance/creation of camel component features, and use a single
> > classloader for the component in Karaf (that allows us to work with
> > any component, OSGi compliant or not). For licensing reasons, we won't
> > provide directly the binary bundle, but the descriptor of the
> > component that will be created at build time or runtime.
> > For instance, deploying camel-azure-cosmosdb won't require a feature
> > anymore, just:
> >
> > bundle:install bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json
> >
> > I'm testing right now if I can use the component pom.xml directly
> > (instead of having a dedicated json file).
> > I'm currently testing the deployment (runtime/buildtime/static). I
> > will provide more details.
> > I will use this approach as replacement of ServiceMix Bundles too.
> >
> > I'm still working on this one, but you have the rough idea.
> >
> > 5. As part of camel-karaf, I will introduce a new tooling named
> > karamel. The purpose is to create Karaf4 (and later Karaf5) runtime
> > with routes easily.
> > Basically, you can do something like:
> > $ karamel build --style k4 myroute1.jar myroute2.xml ...
> > It creates a tar.gz karamel runtime (karaf with camel) ready to run.
> > You can also do:
> > $ karamel image myroute1.jar myroute2.xml ...
> > Then it creates a docker image on the local docker daemon, ready to be run.
> >
> > Thoughts ?
> >
> > If there's no objection, I will move forward on the "short term" tasks.
> >
> > If you have any questions/comments, please let me know.
> >
> > As you can see, we are "restarting" camel-karaf with new cool stuff ;)
> >
> > Thanks,
> > Regards
> > JB



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: [PROPOSAL] Refactoring and new maintenance of camel-karaf

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi guys,

As I didn't receive any objections about this one, I will move forward
and open the PRs.

Regards
JB

On Mon, May 2, 2022 at 3:07 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi guys,
>
> I worked on several changes on camel-karaf that I would like to
> propose as PR asap:
>
> Short term (now):
>
> 1. Remove platform module to directly use features module
> I've removed the platform maven module, and moved camel-karaf features
> directly in a new features module (as we do directly in Karaf).
>
> 2. Add whiteboard support in the core
> The idea is to add CamelContext and Route whiteboard support directly
> in camel-core-osgi. The core will directly have a whiteboard for
> CamelContext and RouteBuilder services.
> It means that the users won't have to create the CamelContext
> explicitly but just register a CamelContext service. For the
> RouteBuilder, it's possible to use a single CamelContext for all
> routes, or to define a CamelContext ID, controlling the routes
> register in each CamelContext.
>
> 3. Extending itests
> I added a bunch of itests, at least testing camel component features
> deployment and, when possible, simple test case. Those itests are not
> executed by default but by a dedicated profile.
>
> Mid term (during summer):
>
> 4. As already proposed, I created a tool that creates "uber" camel
> component bundles, using a descriptor. The purpose is to avoid
> maintenance/creation of camel component features, and use a single
> classloader for the component in Karaf (that allows us to work with
> any component, OSGi compliant or not). For licensing reasons, we won't
> provide directly the binary bundle, but the descriptor of the
> component that will be created at build time or runtime.
> For instance, deploying camel-azure-cosmosdb won't require a feature
> anymore, just:
>
> bundle:install bundle:org.apache.camel/camel-azure-cosmosdb/3.16.0?descriptor=http://github.com/apache/camel-karaf/descriptors/camel-azure-cosmosdb.json
>
> I'm testing right now if I can use the component pom.xml directly
> (instead of having a dedicated json file).
> I'm currently testing the deployment (runtime/buildtime/static). I
> will provide more details.
> I will use this approach as replacement of ServiceMix Bundles too.
>
> I'm still working on this one, but you have the rough idea.
>
> 5. As part of camel-karaf, I will introduce a new tooling named
> karamel. The purpose is to create Karaf4 (and later Karaf5) runtime
> with routes easily.
> Basically, you can do something like:
> $ karamel build --style k4 myroute1.jar myroute2.xml ...
> It creates a tar.gz karamel runtime (karaf with camel) ready to run.
> You can also do:
> $ karamel image myroute1.jar myroute2.xml ...
> Then it creates a docker image on the local docker daemon, ready to be run.
>
> Thoughts ?
>
> If there's no objection, I will move forward on the "short term" tasks.
>
> If you have any questions/comments, please let me know.
>
> As you can see, we are "restarting" camel-karaf with new cool stuff ;)
>
> Thanks,
> Regards
> JB