[karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

I found a bit of time to work on the karaf-boot effort JB initiated at last.
I adapted the tasklist example from aries jpa for karaf boot.

You can find the result in a branch:
https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist

The example contains a JPA persistence unit, a TaskService which 
implements a JPA based repository and a servlet using the http-whiteboard.

I did a little different approach to what JB used with the starter pom 
and the karaf boot plugin.

- I created a karaf-boot-api with the same idea like the enroute 
base-api. It is a pom that contains all APIs you will likely need for 
starting a real business application.
This is the only dependency of the sample. So people starting with this 
pom will be able to start coding business code without thinking about 
the necessary libs.
I also put some test dependencies there like slf4j and junit to help 
people with creating tests.
- I also created a karaf-boot-parent as a parent for all karaf-boot 
samples. It sets up all the necessary plugins like maven-bundle-plugin 
or compiler-plugin. This is different
from JBs approach of using a karaf-boot-plugin. I think the parent 
approach is better as it is easier to understand and extend. People can 
look into the parent to see what it does
and when their project grows they can copy/paste the useful parts into 
their own parent.
- I externalized the osgi settings using an osgi.bnd file. This allows 
to easily customize the OSGi settings without redefining the 
maven-bundle-plugin. It is also compatible to bndtools 3.1
as far as I can tell. So it should make it easier to work on the code 
using bndtools.

Apart from that I created a small stub for defining a feature using 
annotations:
This is how it could look like:
https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java

@Feature(
          name="tasklist",
          version="1.0.0",
          features = {"jpa", "transaction", "hibernate", "http"},
          configFile = "org.ops4j.datasource-tasklist.cfg"
)

The idea is to add this annotation to any class and then let a yet to be 
written karaf-feature plugin create a feature.xml from it.
The result would be a feature with the given name and dependencies. The 
feature would by default also contain the current bundle. So this would 
allow to start with one maven project that contains everything to easily
get a small business application running.

So some things left to do are:
- plugin for the feature creation
- plugin for packaging a self contained karaf including the application 
and all deps and config. More or less this can be done with the current 
karaf-maven-plugin but we need to tune it so it needs less configuration.
- plugin for running the application from the command line
- artifact for creating new karaf-boot applications
- documentation for the transition to a larger multi project setup with 
its own parent. Maybe a separate artifact would also do, not sure
- Integration with bndtools to give the user a nicer IDE for OSGi than 
plain eclipse

I would be happy about any feedback.

Christian


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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Fully agree.

Furthermore, providing bom, parent pom, or whatever it helps, makes sense ;)

Regards
JB

On 12/17/2015 09:27 PM, Matt Sicker wrote:
> Well, anything to help migrating from straight Karaf to karaf-boot would be
> great.
>
> On 17 December 2015 at 14:24, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi Matt,
>>
>> we already have maven archetype, but generally speaking I'm not a big fan.
>>
>> Think about karaf boot with gradle, archetype won't help there.
>>
>> Personally, I prefer to start with a blank pom more than an archetype ;)
>>
>> But definitely, we will provide archetypes.
>>
>> Regards
>> JB
>>
>>
>> On 12/17/2015 05:45 PM, Matt Sicker wrote:
>>
>>> Whatever happened to maven archetypes? This could work for this situation
>>> rather well.
>>>
>>> On 17 December 2015 at 04:46, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> Yes, I agree about the PoC approach, but I think PoC can become a project
>>>> or as least some module can use the "easy" karaf-boot way.
>>>>
>>>> My only concern about copy/paste is that the project bootstrapping is
>>>> long: personally, using archetype or copy paste from a sample pom is fine
>>>> but long, actually longer than just describing couple of dependencies and
>>>> plugin. But it could make sense.
>>>>
>>>> For multi-module, I agree, but I don't see any show stopper: each module
>>>> can use karaf-boot and work together (see the samples of service provider
>>>> and consumer, karaf-boot should really encourage to leverage the service
>>>> approach).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 12/17/2015 11:20 AM, Christian Schneider wrote:
>>>>
>>>> For me the main purpose of karaf boot in unchanged form is to allow
>>>>> people to easily create small proof of concepts.
>>>>> In this stage it normally is no issue that you do not use the company
>>>>> parent pom. You can start easily with karaf boot and bring your poc to a
>>>>> level where management decides to use karaf.
>>>>>
>>>>> Then at some point you need to transition to a regular project. So you
>>>>> can copy the karaf boot parent, edit it to include your company parent
>>>>> and other changes you might need and use it for your project(s).
>>>>> This transition phase will also happen when you use the blackbox
>>>>> karaf-boot plugin but then it will be a lot harder to adapt it to your
>>>>> needs.
>>>>>
>>>>> Another thing we need to look at is the transition from a single module
>>>>> project to a multi module project. I think it is really great to let
>>>>> people start with a single module/project but to leverage OSGi people
>>>>> will want to build multi module projects at some point. This will either
>>>>> happen during the transition from poc to a regular project or even
>>>>> earlier. So I think we also need to make sure that multi module projects
>>>>> can be built easily. For this case I think
>>>>> it is natural that the set of modules that form you application will
>>>>> have their own parent pom (that of course might depend on a company
>>>>> parent).
>>>>>
>>>>> Christian
>>>>>
>>>>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>>>>>
>>>>> Hi Serge,
>>>>>>
>>>>>> It's what I meant by "intrusive": sometime we have to use a company
>>>>>> wide parent pom, no choice. So we can't force the usage of a
>>>>>> karaf-boot parent IMHO.
>>>>>>
>>>>>> That's why, after the earlier discussions on the mailing list, I did:
>>>>>> - a set of karaf-boot-starter, providing dependencies depending what
>>>>>> you need (rest, jpa, shell, etc). They act as BoM and users just have
>>>>>> to define in the dependencies set (see the karaf-boot-samples).
>>>>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>>>>>> the build/bootstrapping at maximum, I created the
>>>>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>>>>>> starters, scanning the sources, and depending of those, build and
>>>>>> possibly bootstrap the project by wrapping other plugins.
>>>>>>
>>>>>> So, we are really in a kind of black box, where processes are hidden:
>>>>>> and it's one of karaf-boot main purpose. However, I got Christian's
>>>>>> point: he's more in the way to not hide as he expects later people
>>>>>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>>>>>> people can "duplicate" what we have in a parent-pom.
>>>>>>
>>>>>> That's why maybe we can provide both:
>>>>>> - I honestly think that "hide way" will match in 80% of the cases,
>>>>>> where people wants to focus on business code and don't care about the
>>>>>> plumbing. It's the feedback that I got discussing with different
>>>>>> people like Serge, and others (from different background, business,
>>>>>> company).
>>>>>> - However, at least by documentation or parent pom, we have to provide
>>>>>> a way to karaf-boot users to use a very advanced/expert way. I like
>>>>>> Christian's idea to use an extender, it makes sense in some use case.
>>>>>> The profile or feature generation by annotation or starter scanning is
>>>>>> also interesting IMHO.
>>>>>>
>>>>>> My $0.02 ;)
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Matt Sicker <bo...@gmail.com>]

Well, anything to help migrating from straight Karaf to karaf-boot would be
great.

