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

[Jean-Baptiste Onofré]

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é  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é 
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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com







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







--
Jean-Baptiste Onofré
jbono...@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]

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

On 17 December 2015 at 14:24, Jean-Baptiste Onofré  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é 
>> 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é
>>> jbono...@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

[Jean-Baptiste Onofré]

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é  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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com







--
Jean-Baptiste Onofré
jbono...@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]

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

On 17 December 2015 at 04:46, Jean-Baptiste Onofré  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é
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Matt Sicker 

Re: [HEADS UP] Marketing and releases schedule

[Serge Huber]

I can vote based on what I’ve seen, it’s better anyway that what exists right 
now :) 

More seriously the only thing I would suggest, but this can wait for after it’s 
in place, are some minor CSS tweeks but I wanted to suggest them myself :) 

It’s mostly because I’m a bit of a design nitpicker, and prefer to suggest 
things than to annoy people with them :) 

cheers,
  Serge… 


> On 17 déc. 2015, at 14:38, Jean-Baptiste Onofré  wrote:
> 
> It was my intention: start a vote during the week end or next week, and have 
> it closed before Christmas.
> 
> I just hope I will get all feedbacks soon, in order to be able to start the 
> vote asap.
> 
> Thanks,
> Regards
> JB
> 
> On 12/17/2015 02:35 PM, Morgan Hautman wrote:
>> Hi,
>> 
>> I would propose to do a vote when the new version comes out to see if we
>> push or not.
>> 
>> WDYT?
>> 
>> Regards,
>> Morgan
>> 
>> On 12/17/2015 02:15 PM, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>> 
>>> I would like to really move forward fast on this topic.
>>> 
>>> About the website, I will publish a new version on my server
>>> implementing Achim's comments.
>>> Even that, is everybody agree if I push it soon (during the week end
>>> of next week) ? I would like to promote it before christmas.
>>> 
>>> Regarding the manual, it's allmost done for the asciidoc usage on all
>>> modules. I'm still working on the dev guide refactoring.
>>> 
>>> Thanks !
>>> Regards
>>> JB
>>> 
>>> On 12/15/2015 09:14 AM, Achim Nierbeck wrote:
 Hi JB,
 
 +1 on on the schedule and 1 to 3 :)
 
 regarding website, following points came to my mind:
 
 The top menu ... I'd like to have it there all the time, maybe turning a
 bit smaller while scrolling :-)
 The intro page looks great on a mobile device but is lacking the
 documentation part
 all other pages don't look good on a mobile device due to the menu on
 the
 left ... :/
 
 On the first page, left of the Icon we might need to change that to a
 Prominent "Apache Karaf (icon)" cause the feather on the right isn't
 really
 eye-catching enough to tell it's an apache page.
 
 The documentation and Projects page ... it could need a bit "space" the
 lines are sitting to much on top of each other and it's hard to grasp
 the
 content right away when flying over the page (as people usually tend
 to do)
 maybe get rid of the bullet points ... ( allways reminds me of "shot
 by the
 bulletpoint" :D)
 
 Besides those minor points it looks really good to me :D
 
 thanks for such a great work.
 
 regards, Achim
 
 
 
 2015-12-14 21:15 GMT+01:00 Jean-Baptiste Onofré :
 
> Hi all,
> 
> just a quick update and help request ;)
> 
> First, about the releases, Karaf 4.0.4 is again postponed for three
> reasons:
> 1. Christian and Guillaume are working on new Aries releases that we
> will
> include in Karaf 4.0.4
> 2. I have several bug fixes on local branches that I will push
> 3. I finally merge the new Maven plugin goals (especially run,
> deploy, and
> client). I'm testing it and I will push as well.
> 
> Second, about the website proposal, it would be great if some of you
> can
> take a tour and send the feedback to me (private message, no need to
> flood
> the mailing list).
> 
> I'm a bit busy with couple of Karaf partners/users this week, but I
> will
> have time early on the mornings and during nights ;)
> 
> Thanks !
> Regards
> JB
> 
> On 11/25/2015 09:09 AM, Jean-Baptiste Onofré wrote:
> 
>> Hi all,
>> 
>> I gonna work on "marketing" this afternoon (new website and
>> documentation improvements). I will update you later today with latest
>> changes on my server to discuss. I would like to move forward on this
>> (both new website and new documentation) during the week end.
>> 
>> On the other hand, I propose the following release plan:
>> 
>> - Karaf Cave 4.0.1 (beginning of next week): I fixed couple of issues
>> and add new features on a local branch (especially Cave is able to
>> "gather" multiple repository.xml in one, and create one repository.xml
>> per artifact if wanted)
>> - Karaf Cellar 4.0.1 (during the week end): I fixed couple of issues
>> (especially one related to Hazelcast configuration parsing with Saxon)
>> and added some new features.
>> - Karaf Decanter 1.0.2 (end of next week): several new features
>> (ActiveMQ logging plugin, Redis appender, ...) have been added
>> - Karaf Container 4.0.4 (if we use the new wording proposal ;))
>> (middle
>> of next week): several bug fixes and preparation for the karaf-4.0.x
>> branch
>> 
>> On the other hand, I plan to move forward on karaf-boot. About
>> this, any
>> help would be more than appreciated ! As Achim said, I wo

