Hi Guillaume,

Thanks for your feedback, see my comments inline:

> Le 23 juin 2020 à 02:51, Guillaume Nodet <gno...@apache.org> a écrit :
> 
> Le lun. 22 juin 2020 à 19:09, Jean-Baptiste Onofre <j...@nanthrax.net 
> <mailto:j...@nanthrax.net>> a
> écrit :
> 
>> Hi guys,
>> 
>> Now that Camel Karaf is on its own repository, I started major
>> refactoring/improvement coming for 3.5.0 (as 3.4.0 is LTS):
>> 
>> 1. Cleanup
>> I did a complete module structure cleanup (no platform anymore, core
>> module directly at root folder) and feature.
>> 
> 
> Definitely needed.  The first step was the repository split but the current
> state is definitely a bit too complex.
> We just need to pay attention to the docs generation so that it can be
> correctly synced on the web site.
> 

Yes, it’s the step I’m doing now: checking if all is ok at runtime and doc 
generation.

> 
>> 
>> 2. Remove osgi-activator component to use whiteboard pattern
>> I removed osgi-activator component to use RouteBuilder extended/production
>> ready whiteboard pattern, using service property.
>> 
> 
> Not sure to understand exactly. It looks to me as if the
> camel-osgi-activator already use a whiteboard pattern to track RouteBuilder
> services exposed by bundles are added to a CamelContext.
> 

The camel-osgi-activator is a bit too simple and not really adapted for 
production. I changed to have whiteboard as part of the core and use service 
property to define camel context id, etc. So, now, user has the choice between 
using an unique CamelContext, reuse an existing CamelContext or create a new 
dedicated one for each RouteBuilder.
It’s exactly like the osgi-activator but improved and production ready.

> 
>> 3. Introduction of CamelContextConfigurer whiteboard
>> Camel-core-osgi now provided CamelContextConfigurer interface allowing you
>> to create and configure CamelContext smoothly.
>> 
> 
> We use XxxConfigurer in camel-core as helpers to set properties on various
> camel parts.  Maybe using CamelContextBuilder would be more appropriate if
> that's a kind of service to create CamelContext objects ?

Yeah, it’s actually better. I will change my implementation to use 
CamelContextBuilder.

> 
> 
>> 4. Deployer
>> Now, you can directly deploy route in groovy or package as pure jar (no
>> need to be a bundle).
>> 
> 
> Sounds good.
> 
> 
>> 
>> 5. Karamel tool
>> I started a new tool named karamel (Karaf with camel), exposed as CLI,
>> Maven plugin, Gradle plugin.
>> Here’s some example of karamel CLI usage:
>> - create ready to run karamel package and/or docker image:
>>   karamel build myroute.class
>>   karamel build myroute.xml
>>   karamel build myroute.groovy
>> - run karamel package:
>>  karamel run route1.jar route2.jar
>>  karamel run route1.jar route2.xml
>>  karamel run route1.groovy route2.xml
>>  karamel run route1.xml mybundle.jar
>>  karamel run route1.xml myfeature.xml
>> 
> 
> Is that specific to Karaf ? The "karamel run" looks similar to the camel
> maven plugin goal.

Yes, it’s specific to Karaf as it’s actually create a Karaf distribution 
running the Camel routes.
The idea is to simplify the create of the Karaf distribution.

> 
> 
>> 
>> 6. Improved and extended examples
>> The camel-karaf-examples repository will be populated with concrete
>> examples. These examples will be used in test as part of the repo itself.
>> 
> 
> Sounds good.
> 
> 
>> 
>> I will submit several PRs.
>> 
> 
> Looking forward to it :-)

Thanks ;) I’m happy to be back on Camel ;)


Regards
JB

> 
> 
>> 
>> I will keep you posted.
>> 
>> Regards
>> JB
>> 
>> 
> 
> -- 
> ------------------------
> Guillaume Nodet

Reply via email to