On 17 December 2015 at 14:24, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi Matt,
>
> we already have maven archetype, but generally speaking I'm not a big fan.
>
> Think about karaf boot with gradle, archetype won't help there.
>
> Personally, I prefer to start with a blank pom more than an archetype ;)
>
> But definitely, we will provide archetypes.
>
> Regards
> JB
>
>
> On 12/17/2015 05:45 PM, Matt Sicker wrote:
>
>> Whatever happened to maven archetypes? This could work for this situation
>> rather well.
>>
>> On 17 December 2015 at 04:46, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>> Hi,
>>>
>>> Yes, I agree about the PoC approach, but I think PoC can become a project
>>> or as least some module can use the "easy" karaf-boot way.
>>>
>>> My only concern about copy/paste is that the project bootstrapping is
>>> long: personally, using archetype or copy paste from a sample pom is fine
>>> but long, actually longer than just describing couple of dependencies and
>>> plugin. But it could make sense.
>>>
>>> For multi-module, I agree, but I don't see any show stopper: each module
>>> can use karaf-boot and work together (see the samples of service provider
>>> and consumer, karaf-boot should really encourage to leverage the service
>>> approach).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 12/17/2015 11:20 AM, Christian Schneider wrote:
>>>
>>> For me the main purpose of karaf boot in unchanged form is to allow
>>>> people to easily create small proof of concepts.
>>>> In this stage it normally is no issue that you do not use the company
>>>> parent pom. You can start easily with karaf boot and bring your poc to a
>>>> level where management decides to use karaf.
>>>>
>>>> Then at some point you need to transition to a regular project. So you
>>>> can copy the karaf boot parent, edit it to include your company parent
>>>> and other changes you might need and use it for your project(s).
>>>> This transition phase will also happen when you use the blackbox
>>>> karaf-boot plugin but then it will be a lot harder to adapt it to your
>>>> needs.
>>>>
>>>> Another thing we need to look at is the transition from a single module
>>>> project to a multi module project. I think it is really great to let
>>>> people start with a single module/project but to leverage OSGi people
>>>> will want to build multi module projects at some point. This will either
>>>> happen during the transition from poc to a regular project or even
>>>> earlier. So I think we also need to make sure that multi module projects
>>>> can be built easily. For this case I think
>>>> it is natural that the set of modules that form you application will
>>>> have their own parent pom (that of course might depend on a company
>>>> parent).
>>>>
>>>> Christian
>>>>
>>>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>>>>
>>>> Hi Serge,
>>>>>
>>>>> It's what I meant by "intrusive": sometime we have to use a company
>>>>> wide parent pom, no choice. So we can't force the usage of a
>>>>> karaf-boot parent IMHO.
>>>>>
>>>>> That's why, after the earlier discussions on the mailing list, I did:
>>>>> - a set of karaf-boot-starter, providing dependencies depending what
>>>>> you need (rest, jpa, shell, etc). They act as BoM and users just have
>>>>> to define in the dependencies set (see the karaf-boot-samples).
>>>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>>>>> the build/bootstrapping at maximum, I created the
>>>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>>>>> starters, scanning the sources, and depending of those, build and
>>>>> possibly bootstrap the project by wrapping other plugins.
>>>>>
>>>>> So, we are really in a kind of black box, where processes are hidden:
>>>>> and it's one of karaf-boot main purpose. However, I got Christian's
>>>>> point: he's more in the way to not hide as he expects later people
>>>>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>>>>> people can "duplicate" what we have in a parent-pom.
>>>>>
>>>>> That's why maybe we can provide both:
>>>>> - I honestly think that "hide way" will match in 80% of the cases,
>>>>> where people wants to focus on business code and don't care about the
>>>>> plumbing. It's the feedback that I got discussing with different
>>>>> people like Serge, and others (from different background, business,
>>>>> company).
>>>>> - However, at least by documentation or parent pom, we have to provide
>>>>> a way to karaf-boot users to use a very advanced/expert way. I like
>>>>> Christian's idea to use an extender, it makes sense in some use case.
>>>>> The profile or feature generation by annotation or starter scanning is
>>>>> also interesting IMHO.
>>>>>
>>>>> My $0.02 ;)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Matt Sicker <bo...@gmail.com>

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Hi Matt,

we already have maven archetype, but generally speaking I'm not a big fan.

Think about karaf boot with gradle, archetype won't help there.

Personally, I prefer to start with a blank pom more than an archetype ;)

But definitely, we will provide archetypes.

Regards
JB

On 12/17/2015 05:45 PM, Matt Sicker wrote:
> Whatever happened to maven archetypes? This could work for this situation
> rather well.
>
> On 17 December 2015 at 04:46, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi,
>>
>> Yes, I agree about the PoC approach, but I think PoC can become a project
>> or as least some module can use the "easy" karaf-boot way.
>>
>> My only concern about copy/paste is that the project bootstrapping is
>> long: personally, using archetype or copy paste from a sample pom is fine
>> but long, actually longer than just describing couple of dependencies and
>> plugin. But it could make sense.
>>
>> For multi-module, I agree, but I don't see any show stopper: each module
>> can use karaf-boot and work together (see the samples of service provider
>> and consumer, karaf-boot should really encourage to leverage the service
>> approach).
>>
>> Regards
>> JB
>>
>>
>> On 12/17/2015 11:20 AM, Christian Schneider wrote:
>>
>>> For me the main purpose of karaf boot in unchanged form is to allow
>>> people to easily create small proof of concepts.
>>> In this stage it normally is no issue that you do not use the company
>>> parent pom. You can start easily with karaf boot and bring your poc to a
>>> level where management decides to use karaf.
>>>
>>> Then at some point you need to transition to a regular project. So you
>>> can copy the karaf boot parent, edit it to include your company parent
>>> and other changes you might need and use it for your project(s).
>>> This transition phase will also happen when you use the blackbox
>>> karaf-boot plugin but then it will be a lot harder to adapt it to your
>>> needs.
>>>
>>> Another thing we need to look at is the transition from a single module
>>> project to a multi module project. I think it is really great to let
>>> people start with a single module/project but to leverage OSGi people
>>> will want to build multi module projects at some point. This will either
>>> happen during the transition from poc to a regular project or even
>>> earlier. So I think we also need to make sure that multi module projects
>>> can be built easily. For this case I think
>>> it is natural that the set of modules that form you application will
>>> have their own parent pom (that of course might depend on a company
>>> parent).
>>>
>>> Christian
>>>
>>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>>>
>>>> Hi Serge,
>>>>
>>>> It's what I meant by "intrusive": sometime we have to use a company
>>>> wide parent pom, no choice. So we can't force the usage of a
>>>> karaf-boot parent IMHO.
>>>>
>>>> That's why, after the earlier discussions on the mailing list, I did:
>>>> - a set of karaf-boot-starter, providing dependencies depending what
>>>> you need (rest, jpa, shell, etc). They act as BoM and users just have
>>>> to define in the dependencies set (see the karaf-boot-samples).
>>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>>>> the build/bootstrapping at maximum, I created the
>>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>>>> starters, scanning the sources, and depending of those, build and
>>>> possibly bootstrap the project by wrapping other plugins.
>>>>
>>>> So, we are really in a kind of black box, where processes are hidden:
>>>> and it's one of karaf-boot main purpose. However, I got Christian's
>>>> point: he's more in the way to not hide as he expects later people
>>>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>>>> people can "duplicate" what we have in a parent-pom.
>>>>
>>>> That's why maybe we can provide both:
>>>> - I honestly think that "hide way" will match in 80% of the cases,
>>>> where people wants to focus on business code and don't care about the
>>>> plumbing. It's the feedback that I got discussing with different
>>>> people like Serge, and others (from different background, business,
>>>> company).
>>>> - However, at least by documentation or parent pom, we have to provide
>>>> a way to karaf-boot users to use a very advanced/expert way. I like
>>>> Christian's idea to use an extender, it makes sense in some use case.
>>>> The profile or feature generation by annotation or starter scanning is
>>>> also interesting IMHO.
>>>>
>>>> My $0.02 ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Matt Sicker <bo...@gmail.com>]

Whatever happened to maven archetypes? This could work for this situation
rather well.