Re: [HEADS UP] Marketing and releases schedule

[Jean-Baptiste Onofré]

It was my intention: start a vote during the week end or next week, and 
have it closed before Christmas.


I just hope I will get all feedbacks soon, in order to be able to start 
the vote asap.


Thanks,
Regards
JB

On 12/17/2015 02:35 PM, Morgan Hautman wrote:

Hi,

I would propose to do a vote when the new version comes out to see if we
push or not.

WDYT?

Regards,
Morgan

On 12/17/2015 02:15 PM, Jean-Baptiste Onofré wrote:

Hi all,

I would like to really move forward fast on this topic.

About the website, I will publish a new version on my server
implementing Achim's comments.
Even that, is everybody agree if I push it soon (during the week end
of next week) ? I would like to promote it before christmas.

Regarding the manual, it's allmost done for the asciidoc usage on all
modules. I'm still working on the dev guide refactoring.

Thanks !
Regards
JB

On 12/15/2015 09:14 AM, Achim Nierbeck wrote:

Hi JB,

+1 on on the schedule and 1 to 3 :)

regarding website, following points came to my mind:

The top menu ... I'd like to have it there all the time, maybe turning a
bit smaller while scrolling :-)
The intro page looks great on a mobile device but is lacking the
documentation part
all other pages don't look good on a mobile device due to the menu on
the
left ... :/

On the first page, left of the Icon we might need to change that to a
Prominent "Apache Karaf (icon)" cause the feather on the right isn't
really
eye-catching enough to tell it's an apache page.

The documentation and Projects page ... it could need a bit "space" the
lines are sitting to much on top of each other and it's hard to grasp
the
content right away when flying over the page (as people usually tend
to do)
maybe get rid of the bullet points ... ( allways reminds me of "shot
by the
bulletpoint" :D)

Besides those minor points it looks really good to me :D

thanks for such a great work.

regards, Achim



2015-12-14 21:15 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

just a quick update and help request ;)

First, about the releases, Karaf 4.0.4 is again postponed for three
reasons:
1. Christian and Guillaume are working on new Aries releases that we
will
include in Karaf 4.0.4
2. I have several bug fixes on local branches that I will push
3. I finally merge the new Maven plugin goals (especially run,
deploy, and
client). I'm testing it and I will push as well.

Second, about the website proposal, it would be great if some of you
can
take a tour and send the feedback to me (private message, no need to
flood
the mailing list).

I'm a bit busy with couple of Karaf partners/users this week, but I
will
have time early on the mornings and during nights ;)

Thanks !
Regards
JB

On 11/25/2015 09:09 AM, Jean-Baptiste Onofré wrote:


Hi all,

I gonna work on "marketing" this afternoon (new website and
documentation improvements). I will update you later today with latest
changes on my server to discuss. I would like to move forward on this
(both new website and new documentation) during the week end.

On the other hand, I propose the following release plan:

- Karaf Cave 4.0.1 (beginning of next week): I fixed couple of issues
and add new features on a local branch (especially Cave is able to
"gather" multiple repository.xml in one, and create one repository.xml
per artifact if wanted)
- Karaf Cellar 4.0.1 (during the week end): I fixed couple of issues
(especially one related to Hazelcast configuration parsing with Saxon)
and added some new features.
- Karaf Decanter 1.0.2 (end of next week): several new features
(ActiveMQ logging plugin, Redis appender, ...) have been added
- Karaf Container 4.0.4 (if we use the new wording proposal ;))
(middle
of next week): several bug fixes and preparation for the karaf-4.0.x
branch

On the other hand, I plan to move forward on karaf-boot. About
this, any
help would be more than appreciated ! As Achim said, I wonder if it
makes sense to keep it on my github or if I can already create a
branch
in Karaf for that. Let me know.

Thoughts ?

Regards
JB



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











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

Re: [HEADS UP] Marketing and releases schedule

[Morgan Hautman]

Hi,

I would propose to do a vote when the new version comes out to see if we 
push or not.


WDYT?

Regards,
Morgan

On 12/17/2015 02:15 PM, Jean-Baptiste Onofré wrote:

Hi all,

I would like to really move forward fast on this topic.

About the website, I will publish a new version on my server 
implementing Achim's comments.
Even that, is everybody agree if I push it soon (during the week end 
of next week) ? I would like to promote it before christmas.


