You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2016/05/11 15:04:19 UTC
[PROPOSAL] Karaf Boot roadmap
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.
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.
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).
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.
Thoughts ?
Regards
JB
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
+1 to all the points :-)
Thanks!
--
Andrea Cosentino
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, May 11, 2016 5:04 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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.
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.
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).
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.
Thoughts ?
Regards
JB
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Uwe Barthel <ba...@x-reizend.de>.
Hi all,
+1 sounds good to me too.
And +1 for a dev guide with the boot one and the non-boot way.
-- barthel
> On 12 May 2016, at 08:29, Achim Nierbeck <bc...@googlemail.com> wrote:
>
> sounds good to me jb
> so go ahead :)
>
> regards, Achim
>
> 2016-05-12 8:20 GMT+02:00 Sobkowiak Krzysztof <kr...@gmail.com>:
>
>> It's nice the boot theme goes forward. +1 for all points. Especially
>> waiting for the new dev guide. I think the guide should provide the both
>> ways - the boot one and the non-boot way.
>>
>> Regards
>> Krzysztof
>>
>> 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>
>> --
>> Krzysztof Sobkowiak
>>
>> JEE & OSS Architect, Integration Architect
>> Apache Software Foundation Member (http://apache.org/)
>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>> Senior Solution Architect @ Capgemini SSC (
>> http://www.capgeminisoftware.pl/)
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Achim Nierbeck <bc...@googlemail.com>.
sounds good to me jb
so go ahead :)
regards, Achim
2016-05-12 8:20 GMT+02:00 Sobkowiak Krzysztof <kr...@gmail.com>:
> It's nice the boot theme goes forward. +1 for all points. Especially
> waiting for the new dev guide. I think the guide should provide the both
> ways - the boot one and the non-boot way.
>
> Regards
> Krzysztof
>
> 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.
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > Thoughts ?
> >
> > Regards
> > JB
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (
> http://www.capgeminisoftware.pl/)
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Sobkowiak Krzysztof <kr...@gmail.com>.
It's nice the boot theme goes forward. +1 for all points. Especially waiting for the new dev guide. I think the guide should provide the both ways - the boot one and the non-boot way.
Regards
Krzysztof
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.
>
> 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.
>
> 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).
>
> 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.
>
> Thoughts ?
>
> Regards
> JB
--
Krzysztof Sobkowiak
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Matt Sicker <bo...@gmail.com>.
I'd imagine the equivalent Karaf Boot CLI tools would be maven plugin goals.
On 12 May 2016 at 16:39, Serge Huber <sh...@jahia.com> wrote:
> This looks really great. I just had a couple of suggestion :
>
> - Could it be possible to use the samples as “project archetypes” ? So
> that users would have even less to write ? I’m thinking especially at
> developing a REST service alongside with a set of integration tests that
> would start the server and use a REST client to test the REST service.
> - Should we think about a CLI interface similar to what exists in the
> front-end development world ? I’m thinking of something like the Angular 2
> CLI that was just announced ? https://cli.angular.io
> I’m not sure how this would integrate with Maven but I was mostly thinking
> about total beginners to both Karaf and Maven (mostly those coming maybe
> from Gradle, Ant or Bndtools).
>
> WDYT ?
>
> cheers,
> Serge… officially on vacation :)
>
> > On 11 mai 2016, at 10:04, Jean-Baptiste Onofré <jb...@nanthrax.net> 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.
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Serge Huber <sh...@jahia.com>.
This looks really great. I just had a couple of suggestion :
- Could it be possible to use the samples as “project archetypes” ? So that users would have even less to write ? I’m thinking especially at developing a REST service alongside with a set of integration tests that would start the server and use a REST client to test the REST service.
- Should we think about a CLI interface similar to what exists in the front-end development world ? I’m thinking of something like the Angular 2 CLI that was just announced ? https://cli.angular.io
I’m not sure how this would integrate with Maven but I was mostly thinking about total beginners to both Karaf and Maven (mostly those coming maybe from Gradle, Ant or Bndtools).
WDYT ?
cheers,
Serge… officially on vacation :)
> On 11 mai 2016, at 10:04, Jean-Baptiste Onofré <jb...@nanthrax.net> 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.
>
> 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.
>
> 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).
>
> 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.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [PROPOSAL] Karaf Boot roadmap
Posted by Morgan Hautman <mo...@gmail.com>.
Hi,
I'm really excited to see the new starters for bootstrapping, if I can give
you a hand on the PoC I will be pleased to help.
+1 for the karaf-boot-maven-plugin with @bootstrap annotation way.
I also think it's a good idea to build the new guide on karaf-boot, so it's
possible to refer to a working example.
Regards,
Morgan
PS: I don't see my samples, should I propose them as PRs?
2016-05-11 17:04 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>