On 17 December 2015 at 04:46, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi,
>
> Yes, I agree about the PoC approach, but I think PoC can become a project
> or as least some module can use the "easy" karaf-boot way.
>
> My only concern about copy/paste is that the project bootstrapping is
> long: personally, using archetype or copy paste from a sample pom is fine
> but long, actually longer than just describing couple of dependencies and
> plugin. But it could make sense.
>
> For multi-module, I agree, but I don't see any show stopper: each module
> can use karaf-boot and work together (see the samples of service provider
> and consumer, karaf-boot should really encourage to leverage the service
> approach).
>
> Regards
> JB
>
>
> On 12/17/2015 11:20 AM, Christian Schneider wrote:
>
>> For me the main purpose of karaf boot in unchanged form is to allow
>> people to easily create small proof of concepts.
>> In this stage it normally is no issue that you do not use the company
>> parent pom. You can start easily with karaf boot and bring your poc to a
>> level where management decides to use karaf.
>>
>> Then at some point you need to transition to a regular project. So you
>> can copy the karaf boot parent, edit it to include your company parent
>> and other changes you might need and use it for your project(s).
>> This transition phase will also happen when you use the blackbox
>> karaf-boot plugin but then it will be a lot harder to adapt it to your
>> needs.
>>
>> Another thing we need to look at is the transition from a single module
>> project to a multi module project. I think it is really great to let
>> people start with a single module/project but to leverage OSGi people
>> will want to build multi module projects at some point. This will either
>> happen during the transition from poc to a regular project or even
>> earlier. So I think we also need to make sure that multi module projects
>> can be built easily. For this case I think
>> it is natural that the set of modules that form you application will
>> have their own parent pom (that of course might depend on a company
>> parent).
>>
>> Christian
>>
>> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>>
>>> Hi Serge,
>>>
>>> It's what I meant by "intrusive": sometime we have to use a company
>>> wide parent pom, no choice. So we can't force the usage of a
>>> karaf-boot parent IMHO.
>>>
>>> That's why, after the earlier discussions on the mailing list, I did:
>>> - a set of karaf-boot-starter, providing dependencies depending what
>>> you need (rest, jpa, shell, etc). They act as BoM and users just have
>>> to define in the dependencies set (see the karaf-boot-samples).
>>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>>> the build/bootstrapping at maximum, I created the
>>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>>> starters, scanning the sources, and depending of those, build and
>>> possibly bootstrap the project by wrapping other plugins.
>>>
>>> So, we are really in a kind of black box, where processes are hidden:
>>> and it's one of karaf-boot main purpose. However, I got Christian's
>>> point: he's more in the way to not hide as he expects later people
>>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>>> people can "duplicate" what we have in a parent-pom.
>>>
>>> That's why maybe we can provide both:
>>> - I honestly think that "hide way" will match in 80% of the cases,
>>> where people wants to focus on business code and don't care about the
>>> plumbing. It's the feedback that I got discussing with different
>>> people like Serge, and others (from different background, business,
>>> company).
>>> - However, at least by documentation or parent pom, we have to provide
>>> a way to karaf-boot users to use a very advanced/expert way. I like
>>> Christian's idea to use an extender, it makes sense in some use case.
>>> The profile or feature generation by annotation or starter scanning is
>>> also interesting IMHO.
>>>
>>> My $0.02 ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Matt Sicker <bo...@gmail.com>

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Hi,

Yes, I agree about the PoC approach, but I think PoC can become a 
project or as least some module can use the "easy" karaf-boot way.

My only concern about copy/paste is that the project bootstrapping is 
long: personally, using archetype or copy paste from a sample pom is 
fine but long, actually longer than just describing couple of 
dependencies and plugin. But it could make sense.

For multi-module, I agree, but I don't see any show stopper: each module 
can use karaf-boot and work together (see the samples of service 
provider and consumer, karaf-boot should really encourage to leverage 
the service approach).

Regards
JB

On 12/17/2015 11:20 AM, Christian Schneider wrote:
> For me the main purpose of karaf boot in unchanged form is to allow
> people to easily create small proof of concepts.
> In this stage it normally is no issue that you do not use the company
> parent pom. You can start easily with karaf boot and bring your poc to a
> level where management decides to use karaf.
>
> Then at some point you need to transition to a regular project. So you
> can copy the karaf boot parent, edit it to include your company parent
> and other changes you might need and use it for your project(s).
> This transition phase will also happen when you use the blackbox
> karaf-boot plugin but then it will be a lot harder to adapt it to your
> needs.
>
> Another thing we need to look at is the transition from a single module
> project to a multi module project. I think it is really great to let
> people start with a single module/project but to leverage OSGi people
> will want to build multi module projects at some point. This will either
> happen during the transition from poc to a regular project or even
> earlier. So I think we also need to make sure that multi module projects
> can be built easily. For this case I think
> it is natural that the set of modules that form you application will
> have their own parent pom (that of course might depend on a company
> parent).
>
> Christian
>
> On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
>> Hi Serge,
>>
>> It's what I meant by "intrusive": sometime we have to use a company
>> wide parent pom, no choice. So we can't force the usage of a
>> karaf-boot parent IMHO.
>>
>> That's why, after the earlier discussions on the mailing list, I did:
>> - a set of karaf-boot-starter, providing dependencies depending what
>> you need (rest, jpa, shell, etc). They act as BoM and users just have
>> to define in the dependencies set (see the karaf-boot-samples).
>> - as a BoM doesn't bring plugin (only dependencies), and to simplify
>> the build/bootstrapping at maximum, I created the
>> karaf-boot-maven-plugin. This plugin is responsible of scanning the
>> starters, scanning the sources, and depending of those, build and
>> possibly bootstrap the project by wrapping other plugins.
>>
>> So, we are really in a kind of black box, where processes are hidden:
>> and it's one of karaf-boot main purpose. However, I got Christian's
>> point: he's more in the way to not hide as he expects later people
>> won't use karaf-boot to a more advanced/expert way. So, at that time,
>> people can "duplicate" what we have in a parent-pom.
>>
>> That's why maybe we can provide both:
>> - I honestly think that "hide way" will match in 80% of the cases,
>> where people wants to focus on business code and don't care about the
>> plumbing. It's the feedback that I got discussing with different
>> people like Serge, and others (from different background, business,
>> company).
>> - However, at least by documentation or parent pom, we have to provide
>> a way to karaf-boot users to use a very advanced/expert way. I like
>> Christian's idea to use an extender, it makes sense in some use case.
>> The profile or feature generation by annotation or starter scanning is
>> also interesting IMHO.
>>
>> My $0.02 ;)
>>
>> Regards
>> JB
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

For me the main purpose of karaf boot in unchanged form is to allow 
people to easily create small proof of concepts.
In this stage it normally is no issue that you do not use the company 
parent pom. You can start easily with karaf boot and bring your poc to a 
level where management decides to use karaf.

Then at some point you need to transition to a regular project. So you 
can copy the karaf boot parent, edit it to include your company parent 
and other changes you might need and use it for your project(s).
This transition phase will also happen when you use the blackbox 
karaf-boot plugin but then it will be a lot harder to adapt it to your 
needs.

Another thing we need to look at is the transition from a single module 
project to a multi module project. I think it is really great to let 
people start with a single module/project but to leverage OSGi people 
will want to build multi module projects at some point. This will either 
happen during the transition from poc to a regular project or even 
earlier. So I think we also need to make sure that multi module projects 
can be built easily. For this case I think
it is natural that the set of modules that form you application will 
have their own parent pom (that of course might depend on a company parent).

Christian

On 17.12.2015 10:51, Jean-Baptiste Onofré wrote:
> Hi Serge,
>
> It's what I meant by "intrusive": sometime we have to use a company 
> wide parent pom, no choice. So we can't force the usage of a 
> karaf-boot parent IMHO.
>
> That's why, after the earlier discussions on the mailing list, I did:
> - a set of karaf-boot-starter, providing dependencies depending what 
> you need (rest, jpa, shell, etc). They act as BoM and users just have 
> to define in the dependencies set (see the karaf-boot-samples).
> - as a BoM doesn't bring plugin (only dependencies), and to simplify 
> the build/bootstrapping at maximum, I created the 
> karaf-boot-maven-plugin. This plugin is responsible of scanning the 
> starters, scanning the sources, and depending of those, build and 
> possibly bootstrap the project by wrapping other plugins.
>
> So, we are really in a kind of black box, where processes are hidden: 
> and it's one of karaf-boot main purpose. However, I got Christian's 
> point: he's more in the way to not hide as he expects later people 
> won't use karaf-boot to a more advanced/expert way. So, at that time, 
> people can "duplicate" what we have in a parent-pom.
>
> That's why maybe we can provide both:
> - I honestly think that "hide way" will match in 80% of the cases, 
> where people wants to focus on business code and don't care about the 
> plumbing. It's the feedback that I got discussing with different 
> people like Serge, and others (from different background, business, 
> company).
> - However, at least by documentation or parent pom, we have to provide 
> a way to karaf-boot users to use a very advanced/expert way. I like 
> Christian's idea to use an extender, it makes sense in some use case. 
> The profile or feature generation by annotation or starter scanning is 
> also interesting IMHO.
>
> My $0.02 ;)
>
> Regards
> JB
>


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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Hi Serge,