Regarding the manual, it's allmost done for the asciidoc usage on all 
modules. I'm still working on the dev guide refactoring.


Thanks !
Regards
JB

On 12/15/2015 09:14 AM, Achim Nierbeck wrote:

Hi JB,

+1 on on the schedule and 1 to 3 :)

regarding website, following points came to my mind:

The top menu ... I'd like to have it there all the time, maybe turning a
bit smaller while scrolling :-)
The intro page looks great on a mobile device but is lacking the
documentation part
all other pages don't look good on a mobile device due to the menu on 
the

left ... :/

On the first page, left of the Icon we might need to change that to a
Prominent "Apache Karaf (icon)" cause the feather on the right isn't 
really

eye-catching enough to tell it's an apache page.

The documentation and Projects page ... it could need a bit "space" the
lines are sitting to much on top of each other and it's hard to grasp 
the
content right away when flying over the page (as people usually tend 
to do)
maybe get rid of the bullet points ... ( allways reminds me of "shot 
by the

bulletpoint" :D)

Besides those minor points it looks really good to me :D

thanks for such a great work.

regards, Achim



2015-12-14 21:15 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

just a quick update and help request ;)

First, about the releases, Karaf 4.0.4 is again postponed for three
reasons:
1. Christian and Guillaume are working on new Aries releases that we 
will

include in Karaf 4.0.4
2. I have several bug fixes on local branches that I will push
3. I finally merge the new Maven plugin goals (especially run, 
deploy, and

client). I'm testing it and I will push as well.

Second, about the website proposal, it would be great if some of you 
can
take a tour and send the feedback to me (private message, no need to 
flood

the mailing list).

I'm a bit busy with couple of Karaf partners/users this week, but I 
will

have time early on the mornings and during nights ;)

Thanks !
Regards
JB

On 11/25/2015 09:09 AM, Jean-Baptiste Onofré wrote:


Hi all,

I gonna work on "marketing" this afternoon (new website and
documentation improvements). I will update you later today with latest
changes on my server to discuss. I would like to move forward on this
(both new website and new documentation) during the week end.

On the other hand, I propose the following release plan:

- Karaf Cave 4.0.1 (beginning of next week): I fixed couple of issues
and add new features on a local branch (especially Cave is able to
"gather" multiple repository.xml in one, and create one repository.xml
per artifact if wanted)
- Karaf Cellar 4.0.1 (during the week end): I fixed couple of issues
(especially one related to Hazelcast configuration parsing with Saxon)
and added some new features.
- Karaf Decanter 1.0.2 (end of next week): several new features
(ActiveMQ logging plugin, Redis appender, ...) have been added
- Karaf Container 4.0.4 (if we use the new wording proposal ;)) 
(middle

of next week): several bug fixes and preparation for the karaf-4.0.x
branch

On the other hand, I plan to move forward on karaf-boot. About 
this, any

help would be more than appreciated ! As Achim said, I wonder if it
makes sense to keep it on my github or if I can already create a 
branch

in Karaf for that. Let me know.

Thoughts ?

Regards
JB



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

Re: [HEADS UP] Marketing and releases schedule

[Jean-Baptiste Onofré]

Hi all,

I would like to really move forward fast on this topic.

About the website, I will publish a new version on my server 
implementing Achim's comments.
Even that, is everybody agree if I push it soon (during the week end of 
next week) ? I would like to promote it before christmas.


Regarding the manual, it's allmost done for the asciidoc usage on all 
modules. I'm still working on the dev guide refactoring.


Thanks !
Regards
JB

On 12/15/2015 09:14 AM, Achim Nierbeck wrote:

Hi JB,

+1 on on the schedule and 1 to 3 :)

regarding website, following points came to my mind:

The top menu ... I'd like to have it there all the time, maybe turning a
bit smaller while scrolling :-)
The intro page looks great on a mobile device but is lacking the
documentation part
all other pages don't look good on a mobile device due to the menu on the
left ... :/

On the first page, left of the Icon we might need to change that to a
Prominent "Apache Karaf (icon)" cause the feather on the right isn't really
eye-catching enough to tell it's an apache page.

The documentation and Projects page ... it could need a bit "space" the
lines are sitting to much on top of each other and it's hard to grasp the
content right away when flying over the page (as people usually tend to do)
maybe get rid of the bullet points ... ( allways reminds me of "shot by the
bulletpoint" :D)

Besides those minor points it looks really good to me :D

thanks for such a great work.

regards, Achim



2015-12-14 21:15 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

just a quick update and help request ;)

First, about the releases, Karaf 4.0.4 is again postponed for three
reasons:
1. Christian and Guillaume are working on new Aries releases that we will
include in Karaf 4.0.4
2. I have several bug fixes on local branches that I will push
3. I finally merge the new Maven plugin goals (especially run, deploy, and
client). I'm testing it and I will push as well.

