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