It's what I meant by "intrusive": sometime we have to use a company wide 
parent pom, no choice. So we can't force the usage of a karaf-boot 
parent IMHO.

That's why, after the earlier discussions on the mailing list, I did:
- a set of karaf-boot-starter, providing dependencies depending what you 
need (rest, jpa, shell, etc). They act as BoM and users just have to 
define in the dependencies set (see the karaf-boot-samples).
- as a BoM doesn't bring plugin (only dependencies), and to simplify the 
build/bootstrapping at maximum, I created the karaf-boot-maven-plugin. 
This plugin is responsible of scanning the starters, scanning the 
sources, and depending of those, build and possibly bootstrap the 
project by wrapping other plugins.

So, we are really in a kind of black box, where processes are hidden: 
and it's one of karaf-boot main purpose. However, I got Christian's 
point: he's more in the way to not hide as he expects later people won't 
use karaf-boot to a more advanced/expert way. So, at that time, people 
can "duplicate" what we have in a parent-pom.

That's why maybe we can provide both:
- I honestly think that "hide way" will match in 80% of the cases, where 
people wants to focus on business code and don't care about the 
plumbing. It's the feedback that I got discussing with different people 
like Serge, and others (from different background, business, company).
- However, at least by documentation or parent pom, we have to provide a 
way to karaf-boot users to use a very advanced/expert way. I like 
Christian's idea to use an extender, it makes sense in some use case. 
The profile or feature generation by annotation or starter scanning is 
also interesting IMHO.

My $0.02 ;)

Regards
JB

On 12/17/2015 10:22 AM, Serge Huber wrote:
> Hi guys,
>
> Sorry for jumping in like this but I’m also very interested in the Karaf boot project, although I unfortunately am so busy with other things I can’t contribute much code to it for the moment.
>
>
>> On 17 déc. 2015, at 09:11, Christian Schneider <ch...@die-schneider.net> wrote:
>>
>>
>> BOM and pom unfortunately both do not provide any way to add plugins to the user code.
>> This is what I use the parent for. You are right that it does not provide much flexibility but I think it is better than
>> a monolithic karaf boot plugin that calls all other necessary plugins. One reason is that a parent is more transparent.
>> So the user can look into the parent and easily understand what it does. A parent is also a nice template
>> for the more advanced user to create his own parent.
>
> The biggest issue I see with a parent POM is that in our experience with integrators, a lot of them that already use Maven have an “imposed” company-wide parent POM, and therefore could not imagine starting a project with anything else than their own parent POM.
>
> In the “boot” world, a lot of projects are now even using shell scripts that will install all the requirements. One of the best ones I’ve seen is the Homebrew project for Mac OS X (http://brew.sh) that makes it incredibly simple to get started. Maybe we could even install Maven using a shell script ? Or maybe I’m pushing this idea a bit too far and assuming Maven is installed is an acceptable first step.
>
> One thing that would be really cool also would be a way to “transform” existing project to be Karaf boot compatible. Let’s imagine I have a legacy WAR project. Using a plugin or a shell script I could quickly transform it to be packaged as a Karaf custom distribution, making it very easy to provide a runnable standalone application.
>
> In the same way we could also look at packaging a JRE so that people wouldn’t even need anything else to run it. Of course this would require having platform specific distributions, but that’s not a huge problem to overcome (apart from manpower to achieve this of course).
>
> I dream of a world where people can “switch over” not only “get started” with Karaf so that we can drive adoption as easily as possible.
>
> cheers,
>    Serge…
>
>>
>> On 17.12.2015 01:03, Achim Nierbeck wrote:
>>> Hi,
>>>
>>> once more, I still think and I think I convinced JB on this point, Parent
>>> POMs are a bad way to start with just to create your own application, this
>>> is where BOMs (Bill Of Material) plays in much more nicely. Especially if
>>> you want to combine different aspects. Like DS plus Web for example, now
>>> you would need two Parents, which isn't possible.
>>>
>>> Now regarding Provisioning and features. I wouldn't go with features, cause
>>> the tend to be
>>> bloated in comparison to the small footprint we want to have with
>>> karaf-boot.
>>>
>>> That's why I proposed long time ago to use profiles.
>>> My first steps no that can be found at the project in JBs GitHub account.
>>> It's the profiles branch. [1]
>>> In this we'll have the profiles attached to the BOMs and therefore it could
>>> be extracted through a specialized Mojo (already worked on that) to merge
>>> all those profiles into one to create a custom Karaf on the fly.
>>>
>>> regards, Achim
>>>
>>> [1] - https://github.com/jbonofre/karaf-boot/tree/profiles
>>>
>>>
>>>
>>> 2015-12-16 22:33 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>>>
>>>> Probably not .. I just did not yet change it :-)
>>>> Will fix it.
>>>>
>>>> Christian
>>>>
>>>> 2015-12-16 22:03 GMT+01:00 Tim Jones <ti...@mccarthy.co.nz>:
>>>>
>>>>> Hi Christian, looks good, one minor, is the package name supposed to be
>>>>> org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>> http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
>>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>> <
>>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
>>>> Open Source Architect
>>>> http://www.talend.com
>>>> <
>>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>
>> Open Source Architect
>> http://www.talend.com <http://www.talend.com/>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Serge Huber <sh...@jahia.com>]

Hi guys, 

Sorry for jumping in like this but I’m also very interested in the Karaf boot project, although I unfortunately am so busy with other things I can’t contribute much code to it for the moment.


> On 17 déc. 2015, at 09:11, Christian Schneider <ch...@die-schneider.net> wrote:
> 
> 
> BOM and pom unfortunately both do not provide any way to add plugins to the user code.
> This is what I use the parent for. You are right that it does not provide much flexibility but I think it is better than
> a monolithic karaf boot plugin that calls all other necessary plugins. One reason is that a parent is more transparent.
> So the user can look into the parent and easily understand what it does. A parent is also a nice template
> for the more advanced user to create his own parent.

The biggest issue I see with a parent POM is that in our experience with integrators, a lot of them that already use Maven have an “imposed” company-wide parent POM, and therefore could not imagine starting a project with anything else than their own parent POM.