Second, about the website proposal, it would be great if some of you can
take a tour and send the feedback to me (private message, no need to flood
the mailing list).

I'm a bit busy with couple of Karaf partners/users this week, but I will
have time early on the mornings and during nights ;)

Thanks !
Regards
JB

On 11/25/2015 09:09 AM, Jean-Baptiste Onofré wrote:


Hi all,

I gonna work on "marketing" this afternoon (new website and
documentation improvements). I will update you later today with latest
changes on my server to discuss. I would like to move forward on this
(both new website and new documentation) during the week end.

On the other hand, I propose the following release plan:

- Karaf Cave 4.0.1 (beginning of next week): I fixed couple of issues
and add new features on a local branch (especially Cave is able to
"gather" multiple repository.xml in one, and create one repository.xml
per artifact if wanted)
- Karaf Cellar 4.0.1 (during the week end): I fixed couple of issues
(especially one related to Hazelcast configuration parsing with Saxon)
and added some new features.
- Karaf Decanter 1.0.2 (end of next week): several new features
(ActiveMQ logging plugin, Redis appender, ...) have been added
- Karaf Container 4.0.4 (if we use the new wording proposal ;)) (middle
of next week): several bug fixes and preparation for the karaf-4.0.x
branch

On the other hand, I plan to move forward on karaf-boot. About this, any
help would be more than appreciated ! As Achim said, I wonder if it
makes sense to keep it on my github or if I can already create a branch
in Karaf for that. Let me know.

Thoughts ?

Regards
JB



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







--
Jean-Baptiste Onofré
jbono...@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

[Jean-Baptiste Onofré]

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é
jbono...@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]

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-maven-plugin 4.0.4-SNAPSHOT

[Jean-Baptiste Onofré]

Hi Markus,

thanks !

Let me take a look on my machine.

Regards
JB

On 12/17/2015 10:57 AM, Markus Rathgeb wrote:

Just a note if you plan a release next week.
I believe there is something broken with the maven-metadata-local.xml
creation of the karaf-maven-plugin in the 4.0.4-SNAPHOST.
The files are empty on my system.
Using "mvn clean install -X" I see a lot of messages (sure, it depends
on the stuff that is packed to your "system" directory in the custom
distribution).

[DEBUG] File 'maven-metadata-local.xml' is not a features file.
org.xml.sax.SAXParseException; systemId:
file://maven-metadata-local.xml; lineNumber: 1; columnNumber:
1; Premature end of file.

The size of the maven-metadata-local.xml file is 0 bytes.

I will try to further inspect this.



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

Re: karaf-maven-plugin 4.0.4-SNAPSHOT

[Markus Rathgeb]

Will check if it is related to my commit (KARAF-4145) first.

2015-12-17 10:57 GMT+01:00 Markus Rathgeb :
> Just a note if you plan a release next week.
> I believe there is something broken with the maven-metadata-local.xml
> creation of the karaf-maven-plugin in the 4.0.4-SNAPHOST.
> The files are empty on my system.
> Using "mvn clean install -X" I see a lot of messages (sure, it depends
> on the stuff that is packed to your "system" directory in the custom
> distribution).
>
> [DEBUG] File 'maven-metadata-local.xml' is not a features file.
> org.xml.sax.SAXParseException; systemId:
> file://maven-metadata-local.xml; lineNumber: 1; columnNumber:
> 1; Premature end of file.
>
> The size of the maven-metadata-local.xml file is 0 bytes.
>
> I will try to further inspect this.

karaf-maven-plugin 4.0.4-SNAPSHOT

[Markus Rathgeb]

Just a note if you plan a release next week.
I believe there is something broken with the maven-metadata-local.xml
creation of the karaf-maven-plugin in the 4.0.4-SNAPHOST.
The files are empty on my system.
Using "mvn clean install -X" I see a lot of messages (sure, it depends
on the stuff that is packed to your "system" directory in the custom
distribution).

[DEBUG] File 'maven-metadata-local.xml' is not a features file.
org.xml.sax.SAXParseException; systemId:
file://maven-metadata-local.xml; lineNumber: 1; columnNumber:
1; Premature end of file.

The size of the maven-metadata-local.xml file is 0 bytes.

I will try to further inspect this.

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

[Jean-Baptiste Onofré]

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  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/k

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

[Serge Huber]

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  
> 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 :
>> 
>>> Probably not .. I just did not yet change it :-)
>>> Will fix it.
>>> 
>>> Christian
>>> 
>>> 2015-12-16 22:03 GMT+01:00 Tim Jones :
>>> 
 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

[Christian Schneider]

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 :


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

Christian

2015-12-16 22:03 GMT+01:00 Tim Jones :


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