karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [PROPOSAL] Karaf Boot roadmap
Date Thu, 12 May 2016 07:03:36 GMT
On 11.05.2016 17:04, Jean-Baptiste Onofré wrote:
> Hi all,
>
> Karaf Boot code is now on the Apache Git:
>
> https://git.apache.org/karaf-boot.git/
>
> with the github mirror:
>
> https://github.com/apache/karaf-boot
>
> I created the component in Jira.
>
> I will update the website with karaf-boot description.
>
> I propose the following roadmap for karaf-boot, heading to the first 
> 1.0 release:
>
> 1. Bootstrapping
> ----------------
> As a reminder, karaf-boot has two goals:
> - simplify the way to create module and application for developers
> - simplify the bootstrapping as a "standalone" application (leveraging 
> the container feature)
>
> Currently, we mostly address the first point. Our starters provide 
> annotations allowing to easily create application. The 
> karaf-boot-maven-plugin "calls" the annotation processor in the 
> starters, and other plugins behind the hood to easily generate artifacts.
>
> Now, we have to address the second point: bootstrapping. I started a 
> PoC on that.
> I created new starters for bootstrapping:
> - karaf-boot-starter-feature creates a feature using the dependencies 
> and project artifact
> - karaf-boot-starter-distribution creates both zip and tar.gz Karaf 
> custom distribution embedding the current project artifact and 
> dependencies
> - karaf-boot-starter-distribution-rjar is similar to distribution, but 
> it's a runnable jar (using a custom Main)
> - karaf-boot-starter-docker creates a docker image embedding the 
> custom distribution
>
> Now, the karaf-boot-maven-plugin is checking the dependencies to find 
> one of these bootstrap starter, and react accordingly.
> However, most of the logic is in the plugin, leveraging 
> karaf-maven-plugin (assembly and archive goals for instance).
> If this approach works (and is easy), I don't think it's the most 
> elegant way.
> I think we should create a @bootstrap annotation on a Runnable class 
> in the bootstrap starters. The annotated class is responsible of the 
> bootstrap artifact creation. An abstract bootstrap starter provide an 
> annotation processor that look for @bootstrap annotation and run the 
> class in a thread. The karaf-boot-maven-plugin just delegates the 
> bootstrapping to the starter.
Not sure if we need such a class as the bootstrapping could also be done 
completely by the starter. On the other hand we will need some 
descriptions about the packaging. I guess we will need to experiment 
with this a bit.

In any case we should be careful to not put too many dependencies into 
the starters as they will all be visible in the user space. Ideally each 
starter should just make some APIs visible to the user but I know this 
will not be possible to achieve.

I currently experiment a lot with spring boot and they have a big 
problem with all the dependencies the starters introduce. There is 
already the case that some starters define incompatible dependencies 
that do not work together in the same project. Maybe we can do better 
here using OSGi.
>
> WDYT ?
>
> 2. New starters
> ---------------
> We have to extend the coverage of the starter to address more use 
> cases. I'm thinking about starters for test (both utest and itest 
> leveraging pax-exam), for jaas, for management/MBean, for eventadmin, 
> for decanter, for camel, etc.
+1
>
> 3. New samples
> --------------
> Related to 2, each new starter should have a corresponding sample. The 
> samples are really important as it's where the users start.
>
> We should also provide kind of full application use case, 
> multi-module. I started this showing how to use different starters in 
> different modules (like a Logo construction set).
I planned to also work on this based on my tutorial samples around 
tasklist blueprint with cdi annoations and around tasklist DS. I propose 
we focus on these two dependency injection frameworks for the start. 
Guillaume is also working on a new real CDI support but I think it will 
take a while until we can recommend it for production use.
Let us sync about this so we do not do double work.
>
> 4. Documentation and Karaf Dev Guide
> ------------------------------------
> The "new" Karaf Dev guide will be based mostly on karaf-boot. A second 
> section ("advanced") can still address non karaf-boot cases.
I am not sure about this as people do not use karaf-boot at the moment. 
So I think it is important to cover the needs of the existing users.

Instead I propose to create a separate documentation at karaf-boot. It 
could be structured like in spring-boot where each starter has a page 
with descriptions and ready to copy
snippets that allow to try it out.

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message