In the “boot” world, a lot of projects are now even using shell scripts that will install all the requirements. One of the best ones I’ve seen is the Homebrew project for Mac OS X (http://brew.sh) that makes it incredibly simple to get started. Maybe we could even install Maven using a shell script ? Or maybe I’m pushing this idea a bit too far and assuming Maven is installed is an acceptable first step.

One thing that would be really cool also would be a way to “transform” existing project to be Karaf boot compatible. Let’s imagine I have a legacy WAR project. Using a plugin or a shell script I could quickly transform it to be packaged as a Karaf custom distribution, making it very easy to provide a runnable standalone application. 

In the same way we could also look at packaging a JRE so that people wouldn’t even need anything else to run it. Of course this would require having platform specific distributions, but that’s not a huge problem to overcome (apart from manpower to achieve this of course). 

I dream of a world where people can “switch over” not only “get started” with Karaf so that we can drive adoption as easily as possible.

cheers,
  Serge… 

> 
> On 17.12.2015 01:03, Achim Nierbeck wrote:
>> Hi,
>> 
>> once more, I still think and I think I convinced JB on this point, Parent
>> POMs are a bad way to start with just to create your own application, this
>> is where BOMs (Bill Of Material) plays in much more nicely. Especially if
>> you want to combine different aspects. Like DS plus Web for example, now
>> you would need two Parents, which isn't possible.
>> 
>> Now regarding Provisioning and features. I wouldn't go with features, cause
>> the tend to be
>> bloated in comparison to the small footprint we want to have with
>> karaf-boot.
>> 
>> That's why I proposed long time ago to use profiles.
>> My first steps no that can be found at the project in JBs GitHub account.
>> It's the profiles branch. [1]
>> In this we'll have the profiles attached to the BOMs and therefore it could
>> be extracted through a specialized Mojo (already worked on that) to merge
>> all those profiles into one to create a custom Karaf on the fly.
>> 
>> regards, Achim
>> 
>> [1] - https://github.com/jbonofre/karaf-boot/tree/profiles
>> 
>> 
>> 
>> 2015-12-16 22:33 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>> 
>>> Probably not .. I just did not yet change it :-)
>>> Will fix it.
>>> 
>>> Christian
>>> 
>>> 2015-12-16 22:03 GMT+01:00 Tim Jones <ti...@mccarthy.co.nz>:
>>> 
>>>> Hi Christian, looks good, one minor, is the package name supposed to be
>>>> org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
>>>> 
>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> 
>>> http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
>>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>> 
>>> 
>>> 
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> <
>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
>>> Open Source Architect
>>> http://www.talend.com
>>> <
>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
>> 
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
> 
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

Hi Achim,

the BOM approach was also my first choice. Unfortunately I think it is 
not suitable.
A BOM allows to define the versions for maven dependencies. It does not 
add any of the dependencies to the project.
So with a BOM you could leave out the versions but would have to specify 
all the dependencies in the user bundle.
What I used there instead was simply a pom with the dependencies. Using 
the transitive nature of dependencies this adds
all dependencies of the pom to the user project. I think this is what we 
want to achieve.

Unfortunately the pom approach also has one weakness. For the 
blueprint-maven-plugin I need to add some APIs (javax.inject and pax-cdi 
api)
as optional.  This does not seem to work if they are extracted into a 
pom. All optional dependencies seem to be not included
in the user project. So if anyone knows how to solve this it would be 
highly appreciated.
Another way would be to configure the maven-bundle-plugin to not create 
Import-Package statements for these APIs. Not sure how to do this though 
in a generic way.

BOM and pom unfortunately both do not provide any way to add plugins to 
the user code.
This is what I use the parent for. You are right that it does not 
provide much flexibility but I think it is better than
a monolithic karaf boot plugin that calls all other necessary plugins. 
One reason is that a parent is more transparent.
So the user can look into the parent and easily understand what it does. 
A parent is also a nice template
for the more advanced user to create his own parent.

I am still not familiar with profiles. I will check out and try your 
code to understand how it works.

I agree with you that we want to achieve a light weight deployment for 
karaf boot. What I had in mind
is to add an option to the karaf-maven-plugin to create a distribution 
with static deployment.
So you specify the features as you do now but the plugin then would not 
add the features as boot features
but instead do all resolution at build time and deploy all bundles using 
startup.properties. This should even
allow to start without the feature service or without the shell if 
people want that.

So in general I think our goals are nicely aligned. We now just have to 
find and agree on a good way to reach them.

Christian

On 17.12.2015 01:03, Achim Nierbeck wrote:
> Hi,
>
> once more, I still think and I think I convinced JB on this point, Parent
> POMs are a bad way to start with just to create your own application, this
> is where BOMs (Bill Of Material) plays in much more nicely. Especially if
> you want to combine different aspects. Like DS plus Web for example, now
> you would need two Parents, which isn't possible.
>
> Now regarding Provisioning and features. I wouldn't go with features, cause
> the tend to be
> bloated in comparison to the small footprint we want to have with
> karaf-boot.
>
> That's why I proposed long time ago to use profiles.
> My first steps no that can be found at the project in JBs GitHub account.
> It's the profiles branch. [1]
> In this we'll have the profiles attached to the BOMs and therefore it could
> be extracted through a specialized Mojo (already worked on that) to merge
> all those profiles into one to create a custom Karaf on the fly.
>
> regards, Achim
>
> [1] - https://github.com/jbonofre/karaf-boot/tree/profiles
>
>
>
> 2015-12-16 22:33 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
>> Probably not .. I just did not yet change it :-)
>> Will fix it.
>>
>> Christian
>>
>> 2015-12-16 22:03 GMT+01:00 Tim Jones <ti...@mccarthy.co.nz>:
>>
>>> Hi Christian, looks good, one minor, is the package name supposed to be
>>> org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>> http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> <
>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
>> Open Source Architect
>> http://www.talend.com
>> <
>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
>
>


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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Achim Nierbeck <bc...@googlemail.com>]

Hi,

once more, I still think and I think I convinced JB on this point, Parent
POMs are a bad way to start with just to create your own application, this
is where BOMs (Bill Of Material) plays in much more nicely. Especially if
you want to combine different aspects. Like DS plus Web for example, now
you would need two Parents, which isn't possible.

Now regarding Provisioning and features. I wouldn't go with features, cause
the tend to be
bloated in comparison to the small footprint we want to have with
karaf-boot.

That's why I proposed long time ago to use profiles.
My first steps no that can be found at the project in JBs GitHub account.
It's the profiles branch. [1]
In this we'll have the profiles attached to the BOMs and therefore it could
be extracted through a specialized Mojo (already worked on that) to merge
all those profiles into one to create a custom Karaf on the fly.

regards, Achim

[1] - https://github.com/jbonofre/karaf-boot/tree/profiles



2015-12-16 22:33 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:

> Probably not .. I just did not yet change it :-)
> Will fix it.
>
> Christian
>
> 2015-12-16 22:03 GMT+01:00 Tim Jones <ti...@mccarthy.co.nz>:
>
> > Hi Christian, looks good, one minor, is the package name supposed to be
> > org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
> >
> >
> >
> > --
> > View this message in context:
> >
> http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
> > Sent from the Karaf - Dev mailing list archive at Nabble.com.
> >
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <
> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de
> >
>
> Open Source Architect
> http://www.talend.com
> <
> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com
> >
>



-- 

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: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

Probably not .. I just did not yet change it :-)
Will fix it.

Christian

2015-12-16 22:03 GMT+01:00 Tim Jones <ti...@mccarthy.co.nz>:

> Hi Christian, looks good, one minor, is the package name supposed to be
> org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Tim Jones <ti...@mccarthy.co.nz>]

Hi Christian, looks good, one minor, is the package name supposed to be
org.apache.aries.jpa.example.tasklist.*blueprint*.impl?Tim



--
View this message in context: http://karaf.922171.n3.nabble.com/karaf-boot-Added-a-DS-sample-with-Servlet-and-JPA-and-slightly-different-setup-tp4044335p4044358.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Hi David,

yes, utest/itest is an important part of karaf-boot. We want to provide 
easy way to leverage pax-exam in a very easy way.

It's not yet done, but in the roadmap.

Regards
JB

On 12/16/2015 04:21 PM, David Daniel wrote:
> Can a karaf boot application be loaded into pax exam 4.7 in a manner
> similar to a standard karaf application.  Would love to see a karaf boot
> application integrated with the bnd launcher as well.
>
> On Wed, Dec 16, 2015 at 9:54 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> I found a bit of time to work on the karaf-boot effort JB initiated at
>> last.
>> I adapted the tasklist example from aries jpa for karaf boot.
>>
>> You can find the result in a branch:
>>
>> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>>
>> The example contains a JPA persistence unit, a TaskService which
>> implements a JPA based repository and a servlet using the http-whiteboard.
>>
>> I did a little different approach to what JB used with the starter pom and
>> the karaf boot plugin.
>>
>> - I created a karaf-boot-api with the same idea like the enroute base-api.
>> It is a pom that contains all APIs you will likely need for starting a real
>> business application.
>> This is the only dependency of the sample. So people starting with this
>> pom will be able to start coding business code without thinking about the
>> necessary libs.
>> I also put some test dependencies there like slf4j and junit to help
>> people with creating tests.
>> - I also created a karaf-boot-parent as a parent for all karaf-boot
>> samples. It sets up all the necessary plugins like maven-bundle-plugin or
>> compiler-plugin. This is different
>> from JBs approach of using a karaf-boot-plugin. I think the parent
>> approach is better as it is easier to understand and extend. People can
>> look into the parent to see what it does
>> and when their project grows they can copy/paste the useful parts into
>> their own parent.
>> - I externalized the osgi settings using an osgi.bnd file. This allows to
>> easily customize the OSGi settings without redefining the
>> maven-bundle-plugin. It is also compatible to bndtools 3.1
>> as far as I can tell. So it should make it easier to work on the code
>> using bndtools.
>>
>> Apart from that I created a small stub for defining a feature using
>> annotations:
>> This is how it could look like:
>>
>> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>>
>> @Feature(
>>           name="tasklist",
>>           version="1.0.0",
>>           features = {"jpa", "transaction", "hibernate", "http"},
>>           configFile = "org.ops4j.datasource-tasklist.cfg"
>> )
>>
>> The idea is to add this annotation to any class and then let a yet to be
>> written karaf-feature plugin create a feature.xml from it.
>> The result would be a feature with the given name and dependencies. The
>> feature would by default also contain the current bundle. So this would
>> allow to start with one maven project that contains everything to easily
>> get a small business application running.
>>
>> So some things left to do are:
>> - plugin for the feature creation
>> - plugin for packaging a self contained karaf including the application
>> and all deps and config. More or less this can be done with the current
>> karaf-maven-plugin but we need to tune it so it needs less configuration.
>> - plugin for running the application from the command line
>> - artifact for creating new karaf-boot applications
>> - documentation for the transition to a larger multi project setup with
>> its own parent. Maybe a separate artifact would also do, not sure
>> - Integration with bndtools to give the user a nicer IDE for OSGi than
>> plain eclipse
>>
>> I would be happy about any feedback.
>>
>> Christian
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

Basically a karaf boot application provides standard bundles and features.
So it should work like a normal application.

For the standalone packaging it depends on how we do it. If it is a 
standard karaf zip then it will work with pax exam out of the box.

Christian

On 16.12.2015 16:21, David Daniel wrote:
> Can a karaf boot application be loaded into pax exam 4.7 in a manner
> similar to a standard karaf application.  Would love to see a karaf boot
> application integrated with the bnd launcher as well.
>
> On Wed, Dec 16, 2015 at 9:54 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> I found a bit of time to work on the karaf-boot effort JB initiated at
>> last.
>> I adapted the tasklist example from aries jpa for karaf boot.
>>
>> You can find the result in a branch:
>>
>> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>>
>> The example contains a JPA persistence unit, a TaskService which
>> implements a JPA based repository and a servlet using the http-whiteboard.
>>
>> I did a little different approach to what JB used with the starter pom and
>> the karaf boot plugin.
>>
>> - I created a karaf-boot-api with the same idea like the enroute base-api.
>> It is a pom that contains all APIs you will likely need for starting a real
>> business application.
>> This is the only dependency of the sample. So people starting with this
>> pom will be able to start coding business code without thinking about the
>> necessary libs.
>> I also put some test dependencies there like slf4j and junit to help
>> people with creating tests.
>> - I also created a karaf-boot-parent as a parent for all karaf-boot
>> samples. It sets up all the necessary plugins like maven-bundle-plugin or
>> compiler-plugin. This is different
>> from JBs approach of using a karaf-boot-plugin. I think the parent
>> approach is better as it is easier to understand and extend. People can
>> look into the parent to see what it does
>> and when their project grows they can copy/paste the useful parts into
>> their own parent.
>> - I externalized the osgi settings using an osgi.bnd file. This allows to
>> easily customize the OSGi settings without redefining the
>> maven-bundle-plugin. It is also compatible to bndtools 3.1
>> as far as I can tell. So it should make it easier to work on the code
>> using bndtools.
>>
>> Apart from that I created a small stub for defining a feature using
>> annotations:
>> This is how it could look like:
>>
>> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>>
>> @Feature(
>>           name="tasklist",
>>           version="1.0.0",
>>           features = {"jpa", "transaction", "hibernate", "http"},
>>           configFile = "org.ops4j.datasource-tasklist.cfg"
>> )
>>
>> The idea is to add this annotation to any class and then let a yet to be
>> written karaf-feature plugin create a feature.xml from it.
>> The result would be a feature with the given name and dependencies. The
>> feature would by default also contain the current bundle. So this would
>> allow to start with one maven project that contains everything to easily
>> get a small business application running.
>>
>> So some things left to do are:
>> - plugin for the feature creation
>> - plugin for packaging a self contained karaf including the application
>> and all deps and config. More or less this can be done with the current
>> karaf-maven-plugin but we need to tune it so it needs less configuration.
>> - plugin for running the application from the command line
>> - artifact for creating new karaf-boot applications
>> - documentation for the transition to a larger multi project setup with
>> its own parent. Maybe a separate artifact would also do, not sure
>> - Integration with bndtools to give the user a nicer IDE for OSGi than
>> plain eclipse
>>
>> I would be happy about any feedback.
>>
>> Christian
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>


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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[David Daniel <da...@gmail.com>]

Can a karaf boot application be loaded into pax exam 4.7 in a manner
similar to a standard karaf application.  Would love to see a karaf boot
application integrated with the bnd launcher as well.

On Wed, Dec 16, 2015 at 9:54 AM, Christian Schneider <
chris@die-schneider.net> wrote:

> I found a bit of time to work on the karaf-boot effort JB initiated at
> last.
> I adapted the tasklist example from aries jpa for karaf boot.
>
> You can find the result in a branch:
>
> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>
> The example contains a JPA persistence unit, a TaskService which
> implements a JPA based repository and a servlet using the http-whiteboard.
>
> I did a little different approach to what JB used with the starter pom and
> the karaf boot plugin.
>
> - I created a karaf-boot-api with the same idea like the enroute base-api.
> It is a pom that contains all APIs you will likely need for starting a real
> business application.
> This is the only dependency of the sample. So people starting with this
> pom will be able to start coding business code without thinking about the
> necessary libs.
> I also put some test dependencies there like slf4j and junit to help
> people with creating tests.
> - I also created a karaf-boot-parent as a parent for all karaf-boot
> samples. It sets up all the necessary plugins like maven-bundle-plugin or
> compiler-plugin. This is different
> from JBs approach of using a karaf-boot-plugin. I think the parent
> approach is better as it is easier to understand and extend. People can
> look into the parent to see what it does
> and when their project grows they can copy/paste the useful parts into
> their own parent.
> - I externalized the osgi settings using an osgi.bnd file. This allows to
> easily customize the OSGi settings without redefining the
> maven-bundle-plugin. It is also compatible to bndtools 3.1
> as far as I can tell. So it should make it easier to work on the code
> using bndtools.
>
> Apart from that I created a small stub for defining a feature using
> annotations:
> This is how it could look like:
>
> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>
> @Feature(
>          name="tasklist",
>          version="1.0.0",
>          features = {"jpa", "transaction", "hibernate", "http"},
>          configFile = "org.ops4j.datasource-tasklist.cfg"
> )
>
> The idea is to add this annotation to any class and then let a yet to be
> written karaf-feature plugin create a feature.xml from it.
> The result would be a feature with the given name and dependencies. The
> feature would by default also contain the current bundle. So this would
> allow to start with one maven project that contains everything to easily
> get a small business application running.
>
> So some things left to do are:
> - plugin for the feature creation
> - plugin for packaging a self contained karaf including the application
> and all deps and config. More or less this can be done with the current
> karaf-maven-plugin but we need to tune it so it needs less configuration.
> - plugin for running the application from the command line
> - artifact for creating new karaf-boot applications
> - documentation for the transition to a larger multi project setup with
> its own parent. Maybe a separate artifact would also do, not sure
> - Integration with bndtools to give the user a nicer IDE for OSGi than
> plain eclipse
>
> I would be happy about any feedback.
>
> Christian
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

It's what I meant: the parent pom (via a plugin) could create the 
osgi.bnd file for the user (even if it's a simple one).

Regards
JB

On 12/16/2015 04:44 PM, Christian Schneider wrote:
> We could of course also put all the apis in the parent.
>
> Unfortunately a pom can not provide a osgi.bnd. So for now if we want to
> use it and I think it makes sense you have to create it. We should be
> able to change that though.
>
> Christian
>
> On 16.12.2015 16:38, Jean-Baptiste Onofré wrote:
>> I see your point about starter. maybe just karaf-boot ? So we can have
>> karaf-boot, karaf-boot-core, and karaf-boot-parent ?
>>
>> For the osgi.bnd, if the karaf-boot (aka
>> karaf-boot-starter/karaf-boot-api) can provide a default one, it's
>> fine for me.
>>
>> We will provide an archetype, but anyway, the purpose of karaf-boot is
>> also to be able to start very quickly: so a very basic pom.xml just
>> defining karaf-boot-parent should be enough.
>>
>> Regards
>> JB
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

We could of course also put all the apis in the parent.

Unfortunately a pom can not provide a osgi.bnd. So for now if we want to 
use it and I think it makes sense you have to create it. We should be 
able to change that though.

Christian

On 16.12.2015 16:38, Jean-Baptiste Onofré wrote:
> I see your point about starter. maybe just karaf-boot ? So we can have 
> karaf-boot, karaf-boot-core, and karaf-boot-parent ?
>
> For the osgi.bnd, if the karaf-boot (aka 
> karaf-boot-starter/karaf-boot-api) can provide a default one, it's 
> fine for me.
>
> We will provide an archetype, but anyway, the purpose of karaf-boot is 
> also to be able to start very quickly: so a very basic pom.xml just 
> defining karaf-boot-parent should be enough.
>
> Regards
> JB

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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

I see your point about starter. maybe just karaf-boot ? So we can have 
karaf-boot, karaf-boot-core, and karaf-boot-parent ?

For the osgi.bnd, if the karaf-boot (aka 
karaf-boot-starter/karaf-boot-api) can provide a default one, it's fine 
for me.

We will provide an archetype, but anyway, the purpose of karaf-boot is 
also to be able to start very quickly: so a very basic pom.xml just 
defining karaf-boot-parent should be enough.

Regards
JB

On 12/16/2015 04:30 PM, Christian Schneider wrote:
> I think the name starter is misleading. When I read it first I thought
> it was some way to boot up the application
> but after all it is just a name.
>
> About the osgi.bnd. Currently you have to provide it but this can
> probably be changed either in the maven-bundle-plugin or in bnd itself.
> I would also prefer to just create it if you really want to tweak
> something.
> On the other hand it is not a big problem as we will most probably
> provide a archetype that contains it anyway. For the archetype I would
> even provide an empty osgi.bnd as it is easier to edit it than to know
> that you have to create a file with this name.
>
> Christian
>
> On 16.12.2015 16:22, Jean-Baptiste Onofré wrote:
>> Hi Christian,
>>
>> thanks for this !
>>
>> karaf-boot-api sounds like the BOM that I proposed in
>> karaf-boot-starter. It sounds good to me, but maybe the
>> karaf-boot-starter name is better than API (or it makes sense if we
>> add some annotations/extensions).
>>
>> For the parent pom, as already said on IRC, it was my first intention
>> and we discussed on the mailing list. Achim convinced me to go on a
>> less intrusive approach. The only drawback with a parent POM is that
>> users have to define it in their POM. At the end, I think it's not a
>> big deal and it makes sense as it can be the parent pom of the user
>> parent pom ;)
>> One of the key purpose of the karaf-boot is to be very very very (and
>> 10x very ;)) easy to start with and use. So, if parent pom is easier,
>> I'm OK with that.
>>
>> For the "external" osgi.bnd, it's also fine for me as soon as the user
>> doesn't have to provide one by default (again, simple). If the user
>> wants to tweak, he can provide a custom osgi.bnd.
>>
>> I like the idea of the annotations for the feature, it's exactly
>> aligned with karaf-boot ideas. Big +1 for this.
>>
>> Thanks !
>>
>> Regards
>> JB
>>
>> On 12/16/2015 03:54 PM, Christian Schneider wrote:
>>> I found a bit of time to work on the karaf-boot effort JB initiated at
>>> last.
>>> I adapted the tasklist example from aries jpa for karaf boot.
>>>
>>> You can find the result in a branch:
>>> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>>>
>>>
>>>
>>> The example contains a JPA persistence unit, a TaskService which
>>> implements a JPA based repository and a servlet using the
>>> http-whiteboard.
>>>
>>> I did a little different approach to what JB used with the starter pom
>>> and the karaf boot plugin.
>>>
>>> - I created a karaf-boot-api with the same idea like the enroute
>>> base-api. It is a pom that contains all APIs you will likely need for
>>> starting a real business application.
>>> This is the only dependency of the sample. So people starting with this
>>> pom will be able to start coding business code without thinking about
>>> the necessary libs.
>>> I also put some test dependencies there like slf4j and junit to help
>>> people with creating tests.
>>> - I also created a karaf-boot-parent as a parent for all karaf-boot
>>> samples. It sets up all the necessary plugins like maven-bundle-plugin
>>> or compiler-plugin. This is different
>>> from JBs approach of using a karaf-boot-plugin. I think the parent
>>> approach is better as it is easier to understand and extend. People can
>>> look into the parent to see what it does
>>> and when their project grows they can copy/paste the useful parts into
>>> their own parent.
>>> - I externalized the osgi settings using an osgi.bnd file. This allows
>>> to easily customize the OSGi settings without redefining the
>>> maven-bundle-plugin. It is also compatible to bndtools 3.1
>>> as far as I can tell. So it should make it easier to work on the code
>>> using bndtools.
>>>
>>> Apart from that I created a small stub for defining a feature using
>>> annotations:
>>> This is how it could look like:
>>> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>>>
>>>
>>>
>>> @Feature(
>>>           name="tasklist",
>>>           version="1.0.0",
>>>           features = {"jpa", "transaction", "hibernate", "http"},
>>>           configFile = "org.ops4j.datasource-tasklist.cfg"
>>> )
>>>
>>> The idea is to add this annotation to any class and then let a yet to be
>>> written karaf-feature plugin create a feature.xml from it.
>>> The result would be a feature with the given name and dependencies. The
>>> feature would by default also contain the current bundle. So this would
>>> allow to start with one maven project that contains everything to easily
>>> get a small business application running.
>>>
>>> So some things left to do are:
>>> - plugin for the feature creation
>>> - plugin for packaging a self contained karaf including the application
>>> and all deps and config. More or less this can be done with the current
>>> karaf-maven-plugin but we need to tune it so it needs less
>>> configuration.
>>> - plugin for running the application from the command line
>>> - artifact for creating new karaf-boot applications
>>> - documentation for the transition to a larger multi project setup with
>>> its own parent. Maybe a separate artifact would also do, not sure
>>> - Integration with bndtools to give the user a nicer IDE for OSGi than
>>> plain eclipse
>>>
>>> I would be happy about any feedback.
>>>
>>> Christian
>>>
>>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

[Christian Schneider <ch...@die-schneider.net>]

I think the name starter is misleading. When I read it first I thought 
it was some way to boot up the application
but after all it is just a name.

About the osgi.bnd. Currently you have to provide it but this can 
probably be changed either in the maven-bundle-plugin or in bnd itself. 
I would also prefer to just create it if you really want to tweak something.
On the other hand it is not a big problem as we will most probably 
provide a archetype that contains it anyway. For the archetype I would 
even provide an empty osgi.bnd as it is easier to edit it than to know 
that you have to create a file with this name.

Christian

On 16.12.2015 16:22, Jean-Baptiste Onofré wrote:
> Hi Christian,
>
> thanks for this !
>
> karaf-boot-api sounds like the BOM that I proposed in 
> karaf-boot-starter. It sounds good to me, but maybe the 
> karaf-boot-starter name is better than API (or it makes sense if we 
> add some annotations/extensions).
>
> For the parent pom, as already said on IRC, it was my first intention 
> and we discussed on the mailing list. Achim convinced me to go on a 
> less intrusive approach. The only drawback with a parent POM is that 
> users have to define it in their POM. At the end, I think it's not a 
> big deal and it makes sense as it can be the parent pom of the user 
> parent pom ;)
> One of the key purpose of the karaf-boot is to be very very very (and 
> 10x very ;)) easy to start with and use. So, if parent pom is easier, 
> I'm OK with that.
>
> For the "external" osgi.bnd, it's also fine for me as soon as the user 
> doesn't have to provide one by default (again, simple). If the user 
> wants to tweak, he can provide a custom osgi.bnd.
>
> I like the idea of the annotations for the feature, it's exactly 
> aligned with karaf-boot ideas. Big +1 for this.
>
> Thanks !
>
> Regards
> JB
>
> On 12/16/2015 03:54 PM, Christian Schneider wrote:
>> I found a bit of time to work on the karaf-boot effort JB initiated at
>> last.
>> I adapted the tasklist example from aries jpa for karaf boot.
>>
>> You can find the result in a branch:
>> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist 
>>
>>
>>
>> The example contains a JPA persistence unit, a TaskService which
>> implements a JPA based repository and a servlet using the 
>> http-whiteboard.
>>
>> I did a little different approach to what JB used with the starter pom
>> and the karaf boot plugin.
>>
>> - I created a karaf-boot-api with the same idea like the enroute
>> base-api. It is a pom that contains all APIs you will likely need for
>> starting a real business application.
>> This is the only dependency of the sample. So people starting with this
>> pom will be able to start coding business code without thinking about
>> the necessary libs.
>> I also put some test dependencies there like slf4j and junit to help
>> people with creating tests.
>> - I also created a karaf-boot-parent as a parent for all karaf-boot
>> samples. It sets up all the necessary plugins like maven-bundle-plugin
>> or compiler-plugin. This is different
>> from JBs approach of using a karaf-boot-plugin. I think the parent
>> approach is better as it is easier to understand and extend. People can
>> look into the parent to see what it does
>> and when their project grows they can copy/paste the useful parts into
>> their own parent.
>> - I externalized the osgi settings using an osgi.bnd file. This allows
>> to easily customize the OSGi settings without redefining the
>> maven-bundle-plugin. It is also compatible to bndtools 3.1
>> as far as I can tell. So it should make it easier to work on the code
>> using bndtools.
>>
>> Apart from that I created a small stub for defining a feature using
>> annotations:
>> This is how it could look like:
>> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java 
>>
>>
>>
>> @Feature(
>>           name="tasklist",
>>           version="1.0.0",
>>           features = {"jpa", "transaction", "hibernate", "http"},
>>           configFile = "org.ops4j.datasource-tasklist.cfg"
>> )
>>
>> The idea is to add this annotation to any class and then let a yet to be
>> written karaf-feature plugin create a feature.xml from it.
>> The result would be a feature with the given name and dependencies. The
>> feature would by default also contain the current bundle. So this would
>> allow to start with one maven project that contains everything to easily
>> get a small business application running.
>>
>> So some things left to do are:
>> - plugin for the feature creation
>> - plugin for packaging a self contained karaf including the application
>> and all deps and config. More or less this can be done with the current
>> karaf-maven-plugin but we need to tune it so it needs less 
>> configuration.
>> - plugin for running the application from the command line
>> - artifact for creating new karaf-boot applications
>> - documentation for the transition to a larger multi project setup with
>> its own parent. Maybe a separate artifact would also do, not sure
>> - Integration with bndtools to give the user a nicer IDE for OSGi than
>> plain eclipse
>>
>> I would be happy about any feedback.
>>
>> Christian
>>
>>
>


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

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

Re: [karaf boot] Added a DS sample with Servlet and JPA and slightly different setup

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

Hi Christian,

thanks for this !

karaf-boot-api sounds like the BOM that I proposed in 
karaf-boot-starter. It sounds good to me, but maybe the 
karaf-boot-starter name is better than API (or it makes sense if we add 
some annotations/extensions).

For the parent pom, as already said on IRC, it was my first intention 
and we discussed on the mailing list. Achim convinced me to go on a less 
intrusive approach. The only drawback with a parent POM is that users 
have to define it in their POM. At the end, I think it's not a big deal 
and it makes sense as it can be the parent pom of the user parent pom ;)
One of the key purpose of the karaf-boot is to be very very very (and 
10x very ;)) easy to start with and use. So, if parent pom is easier, 
I'm OK with that.

For the "external" osgi.bnd, it's also fine for me as soon as the user 
doesn't have to provide one by default (again, simple). If the user 
wants to tweak, he can provide a custom osgi.bnd.

I like the idea of the annotations for the feature, it's exactly aligned 
with karaf-boot ideas. Big +1 for this.

Thanks !

Regards
JB

On 12/16/2015 03:54 PM, Christian Schneider wrote:
> I found a bit of time to work on the karaf-boot effort JB initiated at
> last.
> I adapted the tasklist example from aries jpa for karaf boot.
>
> You can find the result in a branch:
> https://github.com/jbonofre/karaf-boot/tree/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist
>
>
> The example contains a JPA persistence unit, a TaskService which
> implements a JPA based repository and a servlet using the http-whiteboard.
>
> I did a little different approach to what JB used with the starter pom
> and the karaf boot plugin.
>
> - I created a karaf-boot-api with the same idea like the enroute
> base-api. It is a pom that contains all APIs you will likely need for
> starting a real business application.
> This is the only dependency of the sample. So people starting with this
> pom will be able to start coding business code without thinking about
> the necessary libs.
> I also put some test dependencies there like slf4j and junit to help
> people with creating tests.
> - I also created a karaf-boot-parent as a parent for all karaf-boot
> samples. It sets up all the necessary plugins like maven-bundle-plugin
> or compiler-plugin. This is different
> from JBs approach of using a karaf-boot-plugin. I think the parent
> approach is better as it is easier to understand and extend. People can
> look into the parent to see what it does
> and when their project grows they can copy/paste the useful parts into
> their own parent.
> - I externalized the osgi settings using an osgi.bnd file. This allows
> to easily customize the OSGi settings without redefining the
> maven-bundle-plugin. It is also compatible to bndtools 3.1
> as far as I can tell. So it should make it easier to work on the code
> using bndtools.
>
> Apart from that I created a small stub for defining a feature using
> annotations:
> This is how it could look like:
> https://github.com/jbonofre/karaf-boot/blob/tasklist-sample/karaf-boot-samples/karaf-boot-sample-tasklist/src/main/java/org/apache/aries/jpa/example/tasklist/feature/TasklistFeature.java
>
>
> @Feature(
>           name="tasklist",
>           version="1.0.0",
>           features = {"jpa", "transaction", "hibernate", "http"},
>           configFile = "org.ops4j.datasource-tasklist.cfg"
> )
>
> The idea is to add this annotation to any class and then let a yet to be
> written karaf-feature plugin create a feature.xml from it.
> The result would be a feature with the given name and dependencies. The
> feature would by default also contain the current bundle. So this would
> allow to start with one maven project that contains everything to easily
> get a small business application running.
>
> So some things left to do are:
> - plugin for the feature creation
> - plugin for packaging a self contained karaf including the application
> and all deps and config. More or less this can be done with the current
> karaf-maven-plugin but we need to tune it so it needs less configuration.
> - plugin for running the application from the command line
> - artifact for creating new karaf-boot applications
> - documentation for the transition to a larger multi project setup with
> its own parent. Maybe a separate artifact would also do, not sure
> - Integration with bndtools to give the user a nicer IDE for OSGi than
> plain eclipse
>
> I would be happy about any feedback.
>
> Christian
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com