Re: [PROPOSAL] Apache Karaf runtime releases and roadmap

2024-06-08 Thread Serge Huber
Hi François,

I understand not everything has to be native, but for example for Apache
Unomi the default deployment is now mostly in containers, and extensions
are usually deployed mostly in development environments and then statically
packaged for production deployments.

Having the option to then use Karaf 5 to leverage the benefits of GraalVM
Native Image would be very interesting I believe. I think other
applications might be interested in these types of scenarios: full OSGi for
development, maybe pre-production and testing, and possibility to have a
more « static » deployment for production that could be compatible with
native image.

WDYT ?

Regards,
   Serge…

Le jeu. 6 juin 2024 à 11:09, Francois Papon 
a écrit :

> Hi Serge,
>
> I don't think there is a benefit about GraalVM for long running process
> like Karaf. All java things doesn't need to be GraalVM native :)
>
> Another problem is that the community edition of GraalVM doesn't bring
> all the improvement as the commercial one (GC, PGO...)
>
> regards,
>
> François
>
> On 05/06/2024 15:13, Serge Huber wrote:
> > Hi JB thanks for the proposal,
> >
> > Sounds great to me. For me Karaf 5 should really be a natural fit for
> > containerized deployments, making it super easy to package applications
> > that can then easily be scaled up (and down), so making it more
> predictable
> > and possibly more static can be a good thing.
> >
> > Is a goal also to make it compatible with GraalVM Native Image ?
> >
> > Best regards,
> >Serge.
> >
> > On Tue, Jun 4, 2024 at 11:18 AM Jean-Baptiste Onofré 
> > wrote:
> >
> >> Hi folks,
> >>
> >> I think it's time to prepare a new milestone for the project :)
> >>
> >> Short term (and first step) is to prepare the coming release:
> >>
> >> 1. Apache Karaf 4.4.7 will be submitted to vote next week. It will
> include:
> >> * Improvement on the spring features repository (providing both
> >> Spring 5 and Spring 6 features)
> >> * Dependencies updates and minor fixes found on the 4.4.6 release
> >>
> >> 2. Apache Karaf 4.5.0 will be submitted to vote by the end of the
> >> month. It will include (mainly):
> >> * New spec features repository with Jakarta specs
> >> * Bigger fixes for 4.5.0
> >>
> >> 3. Apache Karaf 5.0.0
> >>That's the big milestone, and I propose to have big and opinionated
> >> changes here. OSGi is an implementation detail of the runtime, still
> >> exposed to the experimented users.
> >>Be opinionated means that I propose to remove PAX * dependencies,
> >> and provide Karaf services instead, very simple and opinionated (for
> >> instance, instead of PAX Web, a simple Tomcat based service, instead
> >> of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced
> >> by JUnit 5 simple extensions, etc).
> >>Another goal of Karaf 5 is to bring new tooling to improve dev
> >> experience (annotation based distributions generation, etc).
> >>Also, users will be able to smoothly deploy Spring powered or
> >> Servlet applications without knowing/leveraging OSGi (especially the
> >> import/export pattern).
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
>


Re: [PROPOSAL] Apache Karaf runtime releases and roadmap

2024-06-05 Thread Serge Huber
Hi JB thanks for the proposal,

Sounds great to me. For me Karaf 5 should really be a natural fit for
containerized deployments, making it super easy to package applications
that can then easily be scaled up (and down), so making it more predictable
and possibly more static can be a good thing.

Is a goal also to make it compatible with GraalVM Native Image ?

Best regards,
  Serge.

On Tue, Jun 4, 2024 at 11:18 AM Jean-Baptiste Onofré 
wrote:

> Hi folks,
>
> I think it's time to prepare a new milestone for the project :)
>
> Short term (and first step) is to prepare the coming release:
>
> 1. Apache Karaf 4.4.7 will be submitted to vote next week. It will include:
>* Improvement on the spring features repository (providing both
> Spring 5 and Spring 6 features)
>* Dependencies updates and minor fixes found on the 4.4.6 release
>
> 2. Apache Karaf 4.5.0 will be submitted to vote by the end of the
> month. It will include (mainly):
>* New spec features repository with Jakarta specs
>* Bigger fixes for 4.5.0
>
> 3. Apache Karaf 5.0.0
>   That's the big milestone, and I propose to have big and opinionated
> changes here. OSGi is an implementation detail of the runtime, still
> exposed to the experimented users.
>   Be opinionated means that I propose to remove PAX * dependencies,
> and provide Karaf services instead, very simple and opinionated (for
> instance, instead of PAX Web, a simple Tomcat based service, instead
> of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced
> by JUnit 5 simple extensions, etc).
>   Another goal of Karaf 5 is to bring new tooling to improve dev
> experience (annotation based distributions generation, etc).
>   Also, users will be able to smoothly deploy Spring powered or
> Servlet applications without knowing/leveraging OSGi (especially the
> import/export pattern).
>
> Thoughts ?
>
> Regards
> JB
>


Re: Board report for December 2023

2023-12-15 Thread Serge Huber
+1

I didn't get notifications for the Unomi project either, so it's late too
I'll get right on it. Anybody has any clues as to what is going on ?

Regards,
  Serge...
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Fri, Dec 15, 2023 at 2:46 PM Francois Papon 
wrote:

> +1
>
> regards,
>
> François
>
> On 15/12/2023 13:42, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > I'm sorry, we are late for the board report this month (I didn't
> > receive a reminder and forgot to create one).
> > So I quickly created a board report here:
> >
> > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
> >
> > Please take a look, I would like to send it asap (if possible tonight).
> >
> > Thanks !
> > Regards
> > JB
>


Re: Releases preparation

2023-11-05 Thread Serge Huber
Wow JB glad you're ok !

I for one fully understand that this work is not your priority and thanks
for sharing this update. Please take the time you need for what is truly
urgent :)

Cheers,
  Serge...

On Sun, Nov 5, 2023 at 7:35 AM Jean-Baptiste Onofré  wrote:

> Hi guys
>
> You might have seen I was pretty quiet recently. We have been hit by Ciaran
> storm. I don’t have electricity and Internet connection at home. As we have
> important damages on the house, we decided to rent a new house for a few
> days.
> I will be back online tonight and I will resume Karaf releases preparation
> tomorrow.
>
> Sorry for the delay.
>
> Regards
>


Re: [VOTE] Apache Karaf OSGi runtime 4.3.10 release

2023-09-14 Thread Serge Huber
Thanks JB,

+1 (non-binding)

from me !

cheers,
  Serge...

On Thu, Sep 14, 2023 at 6:34 PM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> I submit Apache Karaf OSGi runtime 4.3.10 release to your vote.
>
> This release is a maintenance release bringing fixes and dependency
> updates.
> Especially this release includes:
> - fix race condition between the FeaturesService and
> FeatureDeploymentListener
> - fix --patch-module on Instance startup
> - add exec:groovy shell command
> - dependency updates including CVE fixes (Johnzon, BouncyCastle,
> Commons FileUpload)
>
> You can take a look on the Release Notes for details:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352694
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1188/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.10/
>
> Git tag:
> karaf-4.3.10
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards
> JB
>


Re: [VOTE] Apache Karaf OSGi runtime 4.4.4 release

2023-09-13 Thread Serge Huber
Thanks JB for the release

+1 (non-binding)




On Wed, Sep 13, 2023 at 9:45 AM Jean-Baptiste Onofré 
wrote:

> Hi Robert,
>
> About jline, it has been postponed because it breaks the tab binding
> in the shell console, so I need more time to fix that (see
> https://issues.apache.org/jira/browse/KARAF-7723).
>
> commons-compress has been upgraded with the version available at time
> of release preparation
> (https://issues.apache.org/jira/browse/KARAF-7702). I will update for
> next release.
>
> wagon needs also pax-url update (in progress).
>
> NB: Karaf 4.4.5 will be submitted to vote very soon as I would like to
> provide Spring 6 features.
>
> Regards
> JB
>
> On Tue, Sep 12, 2023 at 9:14 PM Robert Varga  wrote:
> >
> > On 12/09/2023 17.06, Jean-Baptiste Onofré wrote:
> > > Hi guys,
> >
> > Hey JB,
> >
> > > After long weeks of wait, I submit Apache Karaf OSGi runtime 4.4.4
> > > release to your vote.
> >
> > Thanks a lot!
> >
> > > This release is a maintenance release bringing fixes and dependency
> updates.
> > > Especially this release includes:
> > > - fix race condition between the FeaturesService and
> FeatureDeploymentListener
> > > - fix --patch-module on Instance startup
> > > - add exec:groovy shell command
> > > - dependency updates including CVE fixes (Johnzon, BouncyCastle,
> > > Commons FileUpload)
> > > - better JDK20 support
> >
> > So there are a few third party upgrades missing:
> > - wagon-1.5.3
> > - jline-3.23.0
> > - commons-compress-1.24.0
> >
> > but I do not believe they are worth a respin. I have this upgrade
> > passing basic upgrade tests in ODL.
> >
> > > Please vote to approve this release:
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > +1, non-binding.
> >
> > Thanks again,
> > Robert
>


Re: Board Report for Dec 2022

2022-12-14 Thread Serge Huber
+1 (non binding)



On Thu, Dec 15, 2022 at 8:27 AM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> I prepared the board report for this month:
>
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
> Please take a look, I would like to submit asap (we should report by
> tomorrow).
>
> Thanks !
> Regards
> JB
>


Re: [VOTE] Accept Apache Karaf Minho in Apache Karaf

2022-10-14 Thread Serge Huber
+1 (non-binding)

Can’t wait :)

T +41 22 361 3424

9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 13 oct. 2022 à 16:08, Christian Schneider  a 
> écrit :
> 
> +1
> Christian
> 
>> Am Do., 13. Okt. 2022 um 08:47 Uhr schrieb Jean-Baptiste Onofré <
>> j...@nanthrax.net>:
>> 
>> Hi guys,
>> 
>> As discussed on the mailing list, I would like to start a formal vote
>> to accept Apache Karaf Minho in Apache Karaf.
>> 
>> The proposal is:
>> - create karaf-minho repository on github
>> - use github issues/actions for Minho
>> - rework the website to have all projects at the same level, Karaf
>> runtime becoming Karaf OSGi. Each project will have its own
>> subwebsite, like https://jbonofre.github.io/karaf5/.
>> 
>> In the meantime, I will change all resources to use
>> org.apache.karaf.minho namespace on my github before donation.
>> 
>> Please vote to approve this donation/change:
>> 
>> [ ] +1 Approve Minho donation and proposed plan
>> [ ] -1 Don't approve the donation/changes (please provide specific
>> comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Regards
>> JB
>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com


Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-09 Thread Serge Huber
Sounds good to me.

On Sun, Oct 9, 2022 at 7:50 AM Jean-Baptiste Onofré  wrote:

> That's correct.
>
> My proposal is really more for the website and "marketing".
>
> If you go there: https://karaf.apache.org/projects.html
>
> You can see we have:
> - Karaf runtime
> - Karaf cellar
> - Karaf cave
> - Karaf decanter
>
> So, basically, nothing change so much with my proposal. We would have:
> - Karaf OSGi runtime
> - Karaf Minho runtime
> - Karaf Cellar
> - Karaf Cave
> - Karaf Decanter
> - Karaf Winegrower
>
> Each subproject will have a dedicated subsite (with their own
> documentation, etc, ...).
>
> Regards
> JB
>
> On Sat, Oct 8, 2022 at 4:20 PM Steinar Bang  wrote:
> >
> > > Eric Lilja :
> >
> > > Because it's shedding its OSGi core, making it optional. It's a
> different
> > > product stack.
> >
> > What I meant: K5 is something different so call it something different,
> > but leave the karaf 4.x line with the name "karaf".
> >
> > (And in a different place in the thread it seems like this is the
> > current plan...?)
> >
>


Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Serge Huber
Karaf Nouveau (like Beaujolais :))  ?
Karaf Lafite or Screaming Eagle (
https://financesonline.com/top-10-most-expensive-red-wines-in-the-world-cabernet-sauvignon-tops-the-list/)
for the OSGi Karaf :)

cheers,
  Serge...

ps : I'm just throwing ideas at this point to see what sticks, I'm not
trying to force anything :)
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Fri, Oct 7, 2022 at 1:54 PM Francois Papon 
wrote:

> May be we can rename Karaf 4.x to Karaf OSGi as it's mainly focus on it.
>
>
> On 07/10/2022 13:52, Jean-Baptiste Onofré wrote:
> > The idea is to be clear and consistent across the project:
> >
> > Karaf xxx for current Karaf 4.x runtime
> > Karaf Minho
> > Karaf Winegrower
> > Karaf Cellar
> > Karaf Cave
> > Karaf Decanter
> >
> > Like in Apache Felix.
> >
> > Regards
> > JB
> >
> > On Fri, Oct 7, 2022 at 1:35 PM Francois Papon
> >  wrote:
> >> Hi,
> >>
> >> Ok for Apache Karaf Minho but please, don't rename Apache Karaf 4.x to
> >> Apache Karaf Classic :D
> >>
> >> regards,
> >>
> >> Francois
> >>
> >> On 07/10/2022 12:57, Jean-Baptiste Onofré wrote:
> >>> My preference is Apache Karaf Minho.
> >>>
> >>> What do you think to rename Karaf 4.5.0 with a different name too ? In
> >>> order to avoid any confusion: Apache Karaf is the umbrella project and
> we
> >>> will have only subprojects (like in Felix).
> >>>
> >>> Thoughts ?
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> Le jeu. 6 oct. 2022 à 20:12, Matt Pavlovich  a
> écrit :
> >>>
> >>>> +1 on bringing Karaf 5 into the Apache Karaf project.
> >>>>
> >>>> My $0.02 on naming is that perhaps the ‘5’ should drop off, since
> it’ll
> >>>> have its own version number and in case w/ need a Karaf Runtime v5.x
> to
> >>>> support all the OSGi + Jakarta + JDK changes coming.
> >>>>
> >>>> Regarding name ideas— I think short and simple is best!  Boot, Blend,
> etc.
> >>>>
> >>>> Perhaps whittle it down to 2 or 3 ideas?
> >>>>
> >>>> Thanks,
> >>>> Matt Pavlovich
> >>>>
> >>>>> On Oct 6, 2022, at 8:59 AM, Jean-Baptiste Onofré 
> >>>> wrote:
> >>>>> It sounds good too !
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On Thu, Oct 6, 2022 at 3:57 PM Jamie G. 
> >>>> wrote:
> >>>>>> Perhaps something like Apache Karaf Sustineri ?
> >>>>>>
> >>>>>> - The sustainably sourced modulith runtime
> >>>>>>
> >>>>>> On Thu, Oct 6, 2022 at 11:22 AM Serge Huber 
> wrote:
> >>>>>>> Thanks for the contribution JB.
> >>>>>>>
> >>>>>>> Personally I think we should maybe look into having a new name for
> it
> >>>> to
> >>>>>>> make it easy to distinguish from Karaf ?
> >>>>>>>
> >>>>>>> I'm especially worried if there ever is a Karaf 5 and K5 it's
> going to
> >>>>>>> become very confusing.
> >>>>>>>
> >>>>>>> I don't have great alternative solutions for the moment but maybe
> >>>> something
> >>>>>>> like Alembic, Cauldron, ...
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>Serge...
> >>>>>>>
> >>>>>>> On Thu, Oct 6, 2022 at 3:38 PM Francois Papon <
> >>>> francois.pa...@openobject.fr>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> May be yes, we should find a project name more not old Karaf
> related
> >>>> to
> >&

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Serge Huber
What about Karaf Zero for the new proposal ? :)

It's your fault François, you made me think of it. Worst part is that I
kind of like it :)

cheers,
  Serge...

On Fri, Oct 7, 2022 at 1:35 PM Francois Papon 
wrote:

> Hi,
>
> Ok for Apache Karaf Minho but please, don't rename Apache Karaf 4.x to
> Apache Karaf Classic :D
>
> regards,
>
> Francois
>
> On 07/10/2022 12:57, Jean-Baptiste Onofré wrote:
> > My preference is Apache Karaf Minho.
> >
> > What do you think to rename Karaf 4.5.0 with a different name too ? In
> > order to avoid any confusion: Apache Karaf is the umbrella project and we
> > will have only subprojects (like in Felix).
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > Le jeu. 6 oct. 2022 à 20:12, Matt Pavlovich  a
> écrit :
> >
> >> +1 on bringing Karaf 5 into the Apache Karaf project.
> >>
> >> My $0.02 on naming is that perhaps the ‘5’ should drop off, since it’ll
> >> have its own version number and in case w/ need a Karaf Runtime v5.x to
> >> support all the OSGi + Jakarta + JDK changes coming.
> >>
> >> Regarding name ideas— I think short and simple is best!  Boot, Blend,
> etc.
> >>
> >> Perhaps whittle it down to 2 or 3 ideas?
> >>
> >> Thanks,
> >> Matt Pavlovich
> >>
> >>> On Oct 6, 2022, at 8:59 AM, Jean-Baptiste Onofré 
> >> wrote:
> >>> It sounds good too !
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Thu, Oct 6, 2022 at 3:57 PM Jamie G. 
> >> wrote:
> >>>> Perhaps something like Apache Karaf Sustineri ?
> >>>>
> >>>> - The sustainably sourced modulith runtime
> >>>>
> >>>> On Thu, Oct 6, 2022 at 11:22 AM Serge Huber 
> wrote:
> >>>>> Thanks for the contribution JB.
> >>>>>
> >>>>> Personally I think we should maybe look into having a new name for it
> >> to
> >>>>> make it easy to distinguish from Karaf ?
> >>>>>
> >>>>> I'm especially worried if there ever is a Karaf 5 and K5 it's going
> to
> >>>>> become very confusing.
> >>>>>
> >>>>> I don't have great alternative solutions for the moment but maybe
> >> something
> >>>>> like Alembic, Cauldron, ...
> >>>>>
> >>>>> Regards,
> >>>>>   Serge...
> >>>>>
> >>>>> On Thu, Oct 6, 2022 at 3:38 PM Francois Papon <
> >> francois.pa...@openobject.fr>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> May be yes, we should find a project name more not old Karaf related
> >> to
> >>>>>> not lost the users.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> On 06/10/2022 15:25, Jean-Baptiste Onofré wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I don't use Karaf5, but K5 ;)
> >>>>>>>
> >>>>>>> And yes, the first release would be K5 1.0 (for instance, 1.1, 2.0,
> >>>>>>> 2.1, 2.2, 3.0, etc, etc).
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>> On Thu, Oct 6, 2022 at 3:12 PM Jamie G. 
> >>>>>> wrote:
> >>>>>>>> Agreed that proper naming and transition/migration guides will be
> >>>>>>>> necessary then to guide users.
> >>>>>>>>
> >>>>>>>> A question on the name "Karaf5" - what would its first release
> >> version
> >>>>>>>> be? 1.0.0? 5.0.0?
> >>>>>>>> It may be a little awkward to search Karaf5 2.0 or Karaf5 6.0. as
> it
> >>>>>>>> matures/evolves.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 6, 2022 at 10:10 AM Jean-Baptiste Onofré <
> >> j...@nanthrax.net>
> >>>>>> wrote:
> >>>>>>>>> Hi Jamie,
> >>>>>>>>>
> >>>>>>>>> Correct: we can imagine having the karaf-k4 module providing the
> >> same
> >>>>>>>>>

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Serge Huber
Thanks for the contribution JB.

Personally I think we should maybe look into having a new name for it to
make it easy to distinguish from Karaf ?

I'm especially worried if there ever is a Karaf 5 and K5 it's going to
become very confusing.

I don't have great alternative solutions for the moment but maybe something
like Alembic, Cauldron, ...

Regards,
  Serge...

On Thu, Oct 6, 2022 at 3:38 PM Francois Papon 
wrote:

> Hi,
>
> May be yes, we should find a project name more not old Karaf related to
> not lost the users.
>
> Regards,
>
> On 06/10/2022 15:25, Jean-Baptiste Onofré wrote:
> > Hi,
> >
> > I don't use Karaf5, but K5 ;)
> >
> > And yes, the first release would be K5 1.0 (for instance, 1.1, 2.0,
> > 2.1, 2.2, 3.0, etc, etc).
> >
> > Regards
> > JB
> >
> > On Thu, Oct 6, 2022 at 3:12 PM Jamie G. 
> wrote:
> >> Agreed that proper naming and transition/migration guides will be
> >> necessary then to guide users.
> >>
> >> A question on the name "Karaf5" - what would its first release version
> >> be? 1.0.0? 5.0.0?
> >> It may be a little awkward to search Karaf5 2.0 or Karaf5 6.0. as it
> >> matures/evolves.
> >>
> >> On Thu, Oct 6, 2022 at 10:10 AM Jean-Baptiste Onofré 
> wrote:
> >>> Hi Jamie,
> >>>
> >>> Correct: we can imagine having the karaf-k4 module providing the same
> >>> support as Karaf (4): OSGi, features service, etc.
> >>>
> >>> To be honest, that's not my intention (I don't want to have K4 and K5
> >>> coupled somehow together), but possible.
> >>>
> >>> IMHO, we will have Karaf users and K5 users, different usage.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Thu, Oct 6, 2022 at 2:21 PM Jamie G. 
> wrote:
>  To my understanding it doesn't prevent OSGi, it just does not require
>  it (very much in the spirit of Karaf letting you choose what you want
>  to run Equinox/Felix, Log4j/SLF4j, etc).
> 
>  In theory can an end user take their well formed application
>  (features) and directly deploy them into K5 without refactoring?
> 
>  I've worked on numerous projects which started at Karaf 2, and have
>  updated progressively to K3, K4. Does K5 represent a roadblock to
>  evolution?
> 
> 
>  On Thu, Oct 6, 2022 at 9:36 AM Łukasz Dywicki 
> wrote:
> > Hello,
> > Looking forward towards donation of it as a subproject with clear
> name.
> > Tehhnically speaking it is not Karaf 5 since it is not based on
> earlier principles. Dropping osgi is large change which will confuse
> existing users.
> > Hence following the ActiveMQ Artemis story we should be clear it is
> a new thing and has some things in common, but many more not inlined, with
> earlier release.
> >
> > Best,
> > Łukasz
> > --
> > Code-House
> > http://code-house.org
> >
> >> On 4 Oct 2022, at 18:35, Jean-Baptiste Onofré 
> wrote:
> >>
> >> Hi guys,
> >>
> >> As already discussed on the mailing list several times before, I
> think
> >> Karaf 5 (a.k.a K5) is now in a good first shape (usable).
> >>
> >> In a nutshell, K5 is a modulith runtime, able to launch and
> co-locate
> >> different kinds of modules/applications. It also provides a very
> >> simple services programming model.
> >>
> >> You can find documentation about K5 here:
> >>
> >> https://jbonofre.github.io/karaf5/
> >>
> >> NB: I will add the tools documentation asap.
> >>
> >> You can find the current source code here:
> >>
> >> https://github.com/jbonofre/karaf5
> >>
> >> NB: you can see the tests as kind of examples.
> >>
> >> Here's, basically my proposal I would discuss with you:
> >>
> >> 1. Create a dedicated repository for K5, something like
> >> http://github.com/apache/karaf-k5
> >> 2. For issue tracker and CI/CD, I propose to use GitHub resources
> >> (GitHub Issues and GitHub Actions). It's now an accepted and
> possible
> >> option from the Apache Software Foundation standpoint.
> >> 3. For the website, I think karaf.apache.org should be just a
> landing
> >> page containing all "generic" topics about Apache Karaf project
> >> (mailing list, legal, etc) and then directed to Karaf 4 or K5,
> having
> >> dedicated sub websites for each.
> >>
> >> Thoughts ?
> >>
> >> Thanks,
> >> Regards
> >> JB
>


Re: Board report for June '22

2022-06-01 Thread Serge Huber
+1

Looks good to me, just wondering if we should mention the excellent (and
hard) work done by the Pax Web project that is included in Karaf ?

cheers,
  Serge...


On Wed, Jun 1, 2022 at 10:13 AM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> I prepared Karaf board report for June '22:
>
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
> Can you please take a look and update if I missed something?
>
> I would like to send the report asap.
>
> Thanks,
> Regards
> JB
>


Re: [VOTE] Apache Karaf runtime 4.2.13 release

2021-12-16 Thread Serge Huber
Thanks a lot for doing this in branch 4.2 !

+1 (non-binding)

cheers,
  Serge...

On Thu, Dec 16, 2021 at 4:05 PM Jamie G.  wrote:

> +1
>
> Cheers,
> Jamie
>
> On Thu, Dec 16, 2021 at 10:33 AM Jean-Baptiste Onofré 
> wrote:
> >
> > Hi all,
> >
> > I submit Apache Karaf 4.2.13 to your vote.
> >
> > This version includes 8 fixes and improvements. Especially, it includes
> > Pax Logging 1.11.11 update, upgrading to log4j 2.16.0 fixing
> > CVE-2021-44228 and CVE-2021-45046.
> >
> > Please take a look on Release Notes for details.
> >
> > Release Notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350548
> >
> > Staging Maven Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1166/
> >
> > Staging Dist Repository:
> > https://dist.apache.org/repos/dist/dev/karaf/4.2.13/
> >
> > Git tag:
> > karaf-4.2.13
> >
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Regards
> > JB
> >
>


Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)

2021-12-15 Thread Serge Huber
Thanks for clarifying, +1 (non-binding) then !

cheers,
  Serge...

On Wed, Dec 15, 2021 at 3:22 PM Matt Pavlovich  wrote:

> +1 (non-binding)
>
> > On Dec 14, 2021, at 10:43 PM, JB Onofré  wrote:
> >
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.3.4 to your vote (take #3).
> >
> > This release includes dependency upgrades, fixes, and improvements,
> especially:
> >
> > - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing
> important security issue (CVE-2021-44228) and fixing JNDI issue
> > - align dependencies versions between Karaf and Pax *
> > - fix missing system export packages
> > - fix on Karaf features json support
> > - fix features autoRefresh configuration handling
> > - fix on sshd session handling
> > - update to sshd 2.8.0
> > - lot of pax * updates
> > - and much more !
> >
> > Please take a look on Release Notes for details !
> >
> > Release Notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> >
> > Staging Maven Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1165/
> >
> > Staging Dist Repository:
> > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> >
> > Git tag:
> > karaf-4.3.4
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Regards
> > JB
> >
>
>


Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)

2021-12-14 Thread Serge Huber
Given that log2j 2.15.0 has been found to have a Denial of service should
we re-release with 2.16.0 ?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Note that previous mitigations involving configuration such as to set the
system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this
specific vulnerability. Log4j 2.16.0 fixes this issue by removing support
for message lookup patterns and disabling JNDI functionality by default.
This issue can be mitigated in prior releases (<2.16.0) by removing the
JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class).

Regards,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Wed, Dec 15, 2021 at 7:28 AM Francois Papon 
wrote:

> +1 (binding)
>
> Thanks JB!
>
> regards,
>
> Francois
>
> On 15/12/2021 05:43, JB Onofré wrote:
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.3.4 to your vote (take #3).
> >
> > This release includes dependency upgrades, fixes, and improvements,
> especially:
> >
> > - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing
> important security issue (CVE-2021-44228) and fixing JNDI issue
> > - align dependencies versions between Karaf and Pax *
> > - fix missing system export packages
> > - fix on Karaf features json support
> > - fix features autoRefresh configuration handling
> > - fix on sshd session handling
> > - update to sshd 2.8.0
> > - lot of pax * updates
> > - and much more !
> >
> > Please take a look on Release Notes for details !
> >
> > Release Notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> >
> > Staging Maven Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1165/
> >
> > Staging Dist Repository:
> > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> >
> > Git tag:
> > karaf-4.3.4
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Regards
> > JB
> >
>


Re: [HEADS UP] Preparing Karaf runtime 4.3.3 release

2021-08-30 Thread Serge Huber
Thanks a lot guys ! Can't wait !

cheers,
  Serge...
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Tue, Aug 24, 2021 at 3:41 PM Grzegorz Grzybek 
wrote:

> Hello
>
> Thanks JBO!
>
> And traditional Pax Web 8 info - it's really close! I'm now working on
> Karaf integration tests and I'm surprised how I don't have to do anything
> to make existing tests work! What's more, I've ensured that all tests work
> fine on Jetty, Tomcat and Undertow (instead of only on Jetty).
> I've just added JAAS-related tests, so 3 kinds of external configuration
> work fine:
>
>  - ${karaf.etc}/jetty.xml:
>
> 
>   
> 
>   
> Test Realm
> karaf
> 
>   
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>   
> 
>   
> 
>   
> 
>
>  - ${karaf.etc}/tomcat-server.xml
>
>  catalinaBase="target/tomcat">
>   
> 
>appName="karaf"
>
> userClassNames="org.apache.karaf.jaas.boot.principal.UserPrincipal"
>
> roleClassNames="org.apache.karaf.jaas.boot.principal.RolePrincipal" />
> 
>   
> 
>
>  - ${karaf.etc}/undertow.xml
>
>  xmlns:w="urn:jboss:domain:17.0">
>   
> 
>   
> 
>
> org.apache.karaf.jaas.boot.principal.UserPrincipal
>
> org.apache.karaf.jaas.boot.principal.RolePrincipal
>   
> 
>
> I maintain a todo.txt file[1], where you can track my progress.
>
> kind regards
> Grzegorz Grzybek
> ===
> [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
>
> wt., 24 sie 2021 o 15:17 Jean-Baptiste Onofré 
> napisał(a):
>
>> Hi guys,
>>
>> just to let you know that I will create new PRs tonight, and if Jenkins
>> is happy, I will merge tomorrow.
>>
>> I will submit Karaf 4.3.3 to vote tomorrow night or Tuesday morning (my
>> time).
>>
>> Regards
>> JB
>>
>> On 16/08/2021 21:32, JB Onofré wrote:
>> > Hi everyone
>> >
>> > Just to let you know that I’m preparing Karaf 4.3.3 release. I should
>> be able to submit release to vote by the end of the week.
>> >
>> > I have identified required updates and fixes. I’m on it.
>> >
>> > I will keep you posted.
>> >
>> > Regards
>> > JB
>> >
>>
>


Re: State of Pax Web 8

2021-07-27 Thread Serge Huber
Thank you so much for all this work, I cannot tell you enough how much it
is appreciated!

I've programmed my share of web containers in the past and I know how
tricky this can be to get right.

Regards,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Tue, Jul 27, 2021 at 8:09 AM  wrote:

> This is very nice and thank you very much Grzegorz for all your great
> work on Pax Web!
>
> regards,
>
> François
> fpa...@apache.org
>
> Le 27/07/2021 à 08:00, Grzegorz Grzybek a écrit :
> > Hello
> >
> > I'd just like to let you know that everything is under control and I
> didn't
> > abandon the effort.
> >
> > I've added a todo.txt file[1] to Pax Web's main branch (I didn't create
> > separate GH issues for the tasks yet, as the scope may change, but at
> some
> > point I'll translate the remaining items to GH issues).
> >
> > So currently (and for some time already) I'm patiently making existing
> (Pax
> > Web 7) integration tests work with Pax Web 8.
> >
> > The remaining integration tests cover (~10 tests):
> >  - HttpContext processing[2] (that's beyond CMPN specifications)
> >  - Whiteboard websockets (beyond CMPN specifications)
> >  - DTO tests
> >  - JAX-RS tests
> >  - Jetty/Tomcat/Undertow bundles tests
> >  - Jetty Handlers/Connectors OSGi services
> >  - VirtualHosts
> >  - CRLs
> >  - Jasypt
> >
> > The already working (much faster due to better listeners!) tests include
> > (almost 200 per container runtime):
> >  - external jetty.xml/tomcat-server.xml/undertow.xml configuration
> >  - HttpService/WebContainer tests (CMPN chapter 102)
> >  - JSP tests (custom tags, directives, includes, ...)
> >  - WABs (including SCIs, WebSockets, scanning and fragments)
> >  - JSF
> >  - Vaadin (new!)
> >  - Whiteboard (much improved, including SCR and standard services)
> >
> > The most important aspects of chapters 102 (Http Service), 128 (Web
> > Applications) and 140 (Whiteboard) are implemented including the most
> > important one - 1:N mapping between web elements and _contexts_.
> >
> > The other most important aspect, not related to CMPN specifications is
> the
> > consistency of behavior between Jetty, Tomcat and Undertow containers -
> > only ONE integration test has container specific behavior - the test
> > checking HTTP response when POST size (container-specific configuration)
> is
> > exceeded.
> >
> > I roughly plan to release Pax Web 8 around mid of September.
> >
> > kind regards
> > Grzegorz Grzybek
> > ===
> > [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
> > [2]:
> >
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing
> >
>


Re: [VOTE] Apache Karaf runtime 4.3.2 release

2021-05-10 Thread Serge Huber
+1 (non-binding)

cheers,
  Serge...

On Mon, May 10, 2021 at 3:13 PM Roedl Lukas  wrote:

> +1 (non-binding)
>
> regards,
> Lukas
>
> -Ursprüngliche Nachricht-
> Von: Jean-Baptiste Onofre 
> Gesendet: Sonntag, 9. Mai 2021 07:19
> An: dev@karaf.apache.org
> Betreff: [VOTE] Apache Karaf runtime 4.3.2 release
>
> Hi everyone,
>
> I submit Apache Karaf runtime 4.3.2 to your vote.
>
> This release includes bunch of dependency upgrades, fixes, and
> improvements, especially:
>
> - upgrade to xbean 4.19 fixing JDK9 style war file
> - improvements on scheduler to support array configuration
> - fix on the JSON configuration to support array
> - improvement on JSON configuration to support R7 factory style
> - fix on the default pax-logging layout pattern
> - fix on the JMX RMI to use the configured host
> - fix race condition on SSHd startup
> - improvement on ShellTable
> - bunch of dependency updates for fixes and CVE
> - and much more !
>
> *NOTE: for security reason, the default karaf user is commented in
> etc/users.properties file. Please uncomment and change password if you want
> to use it (for remote access like ssh, jmx, …).*
>
> Please take a look on Release Notes for details !
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
> >
>
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/ <
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/>
>
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.2/ <
> https://dist.apache.org/repos/dist/dev/karaf/4.3.2/>
>
> Git tag:
> karaf-4.3.2
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Regards
> JB
>


Re: Apache Karaf 4.3.2 very soon

2021-05-03 Thread Serge Huber
I get that.

Ok so where is this release then ? :)

Just kidding !

Cheers,
  Serge

Le ven. 30 avr. 2021 à 17:35, Jean-Baptiste Onofre  a
écrit :

> Thanks guys for your kind words.
>
> I *need* to work on Karaf and Apache projects ;) So, I’m almost back in
> the business and targeting weekend ;)
>
> Thanks again !
>
> Regards
> JB
>
> > Le 30 avr. 2021 à 17:12, Steinar Bang  a écrit :
> >
> >>>>>> Serge Huber :
> >
> >> Hi JB,
> >> Please pace yourself man, we can wait a little !
> >
> > Agreed!
> >
>
>


Re: Apache Karaf 4.3.2 very soon

2021-04-29 Thread Serge Huber
Hi JB,

Please pace yourself man, we can wait a little !

Regards,
  Serge...

On Thu, Apr 29, 2021 at 7:44 AM Jean-Baptiste Onofre 
wrote:

> Hi guys,
>
> Even if the week is very rough for me, I will move forward with 4.3.2. I
> hope to submit the release to vote during the week end.
>
> Regards
> JB
>
> > Le 11 avr. 2021 à 07:48, Jean-Baptiste Onofre  a écrit
> :
> >
> > Hi,
> >
> > I will move forward quickly on Karaf 4.3.2 due to the following issue
> detected:
> >
> > - Upgrade xbean to 4.19 for better support on war artifacts
> > - Upgrade Pax Web for new Jetty version and xbean
> > - Fix/improvement on the JSON configuration
> > - Upgrade pax logging and other dependency projects to use
> maven-bundle-plugin 5.1.2, fixing the headers
> >
> > I hope to submit 4.3.2 to vote mid week.
> >
> > I will keep you posted.
> >
> > Regards
> > JB
>
>


Re: [VOTE] Apache Karaf runtime 4.3.1 release

2021-03-30 Thread Serge Huber
+1 (non-binding)

cheers,
  Serge.

On Tue, Mar 30, 2021 at 6:45 PM Jamie G.  wrote:

> +1
>
> Cheers,
> Jamie
>
> On Tue, Mar 30, 2021 at 2:14 PM Jean-Baptiste Onofre 
> wrote:
> >
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > > Le 29 mars 2021 à 15:14, Jean-Baptiste Onofre  a
> écrit :
> > >
> > > Hi everyone,
> > >
> > > I submit Apache Karaf runtime 4.3.1 to your vote.
> > >
> > > This release includes bunch of dependency upgrades, fixes, and
> improvements, especially:
> > >
> > > - java.* now exported by system packages (as expected since R7)
> > > - fixed on configuration with json format
> > > - jetty alias feature for backward compatibility
> > > - resolver parallelism default value fixed (to run on Kubernetes by
> default)
> > > - fix on SSH, log commands
> > > - improvement on the JMX layer (especially JMXMP)
> > > - env/prop interpolation support on the SSH client
> > > - add property to disable auto refresh in features service
> > > - and much more !
> > >
> > > Please take a look on Release Notes for details !
> > >
> > > Release Notes:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
> >
> > >
> > > Staging Repository:
> > >
> https://repository.apache.org/content/repositories/orgapachekaraf-1155/ <
> https://repository.apache.org/content/repositories/orgapachekaraf-1155/>
> > >
> > > Staging Dist:
> > > https://dist.apache.org/repos/dist/dev/karaf/4.3.1/ <
> https://dist.apache.org/repos/dist/dev/karaf/4.3.1/>
> > >
> > > Git tag:
> > > karaf-4.3.1
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > Regards
> > > JB
> >
>


Re: Thinking about Karaf 5 modulith runtime

2020-11-05 Thread Serge Huber
On Thu, Nov 5, 2020 at 5:50 AM Jean-Baptiste Onofre  wrote:

>
> Regarding the "front side", yes, it makes sense. You did it, other
> Karaf/OSGi users made something similar as well. It could be a Karaf
> feature obviously.
>

That is exactly my point: people should not be re-doing stuff over Karaf :)
If they want to do their own that's fine but it would be great to provide
something optional that goes a long way to provide the basic infrastructure
for modern and pluggable UI building.

cheers,
  Serge...


>
> I will write down the points on wiki about this discussion.
>
> Thanks guys, that’s great feedback and help to define the roadmap to Karaf
> 5.
>
> Regards
> JB
>
> > Le 4 nov. 2020 à 23:07, Serge Huber  a écrit :
> >
> > Interesting discussion going on here.
> >
> > Personally from an architectural point of view I really like what OSGi
> > brings to the table in terms of dev discipline, but its true that when
> > integrating with libraries that were not designed for OSGi (most of them
> > were not) it can quickly become problematic. So I'm not sure what could
> be
> > done in terms of tooling but at my company we have developed some Maven
> > plugins that go quite far with dependency calculation and packaging,
> maybe
> > something like that could help if we keep the OSGi runtime (which I
> believe
> > we should).
> >
> > Provisioning also needs improvements, because right now we are looking at
> > container-packaged Karaf runtimes that need to be properly managed in
> terms
> > of upgrading, etc. Having simpler ways (with minimal Maven work) of
> > packaging Karaf distributions would be really good here. Some work has
> > already been done here but I think we could probably go further to make
> it
> > simpler (looking at Spring Boot or Docker-like syntaxes for example).
> >
> > It would also be great to have ready-to-use configurations for build REST
> > APIs, GraphQL APIs, and possibly even UIs. At my company we've been
> working
> > on frameworks to be able to aggregate Javascript components on the server
> > side that then would be automatically merged on an HTML page. Making it
> > possible to simply deploy a new bundle with embedded Javascript
> components
> > that could extend the UI. Having this as a basic framework would help
> > building powerful and flexible front-ends in a more guided way, hopefully
> > improving dev productivity. I'd be more than willing to share my
> experience
> > here.
> >
> > These are just the first things that come to my mind, I hope they'll
> help.
> >
> > Regards,
> >  Serge...
> >
> > On Wed, Nov 4, 2020 at 10:06 PM Robert Varga  wrote:
> >
> >> On 04/11/2020 20:29, Steinar Bang wrote:
> >>>>>>>> Jean-Baptiste Onofre :
> >>>> My thinking now is more to still use OSGi internally (and let people
> >>>> do OSGi on Karaf if they want) but open the scope to other
> >>>> framework/approach (spring boot, micro profile, etc). We would embrace
> >>>> a wider community and expend our use cases.
> >>> FWIW what drew me to karaf was to finally see OSGi deliver on its
> >>> promise.
> >>>
> >>> OSGi that actually worked like people said it was *supposed* to work,
> >>> back in the mid-late 00s...
> >>>
> >>> I would hate to see that go.
> >>>
> >>> (Spring boot is not a priority for me.  I try to run quickly the other
> >>> way when someone mentions Spring or Spring boot...:-) )
> >>
> >> Same sentiment here in general, but with a very libertarian twist :)
> >>
> >> With my various OpenDaylight hats on, let me summarize our project-wide
> >> view, with history going back to the project was officially announced
> >> (early 2013).
> >>
> >> From the get go, our *architectural* requirement was OSGi compatibility,
> >> i.e. every single production (not maven-plugin obviously) artifact has
> >> to be a proper bundle. This, highly technical and
> >> implementation-specific, requirement was set down because of two things:
> >>
> >> 1) what OSGi brings to MANIFEST.MF in terms of headers and intended
> >> wiring, incl. Private-Package
> >>
> >> 2) typical OSGi implementation (we inherited Equinox and are still using
> >> it) uses multiple class loaders and utterly breaks on split packages
> >>
> >> This serves as an architectural requirement that translates to an
> >> unbreakable design req

Re: [RESULT][VOTE] Apache Winegrower 1.0.0 release

2020-11-05 Thread Serge Huber
This is great news ! Thanks JB !

cheers,
  Serge...
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Thu, Nov 5, 2020 at 1:57 PM Jean-Baptiste Onofre  wrote:

> Hi everyone,
>
> This vote passed with the following result:
>
> +1 (binding): François Papon, JB Onofré, Jamie Goodyear
> +1 (non binding): Romain Manni-Bucau, Serge Huber
>
> I’m preparing the subproject page on the website, publish the artifacts on
> Maven Central and dist and update Jira.
> As said, a blog introducing Winegrower is on the way.
>
> Thanks all for your vote !
>
> Regards
> JB
>
> > Le 4 nov. 2020 à 09:25, Jamie G.  a écrit :
> >
> > +1
> >
> > Cheers,
> > Jamie
> >
> > On Wed, Nov 4, 2020 at 1:31 AM Jean-Baptiste Onofre 
> wrote:
> >
> >> Gently reminder: we would need an additional binding vote here.
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
> >>> Le 30 oct. 2020 à 08:00, Jean-Baptiste Onofre  a
> écrit
> >> :
> >>>
> >>> Hi everyone,
> >>>
> >>> I submit Winegrower 1.0.0 to your vote. This is the first Winegrower
> >> release, bootstrapping the project.
> >>>
> >>> We know that some works have to be done on the documentation and
> example
> >> fronts, but this release is fully usable and provide a concrete
> alternative
> >> to existing framework.
> >>> As for Karaf 4.3.0, I’m preparing a blog post about Winegrower.
> >>>
> >>> Staging Repository:
> >>>
> https://repository.apache.org/content/repositories/orgapachekaraf-1150/
> >> <
> https://repository.apache.org/content/repositories/orgapachekaraf-1150/>
> >>>
> >>> Staging Dist:
> >>> https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/ <
> >> https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/>
> >>>
> >>> Please vote to approve this release:
> >>>
> >>> [ ] +1 Approve the release
> >>> [ ] -1 Don't approve the release (please provide specific comments)
> >>>
> >>> This vote will be open for at least 72 hours.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>
> >>
>
>


Re: Thinking about Karaf 5 modulith runtime

2020-11-04 Thread Serge Huber
Interesting discussion going on here.

Personally from an architectural point of view I really like what OSGi
brings to the table in terms of dev discipline, but its true that when
integrating with libraries that were not designed for OSGi (most of them
were not) it can quickly become problematic. So I'm not sure what could be
done in terms of tooling but at my company we have developed some Maven
plugins that go quite far with dependency calculation and packaging, maybe
something like that could help if we keep the OSGi runtime (which I believe
we should).

Provisioning also needs improvements, because right now we are looking at
container-packaged Karaf runtimes that need to be properly managed in terms
of upgrading, etc. Having simpler ways (with minimal Maven work) of
packaging Karaf distributions would be really good here. Some work has
already been done here but I think we could probably go further to make it
simpler (looking at Spring Boot or Docker-like syntaxes for example).

It would also be great to have ready-to-use configurations for build REST
APIs, GraphQL APIs, and possibly even UIs. At my company we've been working
on frameworks to be able to aggregate Javascript components on the server
side that then would be automatically merged on an HTML page. Making it
possible to simply deploy a new bundle with embedded Javascript components
that could extend the UI. Having this as a basic framework would help
building powerful and flexible front-ends in a more guided way, hopefully
improving dev productivity. I'd be more than willing to share my experience
here.

These are just the first things that come to my mind, I hope they'll help.

Regards,
  Serge...

On Wed, Nov 4, 2020 at 10:06 PM Robert Varga  wrote:

> On 04/11/2020 20:29, Steinar Bang wrote:
> >> Jean-Baptiste Onofre :
> >> My thinking now is more to still use OSGi internally (and let people
> >> do OSGi on Karaf if they want) but open the scope to other
> >> framework/approach (spring boot, micro profile, etc). We would embrace
> >> a wider community and expend our use cases.
> > FWIW what drew me to karaf was to finally see OSGi deliver on its
> > promise.
> >
> > OSGi that actually worked like people said it was *supposed* to work,
> > back in the mid-late 00s...
> >
> > I would hate to see that go.
> >
> > (Spring boot is not a priority for me.  I try to run quickly the other
> > way when someone mentions Spring or Spring boot...:-) )
>
> Same sentiment here in general, but with a very libertarian twist :)
>
> With my various OpenDaylight hats on, let me summarize our project-wide
> view, with history going back to the project was officially announced
> (early 2013).
>
> From the get go, our *architectural* requirement was OSGi compatibility,
> i.e. every single production (not maven-plugin obviously) artifact has
> to be a proper bundle. This, highly technical and
> implementation-specific, requirement was set down because of two things:
>
> 1) what OSGi brings to MANIFEST.MF in terms of headers and intended
> wiring, incl. Private-Package
>
> 2) typical OSGi implementation (we inherited Equinox and are still using
> it) uses multiple class loaders and utterly breaks on split packages
>
> This serves as an architectural requirement that translates to an
> unbreakable design requirement how the code must be structured.
>
> We started up with home-brew OSGi container, which we quickly replaced
> for karaf-3.0.x (6?), massively enjoying it being properly integrated,
> with shell, management and all that. Also feature:install.
>
> At the end of day, though, OpenDaylight is a toolkit of a bunch of
> components which you throw together and they work.
>
> Our initial thinking was far removed from the current world of
> containers when operations goes. The deployment was envisioned more like
> an NMS with a dedicated admin team (to paint a picture), providing a
> flexible platform.
>
> The world has changed a lot, and the focus nowadays is containers
> providing a single, hard-wired use-case.
>
> We now provide out-of-the-box use-case wiring using both dynamic Karaf
> and Guice (at least for one use case). We have an external project which
> shows the same can be done with pure Java, Spring Boot and Quarkus.
>
> We now also require Java 11, hence we have JPMS -- and it can fulfill
> our architectural requirement just as well as OSGi and, thanks to OSGi,
> we have zero split packages :)
>
> We do not expect to ditch Karaf anytime soon, but rather leverage
> static-framework for a light-weight OSGi environment, as that is clearly
> the best option for us short-to-medium term, and definitely something we
> will continue supporting for the foreseeable future.
>
> The shift to nimble single-purpose wirings is not going away and hence
> we will be expanding there anyway.
>
> To achieve that, we will not be looking for a framework-of-frameworks,
> we will do that through native integration ourselves.
>
> If Karaf can do the same, i.e. have 

Re: [VOTE] Apache Winegrower 1.0.0 release

2020-10-30 Thread Serge Huber
+1 (non-binding)

Great to see the first release !

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Fri, Oct 30, 2020 at 9:09 AM Romain Manni-Bucau 
wrote:

> +1, thanks a lot!
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 30 oct. 2020 à 09:08, Francois Papon  >
> a écrit :
>
> > +1 (binding)
> >
> > regards,
> >
> > François
> > fpa...@apache.org
> >
> > Le 30/10/2020 à 08:00, Jean-Baptiste Onofre a écrit :
> > > Hi everyone,
> > >
> > > I submit Winegrower 1.0.0 to your vote. This is the first Winegrower
> > release, bootstrapping the project.
> > >
> > > We know that some works have to be done on the documentation and
> example
> > fronts, but this release is fully usable and provide a concrete
> alternative
> > to existing framework.
> > > As for Karaf 4.3.0, I’m preparing a blog post about Winegrower.
> > >
> > > Staging Repository:
> > >
> https://repository.apache.org/content/repositories/orgapachekaraf-1150/
> > <https://repository.apache.org/content/repositories/orgapachekaraf-1150/
> >
> > >
> > > Staging Dist:
> > > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/ <
> > https://dist.apache.org/repos/dist/dev/karaf/winegrower/1.0.0/>
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > Regards
> > > JB
> > >
> > >
> >
>


Re: Apache Karaf runtime 4.3.0 - Decision taken

2020-09-04 Thread Serge Huber
Hi JB,

Yeah I know the feeling of not liking to wait for releases :)

Could you give an example of the missing 10%?

Anyway I think it makes sense and anyway maybe we should start working on
R8 & Karaf 5 ? :)

So here's a non-binding +1.

cheers,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Fri, Sep 4, 2020 at 5:46 PM Jean-Baptiste Onofre  wrote:

> Hi guys,
>
> I have to take my duty as Karaf PMC ;)
>
> Clearly Karaf 4.3.0 is waiting for way too long: 4.3.0-SNAPSHOT started on
> Feb 11, 2019 !
>
> I discussed with Greg earlier today, and we still have work to do for Pax
> Web 8.0.
>
> As I don’t want to hold Karaf 4.3.0 any longer, I took the decision to
> move forward and upgrade Karaf 4.3.0 to Pax Web 7.3.x.
> If Pax Web 7.3.x doesn’t fully cover R7, it covers 90% of the spec, and
> I’m pretty sure most of the users don’t use the pending 10%.
>
> So, here’s my proposal:
> - I’m working on Pax Web 7.3.9 preparation during the week end (updating
> container, etc)
> - In the meantime, I’m preparing Karaf 4.3.0 with a cleanup of the
> features and easy choice between Pax Web and Felix HTTP for the HTTP service
> - In also reviewing the Jira to include the maximum I can in 4.3.0.
>
> Reasonably, I think I will submit Karaf runtime 4.3.0 to vote next week
> (strong commitment).
>
> If you have any concern or comment about this plan, please let me know.
>
> Thanks !
>
> Regards
> JB


Re: [INFO] JDK13 & JDK14 support

2020-08-17 Thread Serge Huber
Thanks JB that's great news. Does this mean it can go all the way from 8 to
14 ?

Regards,
  Serge...

On Mon, Aug 17, 2020 at 3:21 PM Jean-Baptiste Onofre 
wrote:

> Hi guys,
>
> Following previous messages on the mailing list, I created a PullRequest
> adding JDK13 & JDK14 support at runtime:
>
> https://github.com/apache/karaf/pull/1155
>
> I will merge, cherry picked on karaf-4.2.x branch. It will be included in
> next release (4.2.10).
>
> Regards
> JB
>


Re: [VOTE] Apache Karaf Cellar 4.2.1 release

2020-08-17 Thread Serge Huber
+1 (non-binding)

On Mon, Aug 17, 2020 at 9:59 AM Jean-Baptiste Onofre 
wrote:

> Hi everyone,
>
> I submit Apache Karaf Cellar 4.2.1 to your vote.
>
> This release is a maintenance release on the Cellar 4.2.x series,
> including important fixes especially:
> - Fix startup of the feature synchronizer with JDK 1.8
> - Fix hazelcast group manager startup
> - Fix a race condition between ConfigAdmin and group manager
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348569
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348569
> >
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1146/ <
> https://repository.apache.org/content/repositories/orgapachekaraf-1146/>
>
> Staging dist:
> https://dist.apache.org/repos/dist/dev/karaf/cellar/4.2.1/ <
> https://dist.apache.org/repos/dist/dev/karaf/cellar/4.2.1/>
>
> Git tag:
> cellar-4.2.1
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB


Re: [PROPOSAL] Renaming terms

2020-07-27 Thread Serge Huber
wow I didn't think of the git branch name !

But default seems to make more sense than main to me.

Regards,
  Serge...

On Mon, Jul 27, 2020 at 4:08 PM Jean-Baptiste Onofre 
wrote:

> We can rename the branch anyway.
>
> I guess they gonna change the "default" soon.
>
> Regards
> JB
>
> > Le 27 juil. 2020 à 16:06, Grzegorz Grzybek  a
> écrit :
> >
> > Isn't "master" hardcoded in `git` binary - when you create an empty git
> > repo?
> >
> > $ cd /data/tmp/
> > $ mkdir x
> > $ cd x
> > $ git init
> > Initialized empty Git repository in /data/tmp/x/.git/
> > $ git branch -vv
> > $ git commit --allow-empty -m 'Initial commit'
> > [master (root-commit) f402a8e] Initial commit
> > $ git branch -vv
> > * master f402a8e Initial commit
> >
> > regards
> > Grzegorz Grzybek
> >
> > pon., 27 lip 2020 o 15:21 Jean-Baptiste Onofre 
> napisał(a):
> >
> >> It sounds good, main is fine.
> >>
> >> I will do the rename and update documentation/website.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 27 juil. 2020 à 14:55, Francois Papon  >
> >> a écrit :
> >>>
> >>> May be we could use the new github default branch name "main".
> >>>
> >>> regards,
> >>>
> >>> François
> >>> fpa...@apache.org
> >>>
> >>> Le 27/07/2020 à 14:52, Jean-Baptiste Onofre a écrit :
>  Yes, I forgot to mention this. I was about to propose develop branch
> >> instead of master branch.
> 
>  Regards
>  JB
> 
> > Le 27 juil. 2020 à 14:37, Francois Papon <
> francois.pa...@openobject.fr>
> >> a écrit :
> >
> > Should we also rename "master" branch on git?
> >
> > regards,
> >
> > François
> > fpa...@apache.org
> >
> > Le 27/07/2020 à 13:57, Achim Nierbeck a écrit :
> >> +1
> >>
> >> and wherever it fits best.
> >> Make sure the documentation is aligned, and maybe we could give
> hints
> >> in
> >> the current documentation already?
> >>
> >> regards, Achim
> >>
> >>
> >> Am Mo., 27. Juli 2020 um 09:37 Uhr schrieb Fabian Lange <
> >> lange.fab...@gmail.com>:
> >>
> >>> +1
> >>>
> >>> as a user of karaf 4.2 building our own distribution, we would be
> >> okay with
> >>> this being even in 4.2.x
> >>> Even when not backwards compatible
> >>>
> >>> Fabian
> >>>
> >>> On Mon, Jul 27, 2020 at 8:22 AM Jean-Baptiste Onofre <
> >> j...@nanthrax.net>
> >>> wrote:
> >>>
>  Hi guys,
> 
>  I would like to propose new wording in some Karaf designs:
> 
>  - In Karaf runtime, I would like to rename master/slave to
>  primary/secondary
>  - in Cellar, I would like to rename blacklist/whitelist to
> >> allowlist and
>  deny list
> 
>  Thoughts ?
> 
>  Regards
>  JB
> >>
> >>
>
>


Re: [PROPOSAL] Renaming terms

2020-07-27 Thread Serge Huber
+1, I've also been looking at this for Apache Unomi.

Will you do this in minor or major updates?

Regards,
  Serge...


On Mon, Jul 27, 2020 at 8:21 AM Jean-Baptiste Onofre 
wrote:

> Hi guys,
>
> I would like to propose new wording in some Karaf designs:
>
> - In Karaf runtime, I would like to rename master/slave to
> primary/secondary
> - in Cellar, I would like to rename blacklist/whitelist to allowlist and
> deny list
>
> Thoughts ?
>
> Regards
> JB


Re: JB - Delay in answer/fixes for the next three weeks

2020-07-13 Thread Serge Huber
Hi JB,

I'm sure all can understand. I'll try to help by not asking any questions
and hopefully helping others if I can.

Take care,
cheers,
  Serge...

On Mon, Jul 13, 2020 at 7:17 AM Jean-Baptiste Onofre 
wrote:

> Hi guys,
>
> Due to personal issue, I have to take some days off in the coming three
> weeks. I will be mostly online and will work on Karaf features and issues
> during the period, but expect some delay.
> I’m very sorry about that.
>
> Regards
> JB


Re: [HEADS UP] Apache Karaf releases plan

2020-07-07 Thread Serge Huber
Thanks JB.

Do you have any material about the changes in Cellar? As we use it in
several projects (Jahia,Unomi) I'd love to know more :)

cheers,
  Serge...
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Mon, Jul 6, 2020 at 1:03 PM Francois Papon 
wrote:

> Sounds good.
>
> Thanks JB for the update!
>
> regards,
>
> François
> fpa...@apache.org
>
> Le 06/07/2020 à 09:41, Jean-Baptiste Onofre a écrit :
> > Hi guys,
> >
> > Just a quick update about coming Karaf releases:
> >
> > 1. Winegrower 1.0.0
> > I moved forward on new cepages and examples in Winegrower. I will open
> the PRs today and I will move forward on release tomorrow or Wednesday.
> >
> > 2. Karaf Cellar 4.2.0 and 4.3.0
> > I did bunch of fixes in Karaf Cellar 4.2.0. Cellar 4.2.x architecture
> and design is as Cellar 4.1.x but with dependency updates and fixes.
> > On the other hand, I started a deep refactoring of Cellar for 4.3.x
> release with better design. I plan to release a first RC during summer. I
> will share some details quickly.
> >
> > 3. Karaf runtime releases
> > With new features coming (Spring Boot support, DevX, Features JSON,
> etc, etc), we set of runtime releases is planned.
> > I will do a separate email about Karaf runtime plan with details (by the
> end of this week).
> >
> > Stay tuned !
> >
> > Regards
> > JB
>


Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

2020-07-07 Thread Serge Huber
Hi guys,

Interesting discussion. I'd love to see Karaf 4.3 asap.

As (mostly) a user of Pax Web, I'm wondering if just focusing on Jetty
instead of supporting both Jetty & Tomcat could make things faster and
maybe easier to integration test? I'm sure there are use cases for Tomcat
that I'm not aware of but I'm wondering what they are?

As a Karaf user, my biggest need is for a "global" interception mechanism
on the HTTP service to be able to build filters for security, CSRF, etc...
which are things that Pax Web doesn't support right now.

Regards,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Tue, Jul 7, 2020 at 12:23 PM Grzegorz Grzybek 
wrote:

> Hello
>
> The problem with Pax-Web 8 and R7 compatibility is mostly related to ...
> Pax-Web 7 (and 6) not being R6 compatible at all...
>
> Indeed - the refactoring was very ambitious - 1st, I didn't want to get rid
> of all the huge work and design of Pax Web, 2nd, I though it'll be
> comparable to my previous Pax Logging refactoring (where among others I've
> increased number of real integration tests from 0 to 100+).
>
> I'm working now on "resource and welcome file handling" - and while
> "welcome files" are not covered at all in Whiteboard/HttpService specs, Pax
> Web is known to support them - so not having them would be a regression.
>
> I hope to have working resources/welcome files implementation this week -
> just check the related test size to see what I'm talking about:
>
> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-jetty/src/test/java/org/ops4j/pax/web/service/jetty/internal/UnifiedJettyTest.java#L360-L663
> (with similar tests for Tomcat and Undertow).
>
> After resources/welcome-files, the big remaining thing is
> pax-web-extender-war, however the refactoring will be minimal, because the
> biggest changes were related to model (pax-web-spi), pax-web-runtime and
> whiteboard trackers.
>
> For now, master-improvements branch is in a state where chance for merge
> conflict is minimal (for some time initially I did really huge changes,
> removals and moves of the files/packages).
>
> Also, the most important integration tests are now in the process of moving
> (in other words - those that are moved, work).
>
> During my work I have also created some serious issues like:
>  - https://github.com/eclipse-ee4j/servlet-api/issues/300
>  - https://github.com/eclipse/jetty.project/pull/5025
>
> I'm aware that R8 is coming, but when we have working R7 implementation (or
> rather R6 implementation in the first place), it'd be a matter of ~2 weeks
> to implement R8 on top of working R7.
>
> So, thanks for patience, sorry for delay and please help if you like ;)
>
> regards
> Grzegorz Grzybek
>
> wt., 7 lip 2020 o 11:27 Jean-Baptiste Onofre  napisał(a):
>
> > Hi,
> >
> > See my comment inline
> >
> > > Le 7 juil. 2020 à 11:22, Romain Manni-Bucau  a
> > écrit :
> > >
> > > Hi JB,
> > >
> > > I see more issues using felix http:
> > >
> > > 1. it only supports felix today AFAIK which directly impacts the
> > production
> > > since then your monitoring/observability/instrumentation can be to redo
> > so
> > > for me it is way more impacting than the dev side - and more vicious
> >
> > Good point, we can have impact with Equinox, true.
> >
> > > 2. felix is a fatjar so you can't upgrade jetty when needed which is
> > also a
> > > big loss compared to not having R7 IMHO
> >
> > That’s a discussion standpoint. Having a fat jar can be seen as a good
> > point as upgrading Jetty (or Tomcat, or undertow) is not always (never
> ;))
> > "smooth" at Pax Web.
> >
> > >
> > > How far is paxweb from R7? Not being 100% compliant is fine IMO while:
> > > a. it can be manually switched to a compliant impl if required
> > > b. there is no regression from previous version
> > >
> >
> > I think we are pretty close just for R7, but we also started a large
> > refactoring (maybe it was too "ambitious").
> > So, another approach would by to start from Pax Web 7.2.x and just update
> > the minimal set to R7 (new HTTP service).
> &

Re: [VOTE] Apache Karaf runtime 4.2.9 (take #2)

2020-06-08 Thread Serge Huber
+1 (non-binding)

Thanks JB,
Regards,
  Serge...
Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.


On Mon, Jun 8, 2020 at 6:44 AM Jean-Baptiste Onofre  wrote:

> +1 (binding)
>
> Regards
> JB
>
> > Le 5 juin 2020 à 14:48, Jean-Baptiste Onofre  a écrit :
> >
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.2.9 release to your vote (take #2 where
> we fixed the ASM update).
> >
> > This is a maintenance release on the 4.2.x series bringing fixes,
> updates and improvements.
> > It especially fixes the issues related to the shell (paste didn’t work
> properly, some commands caused exception, …).
> >
> > Release Notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
> >
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1143/
> <https://repository.apache.org/content/repositories/orgapachekaraf-1143/>
> >
> > Staging Dist:
> > https://dist.apache.org/repos/dist/dev/karaf/4.2.9/ <
> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/>
> >
> > Git Tag:
> > karaf-4.2.9
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
>
>


Re: [VOTE] Apache Karaf 4.2.9 release

2020-06-04 Thread Serge Huber
Thanks JB for all the work and keeping us updated!

cheers,
  Serge...

On Thu, Jun 4, 2020 at 1:46 PM Jean-Baptiste Onofre  wrote:

> Hi guys,
>
> Just a quick update about Karaf 4.2.9 release. I fixed the issue about
> Aries Proxy and ASM, I also fixed the issue about Hibernate (it was not
> actually update for a while, the bundles didn’t match the feature version).
> I’m working on the latest issue before moving forward on the release vote.
> I will send the vote early tomorrow.
>
> Regards
> JB
>
> > Le 20 mai 2020 à 06:43, Jean-Baptiste Onofre  a écrit :
> >
> > I confirm that it’s potentially an issue depending the usage of
> Aries-proxy.
> >
> > I’m upgrading Aries Proxy and release it and I will update in Karaf.
> >
> > Let me cancel this vote and cut a new one with the updated Aries Proxy
> version.
> >
> > Thanks for spotting that.
> >
> > Regards
> > JB
> >
> >> Le 19 mai 2020 à 20:57, Benjamin Graf  a écrit :
> >>
> >> -1
> >>
> >> Update to ASM 8 has negativ impact to aries-proxy
> >>
> >>
> org.objectweb.asm;resolution:=optional;version="[5,8)",org.objectweb.asm.commons;resolution:=optional;version="[5,8)"
> >>
> >> On 19.05.2020 18:39, Jean-Baptiste Onofre wrote:
> >>> Hi everyone,
> >>>
> >>> I submit Apache Karaf runtime 4.2.9 release to your vote.
> >>>
> >>> This is a maintenance release on the 4.2.x series bringing fixes,
> updates and improvements.
> >>> It especially fixes the issues related to the shell (paste didn’t work
> properly, some commands caused exception, …).
> >>>
> >>> Release Notes:
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
> <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
> >
> >>>
> >>> Staging Repository:
> >>>
> https://repository.apache.org/content/repositories/orgapachekaraf-1142/ <
> https://repository.apache.org/content/repositories/orgapachekaraf-1142/>
> >>>
> >>> Staging Dist:
> >>> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/ <
> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/>
> >>>
> >>> Git Tag:
> >>> karaf-4.2.9
> >>>
> >>> Please vote to approve this release:
> >>>
> >>> [ ] +1 Approve the release
> >>> [ ] -1 Don't approve the release (please provide specific comments)
> >>>
> >>> This vote will be open for at least 72 hours.
> >>>
> >>> Thanks,
> >>> Regards
> >>> JB
> >>
> >
>
>


Re: Board Report for June '20

2020-06-02 Thread Serge Huber
+1

Looks good,

Just wondering if it would make sense to mention the recording of the
meeting if people want to look at it?

Regards,
  Serge...


On Tue, Jun 2, 2020 at 10:11 AM Francois Papon 
wrote:

> +1
>
> Thanks JB!
>
> regards,
>
> François
> fpa...@apache.org
>
> Le 02/06/2020 à 09:59, Jean-Baptiste Onofre a écrit :
> > Hi guys,
> >
> > I prepared the board report for this month:
> >
> > https://cwiki.apache.org/confluence/display/KARAF/Board+Reports <
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports>
> >
> > Can you please take a look and let me know if I forgot something ?
> >
> > I would like to send the report soon.
> >
> > Thanks,
> > Regards
> > JB
>


Re: [VOTE] Apache Karaf 4.2.9 release

2020-05-19 Thread Serge Huber
+1 !

I want/need 4.2.10 :)

T +41 22 361 3424

9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 19 mai 2020 à 18:38, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.2.9 release to your vote.
> 
> This is a maintenance release on the 4.2.x series bringing fixes, updates and 
> improvements.
> It especially fixes the issues related to the shell (paste didn’t work 
> properly, some commands caused exception, …).
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346465
>  
> 
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1142/ 
> 
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.9/ 
> 
> 
> Git Tag:
> karaf-4.2.9
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB


Re: [HEADS UP] Three new features proposal this week

2020-05-07 Thread Serge Huber
Hi guys,

Sorry to jump in so late I was very busy (mostly with Apache Unomi release
:))

Having a build-time resolution would be indeed very interesting.

Also I love the idea of having simpler dependency error display, because
the current one with all the filters is really hard to read and understand,
even for seasoned OSGi devs. But I'm guessing that's in Felix no ?

I'm very impatient for the ENV variable feature as that one is really a
problem when building docker images, and currently we use a workaround in
Unomi that I don't really like (basically providing overrides for all the
properties manually !)

Thanks for all the hard work, I wish I could be more active directly in
Karaf but I'm already quite busy with my project :)

cheers,
  Serge...

On Thu, May 7, 2020 at 5:39 AM Jean-Baptiste Onofre  wrote:

> Hi Matt,
>
> Local repo is not a problem, but it doesn’t help a lot for resolution.
>
> The resolution state at build time would simplify and speed up a lot the
> bootstrapping.
>
> Regards
> JB
>
> > Le 6 mai 2020 à 20:05, Matt Pavlovich  a écrit :
> >
> >
> >
> >> On May 6, 2020, at 10:45 AM, Steinar Bang  wrote:
> >>
> >>> 2. Improve build tool (part of devx) for build time resolution
> >>
> >> Hm... can this be used to fill up the system directory when creating a
> >> docker image on top of the official image?
> >>
> >
> > Have you looked at using local-repo?  We’ve had good success copying
> artifacts into the local-repo to ship an all-in-one, vs applying on top of
> system. Not married to one way or the other, but might be good to talk it
> through as far as the default tooling behavior and if there is a suggested
> convention on what should be in “system/“ vs “local-repo/“.
> >
> > etc/org.ops4j.pax.url.mvn.cfg:
> > ...
> >file:${karaf.home}/local-repo@snapshots@id=karaf.local-repo
> >
> >
>
>


Re: [VOTE] Apache Karaf (runtime) 4.2.7 release

2019-09-24 Thread Serge Huber
I would love to test and validate this with Apache Unomi but I'm still on
Karaf 4.1.x :)

So +1 (non-binding).

cheers,
  Serge...

On Tue, Sep 24, 2019 at 1:30 PM Jean-Baptiste Onofré 
wrote:

> Hi Grzegorz,
>
> yeah, I already identified those differences. We will address in next
> releases, but no impact.
>
> Regards
> JB
>
> On 24/09/2019 13:08, Grzegorz Grzybek wrote:
> > +1
> >
> > And a report from assemblies/apache-karaf/target/bundle-report.xml:
> >
> >  - pax-web 7.2.11 uses commons-codec 1.11, while Karaf uses 1.13
> >  - hibernate validator 6.0.17.Final uses javax.annotation-api/1.2, while
> > Karaf and pax-web use 1.3
> >  - pax-web 7.2.11 uses
> > mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2,
> > while Karaf uses 1.2.2
> >  - pax-jdbc 1.4.0 uses geronimo-connector/3.1.1 while Karaf uses
> > geronimo-connector/3.1.4
> >  - pax-cdi 1.1.1 uses xbean-bundleutils 4.12, while pax-web 7.2.11 uses
> 4.14
> >
> > but these are minor differences.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> > wt., 24 wrz 2019 o 11:28 Andrea Cosentino  >
> > napisał(a):
> >
> >> +1 (non-binding)
> >>
> >> Thanks JB
> >>
> >> --
> >> Andrea Cosentino
> >> --
> >> Apache Camel PMC Chair
> >> Apache Karaf Committer
> >> Apache Servicemix PMC Member
> >> Email: ancosen1...@yahoo.com
> >> Twitter: @oscerd2
> >> Github: oscerd
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Monday, September 23, 2019, 6:35:20 PM GMT+2, Jean-Baptiste Onofré <
> >> j...@nanthrax.net> wrote:
> >>
> >>
> >>
> >>
> >>
> >> Hi all,
> >>
> >> I submit Apache Karaf (runtime) 4.2.7 to your vote. This is a
> >> maintenance release on the 4.2.x series, bringing updates, improvements
> >> and fixes (client.bat on Windows, config fileinstall reuse, race
> >> condition on config in some activator, ...).
> >>
> >> Release Notes:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345539
> >>
> >> Staging Repository:
> >> https://repository.apache.org/content/repositories/orgapachekaraf-1133/
> >>
> >> Git Tag:
> >> karaf-4.2.7
> >>
> >> Please vote to approve this release:
> >>
> >> [ ] +1 Approve the release
> >> [ ] -1 Don't approve the release (please provide specific comments)
> >>
> >> This vote will be open for at least 72 hours.
> >>
> >> Thanks,
> >> 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: Hello World!

2019-09-19 Thread Serge Huber
When I was starting out with OSGi, there used to be a great OSGI Wiki
available, but it got hacked and was never put back online :(

Any chance this content could be put back online somewhere else ?

Regards,
  Serge...

On Thu, Sep 19, 2019 at 3:43 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Thanks Christian, I will check out your stuff later on. Ideally I would
> love to have a book about karaf and some osgi basics and ds... But I guess
> that's a lot of work.
>
> So I think tutorials and examples are a good pragmatic compromise : )
> 
> From: Jean-Baptiste Onofré 
> Sent: Thursday, September 19, 2019 8:15:08 AM
> To: dev@karaf.apache.org 
> Subject: Re: Hello World!
>
> Hi Christian,
>
> I think Karaf examples are good enough to start. They are maybe too
> simple but provide "classic" use cases (rest, service, jpa, etc).
>
> I agree we can do more, and we are working on it. It's something I
> discuss with some guys at ApacheCon last week.
> I will come with concrete proposal soon ;)
>
> Regards
> JB
>
>
> On 19/09/2019 15:02, Christian Schneider wrote:
> > The problem with OSGi docs is that most of the material is quite old.
> > Much of it does not apply to modern OSGi development anymore.
> >
> > Another issue is that especially for dependency injection there are
> quite a
> > few alternatives. Every of these come with their own pros and cons.
> > As a beginner it is difficult to understand and decide how to start.
> >
> > Karaf is a great way to start playing with OSGi as many things are
> readily
> > available and the shell and webconsole allow some nice insight into the
> > system. What karaf does not provide though is a good introduction into
> > OSGi. I tried to do so with my tutorials but they are more like explained
> > examples.
> >
> > I planned to do a longer introduction around how to build a typical
> > application based on best practices .. but it is a lot of work and I
> never
> > really took on the task.
> >
> > You might be interested in my recent talk about OSGi best practices.
> > Unfortunately in 30 minutes I was not able to really explain how to build
> > an application but maybe the example helps a bit.
> > https://adapt.to/2019/en/schedule/osgi-best-practices.html
> > The most interesting part there is maybe how to build bundles without xml
> > config.
> > The new annotations that combine requirements and configs are also very
> > interesting.
> > Both of these are not yet covered by much material on the web.
> > In the example there is a small application with an angular front end
> and a
> > jax-rs backend that can be easily installed in karaf.
> >
> > Christian
> >
> >
> > Am Mi., 18. Sept. 2019 um 06:45 Uhr schrieb Julian Feinauer <
> > j.feina...@pragmaticminds.de>:
> >
> >> Hi,
> >>
> >> it was not so much karaf (I kind of liked it from the start) it was
> rather
> >> OSGi.
> >> We come from spring and when I looked through all the osgi material lots
> >> of it seemed strange and confusing like Aries, Blueprint, DS, enRoute,
> ... .
> >> Serge helped me a lot with sorting the things in my head and getting all
> >> clear (also with bundle vs. feature vs. feature-repo) and DS stuff and
> lots
> >> more.
> >> So I think Karaf is already doing an excellent job its rather the OSGi
> >> world that is damn confusing and one thing that probably could help is a
> >> small OSGi introduction or something.
> >>
> >> I hope that helps!
> >> Julian
> >>
> >> Am 16.09.19, 11:47 schrieb "Jean-Baptiste Onofré" :
> >>
> >> By the way, Julian, I'm curious. Why did you consider Karaf "hard
> for
> >> you to adopt" ? It's to understand what we can improve (maybe
> >> message/website, example, whatever) in the project to change that !
> >>
> >> Thanks !
> >> Regards
> >> JB
> >>
> >> On 16/09/2019 18:21, Julian Feinauer wrote:
> >> > Hi everybody,
> >> >
> >> > my name is Julian and as I’m new on this list, I just wanted to
> >> shortly introduce myself. I’m a contributor to some Apache projects
> (PLC4X,
> >> IoTDB, Calcite) and I met some karaf folks at the ApacheCon in Las
> Vegas (I
> >> was the guy hanging around introducing JB and Serge).
> >> > I have Karaf on my radar for quite some time but always considered
> >> it to hard for us to adopt.
> >> >
> >> > But, as Serge gave me an awesome hands on introduction yesterday,
> I
> >> feel like we should really start to work with it and see how it goes.
> So,
> >> expect some mails from me here or on user@.
> >> >
> >> > Best
> >> > Julian
> >> >
> >>
> >> --
> >> 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: Re: [VOTE] Move jclouds-karaf and jclouds-cli projects under Karaf project governance

2019-04-17 Thread Serge Huber
+1

On Wed, Apr 17, 2019 at 8:20 PM Andrea Cosentino
 wrote:

> +1. It makes sense
>
> Inviato da Yahoo Mail su Android
>
>   Il mer, 17 apr, 2019 alle 20:16, Francois Papon<
> francois.pa...@openobject.fr> ha scritto:   +1 (binding)
>
> regards,
>
> François Papon
> fpa...@apache.org
>
> Le 17/04/2019 à 19:14, Jean-Baptiste Onofré a écrit :
> > Hi,
> >
> > Some days ago we discussed on the Apache jClouds dev mailing list about
> > moving the jclouds-karaf and jclouds-cli project under the Karaf project
> > governance, as it's hard for the jClouds community to maintain them.
> >
> > So, I'm proposing:
> >
> > 1. We keep the git repository where they are currently:
> > https://gitbox.apache.org/repos/asf?p=jclouds-karaf.git
> > https://gitbox.apache.org/repos/asf?p=jclouds-cli.git
> > We also keep the Maven coordinates as they are.
> > It would be completely transparent for our users.
> >
> > 2. The governance changes to Karaf PMC. I will ask to INFRA to change
> > the team (group) managing the repo and Jenkins jobs.
> > 3. I will update Jenkins to notify Karaf mailing list.
> >
> > I already have couple of PRs ready for upgrade jclouds-karaf for Karaf
> > 4.2.x/4.3.x and some other cleanups.
> >
> > Please vote to approve this change:
> >
> > [ ] +1 Approve the change
> > [ ] -1 Don't approve the change (please provide specific comments)
> >
> > Thanks,
> > Regards
> > JB
>
>


Re: [VOTE] Apache Karaf (runtime) 4.2.5 release

2019-04-17 Thread Serge Huber
+1 (non-binding)

cheers,
   Serge

On Wed, Apr 17, 2019 at 8:30 PM Jean-Baptiste Onofré 
wrote:

> Hi all,
>
> I submit Apache Karaf (runtime) 4.2.5 to your vote. This is a
> maintenance release on the 4.2.x series, bringing some improvements and
> bug fixes (scr commands, new docker goal in maven plugin, new
> distribution examples, ...).
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345153
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1131/
>
> Git Tag:
> karaf-4.2.5
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


Re: [PROPOSAL] Introduce "static" resolver

2019-03-04 Thread Serge Huber
I also like the proposed solution using build-time generation.

Just a question about the single classloader though: isn't that going to
cause problems if projects want to use different versions of a library? I
agree that they shouldn't but it's also something that makes Karaf more
powerful than Spring in general.

Regards,
  Serge...

On Mon, Mar 4, 2019 at 4:28 PM Christian Schneider 
wrote:

> +1
>
> Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet <
> gno...@apache.org
> >:
>
> > Right, and also, the demo is using profiles, and I think we should have a
> > demo using plain features instead.  That does not really change anything,
> > as the assembly is all done by the plugin, but this lead to a simpler
> demo.
> >
> > Le lun. 4 mars 2019 à 15:18, Jean-Baptiste Onofré  a
> > écrit :
> >
> > > That's a very good argument and actually I think you are right, that's
> > > even better.
> > >
> > > Maybe the "missing" part if the tooling and the documentation around
> > this.
> > >
> > > Let me prepare a PR for that !
> > >
> > > Regards
> > > JB
> > >
> > > On 04/03/2019 15:15, Guillaume Nodet wrote:
> > > > I would argue that we should not use any resolver at all for such
> > > > containers, and that's already doable with the karaf plugin.
> > > > We have a demo of that in the
> > > >   examples/karaf-profile-example/karaf-profile-example-static
> > > > The resolution is done at build time and the list of bundles is
> written
> > > in
> > > > the
> > > >   etc/startup.properties
> > > > file, by virtue of having the features configured at startup phase
> > rather
> > > > than boot phase.
> > > > In this demo, we even avoid the fact that felix usually copy the
> > bundles
> > > in
> > > > its internal storage by using startup bundles referenced as:
> > > >
> > >
> >
> reference\:file\:org/ops4j/pax/logging/pax-logging-api/1.10.1/pax-logging-api-1.10.1.jar
> > > > = 8
> > > > This leads to no resolution at all at runtime (the example assembly
> > does
> > > > not even contain the karaf features service), a much faster startup
> > time,
> > > > less disk space used.
> > > >
> > > > Unless I'm mistaken, I don't really see the need to build another
> > > different
> > > > thing, but maybe I missed something.
> > > >
> > > > Guillaume
> > > >
> > > > Le lun. 4 mars 2019 à 15:00, Jean-Baptiste Onofré 
> a
> > > > écrit :
> > > >
> > > >> Hi guys,
> > > >>
> > > >> During the introduction thread about "kloud initiative", we quickly
> > > >> discussed about the resolver.
> > > >>
> > > >> Today, we can see concerns about the current features resolver,
> > > especially:
> > > >> - the resolution at runtime can be different than the one done
> during
> > > >> verify
> > > >> - the resolution at runtime can be impacted by the version range
> > > >> - the resolution can cause bunch of refresh, impacting startup and
> > > >> resolution time
> > > >>
> > > >> If the current resolver is great for a "container/dynamic" approach
> > > >> where karaf is running and we deploy things in it, it's not good
> for a
> > > >> "static" bootstrapping as expected for a runtime running on cloud or
> > > >> docker.
> > > >>
> > > >> I would like to propose to introduce a feature resolver named
> "karaf".
> > > >> The idea is to use a resolver that reads the features repositories
> as
> > > >> they are and install bundles/configuration/etc without checking all
> > > >> capabilities and requirements. It sounds a bit like a mix of the
> > simple
> > > >> resolver we use in the Karaf maven plugin in the verify goal, and
> what
> > > >> we had in the past (in Karaf 2.x for instance). It doesn't perform
> any
> > > >> refresh, it's up to the developer (and of course the tooling) to
> > provide
> > > >> a complete features definition.
> > > >>
> > > >> The resolver could be configured in
> etc/org.apache.karaf.features.cfg
> > > >> and we can have a "static" distribution with this resolver by
> default.
> > > >>
> > > >> I would propose to rename "standard" distribution as "container",
> and
> > we
> > > >> will provide the "static" distribution.
> > > >>
> > > >> Thoughts ?
> > > >>
> > > >> Another idea around this is Karaf Winegrower. Winegrower is kind of
> > > >> Karaf Boot, using a single/unique classloader instead of one
> > classloader
> > > >> per bundle. It's pretty convenient for cloud as well.
> > > >> Maybe we can have winegrower as Karaf subproject.
> > > >> Currently Winegrower is here:
> https://github.com/jbonofre/winegrower
> > > >>
> > > >> 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
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
>
>
> --
> --
> Christian Schneider
> 

Re: [DISCUSS] Launching the kloud initiative

2019-02-13 Thread Serge Huber
Just read this:

https://www.linkedin.com/pulse/serverless-framework-michael-vargas

What would be perfect is to be able to replace the Nodejs runtime in this 
config with Karaf

I think that Karaf makes a ton of sense as a « server less » runtime. You build 
your features and don’t care on what hardware they run or how they are deployed.

Wdyt ?

Regards,
  Serge

T +41 22 361 3424

9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 13 févr. 2019 à 14:45, Serge Huber  a écrit :
> 
> My thinking is that the env variables would override, but if you
> change during runtime a value it could still change (and be
> serialized), or we could somehow prevent that. But on next start the
> env override would apply again anyway.
> 
> It shouldn't be difficult to make this behavior configurable anyway,
> but it is a huge requirement for Docker support, and possibly other
> containers might have similar requirements.
> 
> Regards,
>  Serge...
> 
>> On Wed, Feb 13, 2019 at 1:29 PM Jean-Baptiste Onofré  
>> wrote:
>> 
>> Hi Christian
>> 
>> I already started a PoC using a decorator to ConfigAdmin to
>> "inject/override" configuration from plugable backend (like env, like
>> AWS service, ...). It use a converter to map the "backend" config to
>> config admin style.
>> 
>> I will share my PoC on PR asap.
>> 
>> Regards
>> JB
>> 
>>> On 13/02/2019 12:49, Christian Schneider wrote:
>>> I also think configuration from env variables is one of the most important
>>> things to solve. Docker images and Kubernetes deployment descriptors often
>>> look horribly complicated when this is not solved well.
>>> 
>>> I have seen two interesting attempts at this:
>>> 1. The configurer from Peter Kriens. It allows to override any OSGi config
>>> from the command line and I think it also allows using env variables. (see
>>> https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider
>>> )
>>> 2. Dropwizard configuration style. There you have a configuration in yaml
>>> form but you can use placeholders with defaults that can feed from env
>>> variables. (See
>>> https://www.dropwizard.io/0.9.3/docs/manual/core.html#environment-variables
>>> ).
>>> 
>>> Especially the dropwizard style looks really good.
>>> One thing to solve there is how to bridge the gap to OSGi configs that are
>>> always a set of properties vs spring boot or similar configs that are a
>>> flat list of properties. The tree structure of yaml or json might help us
>>> there.
>>> 
>>> Christian
>>> 
>>>> Am Mi., 13. Feb. 2019 um 08:29 Uhr schrieb Serge Huber :
>>>> 
>>>> +1
>>>> 
>>>> I really like this project, but I think we should also be careful to
>>>> really leverage Karaf's strengths compared to other frameworks (such
>>>> as Spring or others).
>>>> 
>>>> I have a millions things that come to mind, how to address :
>>>> - upgrades
>>>> - rolling upgrades
>>>> - leveraging Karaf to avoid building lots of containers and use
>>>> instead OSGi to reduce the memory / CPU footprint
>>>> - configuration of containers (passed as env or even centralized ?)
>>>> 
>>>> There are also some very interesting developments coming to the JDK
>>>> (in JDK 12) such as Project Loom that could help scale Karaf to
>>>> millions of network connections on single instances without the need
>>>> for NIO.
>>>> 
>>>> We were talking in another thread about having a very thin OS-layer on
>>>> top of Karaf to have baremetal performance and I think this could be
>>>> very interesting in a cloud setup as well.
>>>> 
>>>> Anyway, I'm just throwing ideas here, hope you don't mind :)
>>>> 
>>>> cheers,
>>>>  Serge
>>>> 
>>>> On Mon, Feb 11, 2019 at 2:11 PM David Daniel
>>>>  wrote:
>>>>> 
>>>>> Thank you,
>>>>>  I would also be curious if it is possible to work to align some
>>>> features
>>>>> changes to be compatible with the osgi feature spec.
>>>>> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf
>>>> It

Re: [DISCUSS] Launching the kloud initiative

2019-02-13 Thread Serge Huber
My thinking is that the env variables would override, but if you
change during runtime a value it could still change (and be
serialized), or we could somehow prevent that. But on next start the
env override would apply again anyway.

It shouldn't be difficult to make this behavior configurable anyway,
but it is a huge requirement for Docker support, and possibly other
containers might have similar requirements.

Regards,
  Serge...

On Wed, Feb 13, 2019 at 1:29 PM Jean-Baptiste Onofré  wrote:
>
> Hi Christian
>
> I already started a PoC using a decorator to ConfigAdmin to
> "inject/override" configuration from plugable backend (like env, like
> AWS service, ...). It use a converter to map the "backend" config to
> config admin style.
>
> I will share my PoC on PR asap.
>
> Regards
> JB
>
> On 13/02/2019 12:49, Christian Schneider wrote:
> > I also think configuration from env variables is one of the most important
> > things to solve. Docker images and Kubernetes deployment descriptors often
> > look horribly complicated when this is not solved well.
> >
> > I have seen two interesting attempts at this:
> > 1. The configurer from Peter Kriens. It allows to override any OSGi config
> > from the command line and I think it also allows using env variables. (see
> > https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider
> > )
> > 2. Dropwizard configuration style. There you have a configuration in yaml
> > form but you can use placeholders with defaults that can feed from env
> > variables. (See
> > https://www.dropwizard.io/0.9.3/docs/manual/core.html#environment-variables
> > ).
> >
> > Especially the dropwizard style looks really good.
> > One thing to solve there is how to bridge the gap to OSGi configs that are
> > always a set of properties vs spring boot or similar configs that are a
> > flat list of properties. The tree structure of yaml or json might help us
> > there.
> >
> > Christian
> >
> > Am Mi., 13. Feb. 2019 um 08:29 Uhr schrieb Serge Huber :
> >
> >> +1
> >>
> >> I really like this project, but I think we should also be careful to
> >> really leverage Karaf's strengths compared to other frameworks (such
> >> as Spring or others).
> >>
> >> I have a millions things that come to mind, how to address :
> >> - upgrades
> >> - rolling upgrades
> >> - leveraging Karaf to avoid building lots of containers and use
> >> instead OSGi to reduce the memory / CPU footprint
> >> - configuration of containers (passed as env or even centralized ?)
> >>
> >> There are also some very interesting developments coming to the JDK
> >> (in JDK 12) such as Project Loom that could help scale Karaf to
> >> millions of network connections on single instances without the need
> >> for NIO.
> >>
> >> We were talking in another thread about having a very thin OS-layer on
> >> top of Karaf to have baremetal performance and I think this could be
> >> very interesting in a cloud setup as well.
> >>
> >> Anyway, I'm just throwing ideas here, hope you don't mind :)
> >>
> >> cheers,
> >>   Serge
> >>
> >> On Mon, Feb 11, 2019 at 2:11 PM David Daniel
> >>  wrote:
> >>>
> >>> Thank you,
> >>>   I would also be curious if it is possible to work to align some
> >> features
> >>> changes to be compatible with the osgi feature spec.
> >>> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf
> >> It
> >>> might be possible to bridge some of the gap between bnd and karaf.  I
> >> love
> >>> things about both frameworks and would be super excited if they could
> >> work
> >>> together.
> >>>
> >>> David
> >>>
> >>> On Mon, Feb 11, 2019 at 7:01 AM Jean-Baptiste Onofré 
> >>> wrote:
> >>>
> >>>> Thanks for your feedback David, nice idea about jlink, I have to
> >>>> investigate a little about it, but definitely interesting.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 11/02/2019 12:52, David Daniel wrote:
> >>>>> I really like the idea of the static build and features in code.  I
> >> think
> >>>>> the jdk is making great strides in getting java running well on
> >> docker
> >>>>> java 9 jlink for small images that can be copied and s

Re: [DISCUSS] Launching the kloud initiative

2019-02-13 Thread Serge Huber
+1 on promoting Karaf. May I remind you I produced a while ago a lot
of resources comparing Karaf to other frameworks solutions?

https://docs.google.com/spreadsheets/d/1Js5qTXXugEOsp-5kUYoUbCKP1xt1dUx8efWZcGbm6C4/edit#gid=0
https://docs.google.com/document/d/1b1aJ_qimFxPxD9BDtaq21sW_h43kWUXrLVTWAFR_Coc/edit#heading=h.3uzgwjymutz
https://docs.google.com/document/d/1cZp-KymYOVgpBiHVPdLAYfKY81U_LzfqVYCIcVd2Mfg/edit#heading=h.9xhre7dovs0q
https://docs.google.com/document/d/1e4vvXhTNMaAbb7UgDSgmRjvVHp_nm981ztw33k0kHN8/edit#heading=h.2jt36cq65nll

Of course, these resources can be improved, especially in light of the
kloud initiative, but I think that it would help promote Karaf more
aggressively.

Regards,
  Serge...

On Wed, Feb 13, 2019 at 9:06 AM Jean-Baptiste Onofré  wrote:
>
> Good point Serge.
>
> The huge advantage of Karaf is our "polymorphic" approach: we can
> address lot of different packaging, use cases, etc.
>
> So, update is a key thing as well (more for dynamic approach than static
> I think).
>
> I forgot to mention one area where we would need help: spread the word
> and advertising. With the kloud initiative, I think we can seduce more
> users, but they have to find Karaf and what they can do with it and how
> Karaf can help them.
>
> I created new Jira yesterday evening, and now I'm starting from PoC that
> you will be able to see as PRs soon.
>
> Thanks for your enthusiasm and your interest in Karaf !
>
> Let's build the "new" Karaf ;)
>
> Regards
> JB
>
> On 13/02/2019 08:29, Serge Huber wrote:
> > +1
> >
> > I really like this project, but I think we should also be careful to
> > really leverage Karaf's strengths compared to other frameworks (such
> > as Spring or others).
> >
> > I have a millions things that come to mind, how to address :
> > - upgrades
> > - rolling upgrades
> > - leveraging Karaf to avoid building lots of containers and use
> > instead OSGi to reduce the memory / CPU footprint
> > - configuration of containers (passed as env or even centralized ?)
> >
> > There are also some very interesting developments coming to the JDK
> > (in JDK 12) such as Project Loom that could help scale Karaf to
> > millions of network connections on single instances without the need
> > for NIO.
> >
> > We were talking in another thread about having a very thin OS-layer on
> > top of Karaf to have baremetal performance and I think this could be
> > very interesting in a cloud setup as well.
> >
> > Anyway, I'm just throwing ideas here, hope you don't mind :)
> >
> > cheers,
> >   Serge
> >
> > On Mon, Feb 11, 2019 at 2:11 PM David Daniel
> >  wrote:
> >>
> >> Thank you,
> >>   I would also be curious if it is possible to work to align some features
> >> changes to be compatible with the osgi feature spec.
> >> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf  It
> >> might be possible to bridge some of the gap between bnd and karaf.  I love
> >> things about both frameworks and would be super excited if they could work
> >> together.
> >>
> >> David
> >>
> >> On Mon, Feb 11, 2019 at 7:01 AM Jean-Baptiste Onofré 
> >> wrote:
> >>
> >>> Thanks for your feedback David, nice idea about jlink, I have to
> >>> investigate a little about it, but definitely interesting.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On 11/02/2019 12:52, David Daniel wrote:
> >>>> I really like the idea of the static build and features in code.  I think
> >>>> the jdk is making great strides in getting java running well on docker
> >>>> java 9 jlink for small images that can be copied and spun up quickly
> >>>> java 10 defaults improvements https://aboullaite.me/docker-java-10/
> >>>> portola for running java on musl (alpine without glibc)
> >>>> https://openjdk.java.net/projects/portola/
> >>>> loom is coming for not spinning off a ton of threads
> >>>> If at all possible I would love to be able to build a minimal karaf
> >>>> distribution with jlink from java module files that were generated from
> >>> the
> >>>> karaf resolver.  I think this might be a little much though and don't
> >>> even
> >>>> know if it is possible.  Just something that might be able to be looked
> >>> at
> >>>> while the code is being written.
> >>>>
> >>>> David
> >>>>
> >>>

Re: [DISCUSS] Launching the kloud initiative

2019-02-12 Thread Serge Huber
+1

I really like this project, but I think we should also be careful to
really leverage Karaf's strengths compared to other frameworks (such
as Spring or others).

I have a millions things that come to mind, how to address :
- upgrades
- rolling upgrades
- leveraging Karaf to avoid building lots of containers and use
instead OSGi to reduce the memory / CPU footprint
- configuration of containers (passed as env or even centralized ?)

There are also some very interesting developments coming to the JDK
(in JDK 12) such as Project Loom that could help scale Karaf to
millions of network connections on single instances without the need
for NIO.

We were talking in another thread about having a very thin OS-layer on
top of Karaf to have baremetal performance and I think this could be
very interesting in a cloud setup as well.

Anyway, I'm just throwing ideas here, hope you don't mind :)

cheers,
  Serge

On Mon, Feb 11, 2019 at 2:11 PM David Daniel
 wrote:
>
> Thank you,
>   I would also be curious if it is possible to work to align some features
> changes to be compatible with the osgi feature spec.
> https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf  It
> might be possible to bridge some of the gap between bnd and karaf.  I love
> things about both frameworks and would be super excited if they could work
> together.
>
> David
>
> On Mon, Feb 11, 2019 at 7:01 AM Jean-Baptiste Onofré 
> wrote:
>
> > Thanks for your feedback David, nice idea about jlink, I have to
> > investigate a little about it, but definitely interesting.
> >
> > Regards
> > JB
> >
> > On 11/02/2019 12:52, David Daniel wrote:
> > > I really like the idea of the static build and features in code.  I think
> > > the jdk is making great strides in getting java running well on docker
> > > java 9 jlink for small images that can be copied and spun up quickly
> > > java 10 defaults improvements https://aboullaite.me/docker-java-10/
> > > portola for running java on musl (alpine without glibc)
> > > https://openjdk.java.net/projects/portola/
> > > loom is coming for not spinning off a ton of threads
> > > If at all possible I would love to be able to build a minimal karaf
> > > distribution with jlink from java module files that were generated from
> > the
> > > karaf resolver.  I think this might be a little much though and don't
> > even
> > > know if it is possible.  Just something that might be able to be looked
> > at
> > > while the code is being written.
> > >
> > > David
> > >
> > >
> > > On Mon, Feb 11, 2019 at 1:57 AM Jean-Baptiste Onofré 
> > > wrote:
> > >
> > >> Hi guys,
> > >>
> > >> As we now have released Karaf runtime 4.2.3 and started 4.3.x, I think
> > >> it's time to discuss and move forward "concretely" about the "kloud"
> > >> (Karaf for the Cloud) initiative.
> > >>
> > >> I think the first approach is focused on the developers and devops. I
> > >> created the following Jira:
> > >>
> > >> https://issues.apache.org/jira/browse/KARAF-5923
> > >> https://issues.apache.org/jira/browse/KARAF-6148
> > >> https://issues.apache.org/jira/browse/KARAF-6149
> > >> https://issues.apache.org/jira/browse/KARAF-6150
> > >>
> > >> The idea is really to simplify the features generation and distribution
> > >> packaging.
> > >>
> > >> For the features generation, I'm thinking on annotations directly in the
> > >> code (in package-info.java for instance) describing the features needed
> > >> by the application. The annotations scanner could then create the
> > >> features XML using the code itself and the annotations. That would allow
> > >> us to not relay on Maven and be able to support CLI/Gradle/Maven. In the
> > >> case where the user uses Maven, we could better leverage Maven to get
> > >> some details. The idea is to especially easily create features XML to
> > >> build "static" runtime (that make sense for the cloud).
> > >>
> > >> After the features XML generation, we should have a easier way to build
> > >> a distribution. We also have to provide multiple "packaging output" like
> > >> archives (zip/tar.gz), uber jar (embedding karaf and user application),
> > >> docker image, openimage, kubernetes meta, ...
> > >> The idea is to have a ready to go packaging for the cloud.
> > >>
> > >> For the cloud perspective, the distribution should be
> > >> "immutable/static". Currently, the resolver we have is great for
> > >> "dynamic" deployment but could be painful for static one (dealing with
> > >> refresh, multiple versions resolution, etc).
> > >> I'm proposing to create kind of "static" resolver
> > >> (https://issues.apache.org/jira/browse/KARAF-6147) directly taking boot
> > >> features and installing straight forward what's defined in the features.
> > >> It should result with a more "predictable" behavior, really helpful from
> > >> a cloud perspective.
> > >>
> > >> Finally, I created some Jira about general improvements for the cloud
> > >> and docker:
> > >>
> > >> 

Re: [VOTE] Apache Karaf Cellar 4.1.2 release

2018-10-10 Thread Serge Huber
+1 (non-binding)

Regards,
  Serge...

On Wed, Oct 10, 2018 at 2:01 PM Jamie G.  wrote:
>
> +1 (binding)
>
> Cheers,
> Jamie
> On Wed, Oct 10, 2018 at 3:35 AM Jean-Baptiste Onofré  
> wrote:
> >
> > Hi all,
> >
> > I submit Karaf Cellar 4.1.2 release to your vote. This release is a
> > maintenance release of the Cellar 4.1.x serie.
> >
> > Release Notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12341724
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1118/
> >
> > Git Tag:
> > cellar-4.1.2
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com


Re: [VOTE] Apache Karaf Cellar 4.0.5 release

2018-10-09 Thread Serge Huber
Big +1 (non-binding)

Thanks a lot JB, we were anxiously waiting on this one !

Regards,
  Serge
On Tue, Oct 9, 2018 at 7:06 PM Francois Papon
 wrote:
>
> +1 (non-binding)
>
> Thanks JB!
>
> Regards,
>
> François Papon
> fpa...@apache.org
>
> Le 09/10/2018 à 19:31, Jean-Baptiste Onofré a écrit :
> > Hi all,
> >
> > I submit Karaf Cellar 4.0.5 release to your vote. This release is a
> > maintenance release of the Cellar 4.0.x serie.
> >
> > Release Notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340649
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1117/
> >
> > Git Tag:
> > cellar-4.0.5
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
>


Re: [VOTE] Apache Karaf (Container) 4.2.0 release

2018-04-03 Thread Serge Huber
+1 (non binding)

Didn't have time to test it with Apache Unomi but I will do it as soon as I
can :)

cheers,
  Serge...

Serge Huber
CTO & Co-Founder
T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com <http://www.jahia.com/>
SKYPE | LINKEDIN <https://www.linkedin.com/in/sergehuber> | TWITTER
<https://twitter.com/sergehuber> | VCARD
<http://www.jahia.com/vcard/HuberSerge.vcf>


> JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and
to discover why Jahia is a leading User Experience Platform (UXP) for
Digital Transformation.

On Tue, Apr 3, 2018 at 11:28 AM, Grzegorz Grzybek <gr.grzy...@gmail.com>
wrote:

> My tests show that everything's fine with pax-web 7. Thanks!
>
> +1 (non-binding).
>
> regards
> Grzegorz Grzybek
>
> 2018-04-03 10:25 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
> > Hi all,
> >
> > I submit Karaf (Container) 4.2.0 release to your vote.
> >
> > This is the first GA on the 4.2.x series, following M1 and M2.
> >
> > NB: I preferred to postpone the merge of the new examples as it needs a
> > little
> > polish. The PR is already available and it will be included in 4.2.1
> (that
> > we
> > can expect beginning of May depending of 4.2.0 feedbacks):
> > https://github.com/apache/karaf/pull/484
> >
> > Release Notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12311140=12342076
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1110/
> >
> > Git Tag:
> > karaf-4.2.0
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>


Re: [VOTE] Apache Karaf Decanter 1.1.0 release

2016-03-29 Thread Serge Huber
+1 (non-binding)


> On 29 mars 2016, at 08:17, Andrea Cosentino  
> wrote:
> 
> +1 (non-binding)
> 
> Thanks.
> --
> Andrea Cosentino 
> --
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1...@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
> 
> 
> 
> On Monday, March 28, 2016 3:18 PM, Christian Schneider 
>  wrote:
> +1 (non binding)
> 
> Christian
> 
> 
> 2016-03-28 10:52 GMT+02:00 Morgan :
> 
>> +1 (non-binding)
>> 
>> 
>> On 2016-03-28 10:09, Jean-Baptiste Onofré wrote:
>> 
>>> Hi all,
>>> 
>>> I submit the Decanter 1.1.0 release to your vote.
>>> 
>>> Release Notes:
>>> 
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334862
>>> 
>>> Staging Repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-1058/
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Do not approve the release (please provide specific comments)
>>> 
>>> This vote will be open for 72 hours.
>>> 
>>> Regards
>>> JB
>>> 
>> 
>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> 
> Open Source Architect
> http://www.talend.com
> > 



Re: Introduction

2016-03-24 Thread Serge Huber

> On 23 mars 2016, at 21:29, Achim Nierbeck  wrote:
> 
>> *Interest #3:* Support filesystem watching (or editor watching for
>> integrated editors) and hot-swap the bundle being developed into the
>> running environment either on-demand or automatically whenever there are no
>> syntax errors.  In conjunction with #2, this could make software
>> development more agile.
>> 
> 
> Sounds like you want to build bundles on the fly, one point to start would
> be to have the Pax-Swissbox bundle at hand, to create "Tiny-Bundles". If
> it's more like a static monitoring of a filesystem, we already got that
> with felix-fileinstaller.
> 

Actually I’ve used another trick to do very dynamic file updating. If these are 
web resources served by an HttpService, I’ve created a custom HttpContext that 
will look for a bundle header that points to the source code. If it exists I do 
file lookups in the source directly first, and then in the bundle. This way 
even without deploying a bundle you can load file updates !

Of course this only works for resources, not for Java code.

cheers,
  Serge… 

Re: [PROPOSAL] Create karaf-boot project

2016-03-21 Thread Serge Huber
+1 :) (actually just a +1)

A subproject does seem better but then I’m no expert.

I have a lot of things to boot :) 

cheers,
  Serge… 

> On 21 mars 2016, at 12:52, Jean-Baptiste Onofré  wrote:
> 
> Hi team,
> 
> Regarding the discussion we had couple of months ago, karaf-boot PoC started 
> on my github.
> 
> In order to give more visibility, and allow anyone to work on it, I propose 
> to donate this as a Karaf sub-project or a Karaf Container module.
> 
> Right now, I will push some enhancements/new features that I did last week, 
> and I will update the README (markdown) to describe the purposes and 
> objectives of karaf-boot.
> 
> For the donation, I see two ways:
> 
> - a new subproject as Decanter, or Cellar, meaning karaf-boot will have its 
> own git repo.
> - a module in Karaf Container (so a folder named boot or karaf-boot in the 
> Karaf container git repo).
> 
> Thoughts ?
> 
> Thanks,
> Regards
> JB
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Small improvement in Karaf's Main class

2016-02-26 Thread Serge Huber

Hi guys, 

Just to let you know I’ve created the following issue : 

https://issues.apache.org/jira/browse/KARAF-4361 


and I attached a patch to it that implements the changes

This is not a big change but it could make a world of difference in our 
embedded integration of Karaf. Without this we would basically have to recopy 
the Main class and fork it.

I was wondering if you would prefer a Git pull request or is the patch ok ?

cheers,
  Serge… 

Re: Known Karaf users

2016-02-14 Thread Serge Huber
I was actually proposing to do both a community page and rotating banners on 
the home page :) But I agree that a strong community page would be fantastic 
too !

cheers,
  Serge… 


> On 14 févr. 2016, at 14:08, David Daniel <david.daniel.1...@gmail.com> wrote:
> 
> I like the idea of a community page better..  You can also put stuff up
> there like meetups and events so that people will know in advance when and
> where they are happening.  This is beneficial to keep people aware of what
> is going on around them.  As a developer I have very little say where
> company money goes for example we rarely pay for support of open source
> products ourselves.  One thing I do have some control over though is
> conferences, certifications and training.  I am going to nescala and the
> typelevel summit next month.  I also went to Spark East last year and a
> couple other conferences.  Training and certifications are a good way to
> get a little money if you are already going to be in an area when a project
> gets larger.  A community page helps people know what area others will be
> in.  An example would be posting a meetup at bar after an apache conference
> or if there is a meetup.com meetup will be tackling a karaf subject.  Last
> year there was an open daylight development introduction meetup.  Two hours
> of it was spent talking about osgi and karaf but of the 50 people there
> most of them were networking people.  When we broke into small groups to
> try to fix simple bugs it would have been helpful if there was a person in
> each group to help with karaf and osgi issues.
> 
> David
> 
> On Sun, Feb 14, 2016 at 4:53 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
> 
>> We already have the news as a rotating banner, I'm afraid it will be too
>> much if you have a second banner.
>> 
>> I can try it anyway to see the rendering.
>> 
>> Regards
>> JB
>> 
>> 
>> On 02/14/2016 10:45 AM, Serge Huber wrote:
>> 
>>> I actually like the idea of the rotating banner on the home page with
>>> quotes of the various case studies. Wdyt?
>>> 
>>> Cheers,
>>>   Serge
>>> 
>>> Serge Huber
>>> CTO & Co-Founder
>>> 
>>> T +41 22 361 3424
>>> 9 route des Jeunes | 1227 Acacias | Switzerland
>>> jahia.com
>>> SKYPE | LINKEDIN | TWITTER | VCARD
>>> 
>>> 
>>> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is
>>>> a leading User Experience Platform (UXP) for Digital Transformation.
>>>> 
>>> 
>>> Le 14 févr. 2016 à 07:18, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit
>>>> :
>>>> 
>>>> Awesome,
>>>> 
>>>> thanks David.
>>>> 
>>>> I gonna add a section on the website (in "Community").
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 02/13/2016 10:00 PM, David Daniel wrote:
>>>>> I don't see a problem with anything I said as it is all public and
>>>>> unclassified, see
>>>>> http://www.afei.org/PE/4A07/Documents/DIB%20Description.pdf witch
>>>>> specifies
>>>>> the DDF's use within DCGS  I would change the security scan names to
>>>>> just
>>>>> government security scans and leave it up to people to google what they
>>>>> are.  I would also change terabytes of data to just large amounts of
>>>>> data
>>>>> as I am not sure the amount of data and less specific is safer.  You can
>>>>> reword how you would like and I would reference the announcement above
>>>>> as
>>>>> it is an official government release that talks about the benefits of
>>>>> karaf
>>>>> and osgi rather than just a random user.  There are other documents out
>>>>> there if you do a little more googling.
>>>>> 
>>>>> On Sat, Feb 13, 2016 at 3:31 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>>>>> wrote:
>>>>> 
>>>>> Thanks guys.
>>>>>> 
>>>>>> Do we have approval to add on the website ?
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>> 
>>>>>> On 02/13/2016 05:49 PM, David Daniel wrote:
>>>>>>> 
>>>>>>> I work on karaf with a number of projects for the US government.  I
>>>>>>> have
>>>>>>> mentioned it before b

Re: Known Karaf users

2016-02-14 Thread Serge Huber
For me its all good too !

Cheers,
  Serge

Serge Huber
CTO & Co-Founder

T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 13 févr. 2016 à 21:31, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit :
> 
> Thanks guys.
> 
> Do we have approval to add on the website ?
> 
> Regards
> JB
> 
>> On 02/13/2016 05:49 PM, David Daniel wrote:
>> I work on karaf with a number of projects for the US government.  I have
>> mentioned it before but here is a link to one that is open source
>> https://github.com/codice/ddf  I have also seen a number of other products
>> that we integrate with starting the migration to karaf such as saiku 4.0
>> and pentaho 6.0
>> http://wiki.pentaho.com/display/PEOpen/6.0+OSGI+documentation  Our company
>> has a text analytics/natural language processing and cross document
>> correlation product that runs on karaf but I think we may be competitors
>> with Benson's company and he is a committer. I have also met a lot of
>> redhat people in the DC area that work with karaf/service mix through
>> fuse.  My guess is that you will find karaf use is a lot like web forums.
>> For every person that comments on karaf in the mailing list there are 100's
>> who are just lurkers.
>> 
>> For a short marketing spiel I would go with something along the lines of.
>> 
>> "Karaf was selected as the server to host a large DOD/Cross Agency
>> application that searches and serves terabytes of data to thousands of
>> users across the government.  Karaf has undergone rigorous security scans
>> such as Fortify, Retna and ACAS all while meeting the performance
>> requirements expected of a critical system."
>> 
>> David
>> 
>>> On Sat, Feb 13, 2016 at 9:04 AM, Serge Huber <shu...@jahia.com> wrote:
>>> 
>>> I like the idea too. Let me try for Jahia :
>>> 
>>> "Jahia uses Apache Karaf in two of its products : Marketing Factory and
>>> Digital Experience Manager (DXM). Marketing Factory actually uses Apache
>>> Unomi that uses Apache Karaf as its runtime, and DXM uses Apache Karaf as
>>> an embedded OSGi runtime inside its JavaEE Web Application. Both systems
>>> are commercially available applications that are deployed at large
>>> customers throughout the world and rely upon Apache Karaf to deliver
>>> high-performance, scalable and highly available solutions”.
>>> 
>>> How does this read ? Is it acceptable ?
>>> 
>>> cheers,
>>>   Serge…
>>> 
>>>>> On 13 févr. 2016, at 08:48, Christian Schneider <ch...@die-schneider.net>
>>>> wrote:
>>>> 
>>>> A list of users of karaf would be nice but I think something even better
>>> would be to have a short success story for each user.
>>>> The story could show an overview of the architecture and technologies
>>> they use as well as their business case.
>>>> We could then showcase one user in a round robin fashion on the karaf
>>> entry page with a short teaser. A click would go to the full story and
>>>> also give links to all the other stories.
>>>> 
>>>> Of course we have to agree on some rules how such a story should look
>>> like. So for example maybe we maybe would not want too blatant advertising
>>> for the user.
>>>> We might also want to set a limit for the size of the story.
>>>> 
>>>> I could describe what Talend does with Karaf and also ask some users I
>>> know for their stories.
>>>> 
>>>> What do you think?
>>>> 
>>>> Christian
>>>> 
>>>>> On 10.02.2016 19:06, Serge Huber wrote:
>>>>> Hello,
>>>>> 
>>>>> I just got a question from management about the list of known users of
>>> Karaf.
>>>>> I couldn't provide a nice list and his got me thinking about putting
>>> some users on the home page and then link to a more complete list.
>>>>> 
>>>>> I can already offer to list my company if that helps :)
>>>>> 
>>>>> Cheers,
>>>>>   Serge
>>>>> 
>>>>> Serge Huber
>>>>> CTO & Co-Founder
>>>>> 
>>>>> T +41 22 361 3424
>>>>> 9 route des Jeunes | 1227 Acacias | Switzerland
>>>>> jahia.com
>>>>> SKYPE | LINKEDIN | TWITTER | VCARD
>>>>> 
>>>>>> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia
>>> is a leading User Experience Platform (UXP) for Digital Transformation.
>>>> 
>>>> 
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>> 
>>>> Open Source Architect
>>>> http://www.talend.com
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Re: Known Karaf users

2016-02-14 Thread Serge Huber
I actually like the idea of the rotating banner on the home page with quotes of 
the various case studies. Wdyt?

Cheers,
  Serge

Serge Huber
CTO & Co-Founder

T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 14 févr. 2016 à 07:18, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit :
> 
> Awesome,
> 
> thanks David.
> 
> I gonna add a section on the website (in "Community").
> 
> Regards
> JB
> 
>> On 02/13/2016 10:00 PM, David Daniel wrote:
>> I don't see a problem with anything I said as it is all public and
>> unclassified, see
>> http://www.afei.org/PE/4A07/Documents/DIB%20Description.pdf witch specifies
>> the DDF's use within DCGS  I would change the security scan names to just
>> government security scans and leave it up to people to google what they
>> are.  I would also change terabytes of data to just large amounts of data
>> as I am not sure the amount of data and less specific is safer.  You can
>> reword how you would like and I would reference the announcement above as
>> it is an official government release that talks about the benefits of karaf
>> and osgi rather than just a random user.  There are other documents out
>> there if you do a little more googling.
>> 
>> On Sat, Feb 13, 2016 at 3:31 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>> 
>>> Thanks guys.
>>> 
>>> Do we have approval to add on the website ?
>>> 
>>> Regards
>>> JB
>>> 
>>> 
>>>> On 02/13/2016 05:49 PM, David Daniel wrote:
>>>> 
>>>> I work on karaf with a number of projects for the US government.  I have
>>>> mentioned it before but here is a link to one that is open source
>>>> https://github.com/codice/ddf  I have also seen a number of other
>>>> products
>>>> that we integrate with starting the migration to karaf such as saiku 4.0
>>>> and pentaho 6.0
>>>> http://wiki.pentaho.com/display/PEOpen/6.0+OSGI+documentation  Our
>>>> company
>>>> has a text analytics/natural language processing and cross document
>>>> correlation product that runs on karaf but I think we may be competitors
>>>> with Benson's company and he is a committer. I have also met a lot of
>>>> redhat people in the DC area that work with karaf/service mix through
>>>> fuse.  My guess is that you will find karaf use is a lot like web forums.
>>>> For every person that comments on karaf in the mailing list there are
>>>> 100's
>>>> who are just lurkers.
>>>> 
>>>> For a short marketing spiel I would go with something along the lines of.
>>>> 
>>>> "Karaf was selected as the server to host a large DOD/Cross Agency
>>>> application that searches and serves terabytes of data to thousands of
>>>> users across the government.  Karaf has undergone rigorous security scans
>>>> such as Fortify, Retna and ACAS all while meeting the performance
>>>> requirements expected of a critical system."
>>>> 
>>>> David
>>>> 
>>>> On Sat, Feb 13, 2016 at 9:04 AM, Serge Huber <shu...@jahia.com> wrote:
>>>> 
>>>> I like the idea too. Let me try for Jahia :
>>>>> 
>>>>> "Jahia uses Apache Karaf in two of its products : Marketing Factory and
>>>>> Digital Experience Manager (DXM). Marketing Factory actually uses Apache
>>>>> Unomi that uses Apache Karaf as its runtime, and DXM uses Apache Karaf as
>>>>> an embedded OSGi runtime inside its JavaEE Web Application. Both systems
>>>>> are commercially available applications that are deployed at large
>>>>> customers throughout the world and rely upon Apache Karaf to deliver
>>>>> high-performance, scalable and highly available solutions”.
>>>>> 
>>>>> How does this read ? Is it acceptable ?
>>>>> 
>>>>> cheers,
>>>>>Serge…
>>>>> 
>>>>> On 13 févr. 2016, at 08:48, Christian Schneider <ch...@die-schneider.net
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> A list of users of karaf would be nice but I think something even better
>>>>> would be to have a short success story for each user.

Re: Known Karaf users

2016-02-13 Thread Serge Huber
Thanks Achim, 

Actually we could do somethink like the Jackrabbit JcrLinks Wiki page : 

http://wiki.apache.org/jackrabbit/JcrLinks#Open_Source_Applications 
<http://wiki.apache.org/jackrabbit/JcrLinks#Open_Source_Applications>

It lists the open source and commercial applications seperately.

cheers,
  Serge… 


> On 10 févr. 2016, at 20:04, Achim Nierbeck <bcanh...@googlemail.com> wrote:
> 
> Hi Serge,
> 
> I know of at least two "companies" though I need to check first if we can
> list them ;)
> Though as Karaf is also the basis for JBoss and Talend based Products they
> most likely have a lot more customers, and I don't know if we can count
> those in. AFAIK our biggest "User" is most likely the OpenDayLight Project.
> Besides that we have a couple other OpenSource Projects based on Karaf.
> 
> I still dream of all those Projects that actually use Karaf to actually
> have the Powered-By-Logo [1] on their site.
> 
> regards, Achim
> 
> [1] - http://www.apache.org/foundation/press/kit/poweredBy/pb-karaf.jpg
> 
> 
> 2016-02-10 19:06 GMT+01:00 Serge Huber <shu...@jahia.com>:
> 
>> Hello,
>> 
>> I just got a question from management about the list of known users of
>> Karaf.
>> I couldn't provide a nice list and his got me thinking about putting some
>> users on the home page and then link to a more complete list.
>> 
>> I can already offer to list my company if that helps :)
>> 
>> Cheers,
>>  Serge
>> 
>> Serge Huber
>> CTO & Co-Founder
>> 
>> T +41 22 361 3424
>> 9 route des Jeunes | 1227 Acacias | Switzerland
>> jahia.com
>> SKYPE | LINKEDIN | TWITTER | VCARD
>> 
>> 
>>> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is
>> a leading User Experience Platform (UXP) for Digital Transformation.
> 
> 
> 
> 
> -- 
> 
> 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: Known Karaf users

2016-02-13 Thread Serge Huber
I like the idea too. Let me try for Jahia : 

"Jahia uses Apache Karaf in two of its products : Marketing Factory and Digital 
Experience Manager (DXM). Marketing Factory actually uses Apache Unomi that 
uses Apache Karaf as its runtime, and DXM uses Apache Karaf as an embedded OSGi 
runtime inside its JavaEE Web Application. Both systems are commercially 
available applications that are deployed at large customers throughout the 
world and rely upon Apache Karaf to deliver high-performance, scalable and 
highly available solutions”.

How does this read ? Is it acceptable ?

cheers,
  Serge… 

> On 13 févr. 2016, at 08:48, Christian Schneider <ch...@die-schneider.net> 
> wrote:
> 
> A list of users of karaf would be nice but I think something even better 
> would be to have a short success story for each user.
> The story could show an overview of the architecture and technologies they 
> use as well as their business case.
> We could then showcase one user in a round robin fashion on the karaf entry 
> page with a short teaser. A click would go to the full story and
> also give links to all the other stories.
> 
> Of course we have to agree on some rules how such a story should look like. 
> So for example maybe we maybe would not want too blatant advertising for the 
> user.
> We might also want to set a limit for the size of the story.
> 
> I could describe what Talend does with Karaf and also ask some users I know 
> for their stories.
> 
> What do you think?
> 
> Christian
> 
> On 10.02.2016 19:06, Serge Huber wrote:
>> Hello,
>> 
>> I just got a question from management about the list of known users of Karaf.
>> I couldn't provide a nice list and his got me thinking about putting some 
>> users on the home page and then link to a more complete list.
>> 
>> I can already offer to list my company if that helps :)
>> 
>> Cheers,
>>   Serge
>> 
>> Serge Huber
>> CTO & Co-Founder
>> 
>> T +41 22 361 3424
>> 9 route des Jeunes | 1227 Acacias | Switzerland
>> jahia.com
>> SKYPE | LINKEDIN | TWITTER | VCARD
>>   
>>> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
>>> leading User Experience Platform (UXP) for Digital Transformation.
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 



Known Karaf users

2016-02-10 Thread Serge Huber
Hello,

I just got a question from management about the list of known users of Karaf.
I couldn't provide a nice list and his got me thinking about putting some users 
on the home page and then link to a more complete list.

I can already offer to list my company if that helps :)

Cheers,
  Serge

Serge Huber
CTO & Co-Founder

T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

Re: [VOTE] Promote the new website look'n feel

2016-01-21 Thread Serge Huber
Sorry that first sentence should have been : "Looks quite good on my iPhone 6 
Plus but strangely not all links are clickable.”

> On 21 janv. 2016, at 15:25, Serge Huber <shu...@jahia.com> wrote:
> 
> Looks quite good on my iPhone 6 Plus but strangely not all links are not 
> clickable.
> 
> For example if I click on Documentation in the top menu and then want to 
> click on Karaf Container 4.x [online] link it doesn’t do anything. Testing 
> this in Safari’s responsive design mode has the same behavior. Not sure 
> what’s going on there.
> 
> Strangely all the links in the top menu always work, but any link in the 
> content doesn’t !
> 
> cheers,
>  Serge… 
> 
>> On 21 janv. 2016, at 14:53, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>> 
>> Hi all,
>> 
>> Morgan helped me to fix the mobile rendering issue.
>> 
>> I updated the website proposal on the same URL:
>> 
>> http://maven.nanthrax.net/goodies/karaf/site/
>> 
>> (NB: don't forget to refresh your browser cache with CTRL-SHIFT-R)
>> 
>> I gonna add couple of missing links, but you can consider this mockup as the 
>> one to vote on.
>> 
>> @Milen: as you voted -1 due to the mobile rendering, can you take a new look 
>> and see if it's OK for you now ?
>> 
>> For the others, don't hesitate to vote (if it's not already done).
>> 
>> Thanks !
>> Regards
>> JB
>> 
>> On 01/19/2016 10:24 AM, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>> 
>>> I extending this vote to 72 more hours in order for me to fix the
>>> rendering on mobile, and add the release schedule information.
>>> 
>>> Thanks,
>>> Regards
>>> JB
>>> 
>>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote:
>>>> Hi all,
>>>> 
>>>> As already discussed on the mailing list, I would like to promote the
>>>> new website.
>>>> 
>>>> As reminder, the new website proposal is there:
>>>> 
>>>> http://maven.nanthrax.net/goodies/karaf/site/
>>>> 
>>>> Please vote to approve the new website:
>>>> 
>>>> [ ] +1 Approve the new website promotion
>>>> [ ] -1 Don't approve the new website (please provide specific comments)
>>>> 
>>>> This vote will be open for at least 72 hours.
>>>> 
>>>> Thanks,
>>>> Regards
>>>> JB
>>> 
>> 
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
> 



Re: [VOTE] Promote the new website look'n feel

2016-01-21 Thread Serge Huber
Looks quite good on my iPhone 6 Plus but strangely not all links are not 
clickable.

For example if I click on Documentation in the top menu and then want to click 
on Karaf Container 4.x [online] link it doesn’t do anything. Testing this in 
Safari’s responsive design mode has the same behavior. Not sure what’s going on 
there.

Strangely all the links in the top menu always work, but any link in the 
content doesn’t !

cheers,
  Serge… 

> On 21 janv. 2016, at 14:53, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> Morgan helped me to fix the mobile rendering issue.
> 
> I updated the website proposal on the same URL:
> 
> http://maven.nanthrax.net/goodies/karaf/site/
> 
> (NB: don't forget to refresh your browser cache with CTRL-SHIFT-R)
> 
> I gonna add couple of missing links, but you can consider this mockup as the 
> one to vote on.
> 
> @Milen: as you voted -1 due to the mobile rendering, can you take a new look 
> and see if it's OK for you now ?
> 
> For the others, don't hesitate to vote (if it's not already done).
> 
> Thanks !
> Regards
> JB
> 
> On 01/19/2016 10:24 AM, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> I extending this vote to 72 more hours in order for me to fix the
>> rendering on mobile, and add the release schedule information.
>> 
>> Thanks,
>> Regards
>> JB
>> 
>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>> 
>>> As already discussed on the mailing list, I would like to promote the
>>> new website.
>>> 
>>> As reminder, the new website proposal is there:
>>> 
>>> http://maven.nanthrax.net/goodies/karaf/site/
>>> 
>>> Please vote to approve the new website:
>>> 
>>> [ ] +1 Approve the new website promotion
>>> [ ] -1 Don't approve the new website (please provide specific comments)
>>> 
>>> This vote will be open for at least 72 hours.
>>> 
>>> Thanks,
>>> Regards
>>> JB
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: [VOTE] Promote the new website look'n feel

2016-01-21 Thread Serge Huber
It works now ! 

Here’s my +1 (again :))

cheers,
  Serge.. 

> On 21 janv. 2016, at 17:14, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi Serge,
> 
> can you try again ?
> 
> Thanks,
> Regards
> JB
> 
> On 01/21/2016 03:25 PM, Serge Huber wrote:
>> Looks quite good on my iPhone 6 Plus but strangely not all links are not 
>> clickable.
>> 
>> For example if I click on Documentation in the top menu and then want to 
>> click on Karaf Container 4.x [online] link it doesn’t do anything. Testing 
>> this in Safari’s responsive design mode has the same behavior. Not sure 
>> what’s going on there.
>> 
>> Strangely all the links in the top menu always work, but any link in the 
>> content doesn’t !
>> 
>> cheers,
>>   Serge…
>> 
>>> On 21 janv. 2016, at 14:53, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> Morgan helped me to fix the mobile rendering issue.
>>> 
>>> I updated the website proposal on the same URL:
>>> 
>>> http://maven.nanthrax.net/goodies/karaf/site/
>>> 
>>> (NB: don't forget to refresh your browser cache with CTRL-SHIFT-R)
>>> 
>>> I gonna add couple of missing links, but you can consider this mockup as 
>>> the one to vote on.
>>> 
>>> @Milen: as you voted -1 due to the mobile rendering, can you take a new 
>>> look and see if it's OK for you now ?
>>> 
>>> For the others, don't hesitate to vote (if it's not already done).
>>> 
>>> Thanks !
>>> Regards
>>> JB
>>> 
>>> On 01/19/2016 10:24 AM, Jean-Baptiste Onofré wrote:
>>>> Hi all,
>>>> 
>>>> I extending this vote to 72 more hours in order for me to fix the
>>>> rendering on mobile, and add the release schedule information.
>>>> 
>>>> Thanks,
>>>> Regards
>>>> JB
>>>> 
>>>> On 01/13/2016 06:58 PM, Jean-Baptiste Onofré wrote:
>>>>> Hi all,
>>>>> 
>>>>> As already discussed on the mailing list, I would like to promote the
>>>>> new website.
>>>>> 
>>>>> As reminder, the new website proposal is there:
>>>>> 
>>>>> http://maven.nanthrax.net/goodies/karaf/site/
>>>>> 
>>>>> Please vote to approve the new website:
>>>>> 
>>>>> [ ] +1 Approve the new website promotion
>>>>> [ ] -1 Don't approve the new website (please provide specific comments)
>>>>> 
>>>>> This vote will be open for at least 72 hours.
>>>>> 
>>>>> Thanks,
>>>>> 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: [RESULT][VOTE] Apache Karaf 4.0.4 release

2016-01-13 Thread Serge Huber
Cool ! Great job JB !

cheers,
  Serge… 


> On 13 janv. 2016, at 18:56, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi all,
> 
> this vote passed with the following result:
> 
> +1 (binding): Achim Nierbeck, Guillaume Nodet, Jean-Baptiste Onofré, Freeman 
> Fang, Jamie Goodyear
> +1 (non binding): Andrea Cosentino, Serge Huber, Andy Schmidt, Roedl Lukas, 
> Fabian Lange, Christian Schneider, Krzysztof Sobkowiak
> 
> I'm promoting the artifacts to Central, update the website, and announce the 
> release.
> 
> Thanks all for your vote.
> 
> Regards
> JB
> 
> On 01/10/2016 06:10 PM, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> I submit Karaf 4.0.4 release to your vote.
>> 
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334047
>> 
>> 
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1054/
>> 
>> Git Tag:
>> karaf-4.0.4
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Thanks,
>> Regards
>> JB
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: [VOTE] Promote the new website look'n feel

2016-01-13 Thread Serge Huber
+1 (non-binding)

cheers,
  Serge… 

> On 13 janv. 2016, at 18:58, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> As already discussed on the mailing list, I would like to promote the new 
> website.
> 
> As reminder, the new website proposal is there:
> 
> http://maven.nanthrax.net/goodies/karaf/site/
> 
> Please vote to approve the new website:
> 
> [ ] +1 Approve the new website promotion
> [ ] -1 Don't approve the new website (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: [VOTE] Apache Karaf 4.0.4 release

2016-01-11 Thread Serge Huber
Yes I do download and test, even the snapshots a lot of the time, but I don’t 
necessarily integrate them into my projects right away because that takes a 
little more time :) 

cheers,
  Serge… 

> On 11 janv. 2016, at 10:04, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi Serge,
> 
> I hope that most of the voters download and test the distribution, also 
> review the "legal" files and release notes ;)
> 
> And of course any vote counts !
> 
> Regards
> JB
> 
> On 01/11/2016 09:57 AM, Serge Huber wrote:
>> +1 (non binding but I wish it would count :))
>> 
>> Btw is there any requirements or expectations on voting ? Should voters 
>> participate in packaging validation or anything else ?
>> 
>> cheers,
>>   Serge..
>> 
>>> On 10 janv. 2016, at 18:10, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I submit Karaf 4.0.4 release to your vote.
>>> 
>>> Release Notes:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334047
>>> 
>>> Staging Repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-1054/
>>> 
>>> Git Tag:
>>> karaf-4.0.4
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>> 
>>> This vote will be open for at least 72 hours.
>>> 
>>> Thanks,
>>> 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: [VOTE] Apache Karaf 4.0.4 release

2016-01-11 Thread Serge Huber
+1 (non binding but I wish it would count :)) 

Btw is there any requirements or expectations on voting ? Should voters 
participate in packaging validation or anything else ?

cheers,
  Serge.. 

> On 10 janv. 2016, at 18:10, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I submit Karaf 4.0.4 release to your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334047
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1054/
> 
> Git Tag:
> karaf-4.0.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: [PROPOSAL] Karaf marketing

2016-01-06 Thread Serge Huber
I really like it but some little details have been bugging me, the line spacing 
of lists. I looked at the CSS and noticed you have a line-height: 20px set that 
seems very weird on the home page. I tested by deactivating it (removing it) 
and it seems the default setting works better on the pages I tested.

It’s really a detail though :) 

I also tried adding a border-radius on the home page titles : 

.homepage-subtitle, .homepage-title {
background: rgba(52,48,45,.8);
color: #f1f1f1;
display: inline-block;
border-radius: 5px;
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
}

I find it a little less rough but again that’s personal preference :) 

cheers,
  Serge… 


> On 6 janv. 2016, at 18:17, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I updated the new website proposal on my server:
> 
> http://maven.nanthrax.net/goodies/karaf/site/
> 
> Please, don't forget to update your browser cache (using CTRL-SHIFT-R on 
> Firefox for instance).
> 
> I would like to start a vote tomorrow, so please, take a tour and send your 
> feedbacks to me.
> 
> Thanks !
> 
> Regards
> JB
> 
> On 11/12/2015 07:54 AM, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> I already discussed with some of you about my plan on Karaf marketing.
>> 
>> I think clearly that we had a great project, a great team, a great tool,
>> but we're not really good in term of promotion and marketing.
>> 
>> Especially, we have to be clear in the message and the projects that we
>> deliver. For instance, again, I'm sure that karaf-boot is a huge step
>> forward in Karaf adoption. I'm not sure that all users are aware and
>> know the purpose of Cellar, Cave, Decanter, and even some Karaf areas.
>> 
>> In order to improve the Karaf marketing area, I would like to propose
>> the following plan:
>> 
>> 1. More professional website
>> I think we have to improve both the content and the look'n feel of the
>> website.
>> In term of content, I think it makes sense to not emphasize on OSGi. The
>> fact that Karaf runs OSGi is not really interesting for most of end
>> users (of course, it is for advanced/power users). We have to explain
>> that Karaf is modern and multi-purpose container. More over, with
>> karaf-boot, it becomes also a bootstrapper and "run anywhere" paradigm
>> platform.
>> So, I started a new website, changing the look'n feel (to give a more
>> professional shape) and the content (changing the marketing message):
>> 
>> http://maven.nanthrax.net/goodies/karaf/site/
>> 
>> I will complete the website today (some cleanup, other pages than the
>> home one, etc), but it already gives you an idea.
>> 
>> 2. New guides/documentation
>> I'm working on the improvement in term of content of the documentation.
>> Especially, the dev guide will be more straight forward, providing
>> recipes for users.
>> All guides will use asciidoc now. You can already see the kind of output
>> on the Decanter guide:
>> 
>> http://karaf.apache.org/manual/decanter/latest-1/index.html
>> 
>> All Karaf guides (and subprojects) will be rendered in a popup using
>> such look'n feel.
>> 
>> 3. Meetups
>> I plan to organize a Karaf Meetup beginning of 2016. I have some
>> sponsors in mind. The purpose is to meet most of Karaf users, devs, and
>> enthusiasts.
>> I will give you more details soon.
>> 
>> Thoughts ?
>> 
>> Regards
>> JB
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: Happy New Year !

2016-01-01 Thread Serge Huber
Happy new year too ! This is where I'm writing this from :)



Cheers,

Serge Huber
CTO & Co-Founder

T +41 22 361 3424
9 route des Jeunes | 1227 Acacias | Switzerland
jahia.com
SKYPE | LINKEDIN | TWITTER | VCARD
  

> JOIN OUR COMMUNITY to evaluate, get trained and to discover why Jahia is a 
> leading User Experience Platform (UXP) for Digital Transformation.

> Le 1 janv. 2016 à 06:24, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit :
> 
> On behalf of the Karaf team, I wish you a happy new year !
> 
> I hope this new year will bring all that you expect.
> 
> For sure, 2016 will be an important year for Karaf in term of increasing the 
> adoption. New website, new samples, new documentation, and Karaf Boot are 
> keys to step forward in 2016 to bring Karaf in new areas !
> 
> So, keep using, loving, helping, contributing on Karaf !
> 
> 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

2015-12-17 Thread 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=http%3a%2f%2fwww.liquid-reality.de
>>> Open Source Architect
>>> http://www.talend.com
>>> <
>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com
>> 
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> 
> Open Source Architect
> http://www.talend.com 


Re: [HEADS UP] Marketing and releases schedule

2015-12-17 Thread 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 

Re: [PROPOSAL] Karaf marketing

2015-12-02 Thread Serge Huber
Love the new project, especially the new messaging that makes it a lot clearer. 

The projects part is fantastic in terms of message but I think it needs a 
little improvements because the bullets look weird. Maybe just remove the 
bullets ? 

Also it would be great to have a “videos” section if there are any recorded 
sessions of Karaf talks. Or at the least slidedecks. What do you think about 
that ?

I also noticed Karaf Boot is already in there, cool !

cheers,
  Serge… 


> On 1 déc. 2015, at 16:39, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I updated the website proposal:
> 
> http://maven.nanthrax.net/goodies/karaf/site/
> 
> (don't forget to reload the page cache with CTRL-R for instance).
> 
> I added most of the pages (I have to clean up some links), the news sliders, 
> etc.
> 
> Now, I'm working on:
> 1. migrating the documentation to asciidoc (like the decanter one)
> 2. revamping of the dev guide to be more "recipes oriented", with samples 
> embedded in the distribution
> 
> Regarding the website, please, don't hesitate to share your comments (on IRC, 
> Skype, mail, or mailing list), I will integrate it.
> 
> I would like to promote this new "marketing" material soon.
> 
> Thanks,
> Regards
> JB
> 
> On 11/12/2015 07:54 AM, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> I already discussed with some of you about my plan on Karaf marketing.
>> 
>> I think clearly that we had a great project, a great team, a great tool,
>> but we're not really good in term of promotion and marketing.
>> 
>> Especially, we have to be clear in the message and the projects that we
>> deliver. For instance, again, I'm sure that karaf-boot is a huge step
>> forward in Karaf adoption. I'm not sure that all users are aware and
>> know the purpose of Cellar, Cave, Decanter, and even some Karaf areas.
>> 
>> In order to improve the Karaf marketing area, I would like to propose
>> the following plan:
>> 
>> 1. More professional website
>> I think we have to improve both the content and the look'n feel of the
>> website.
>> In term of content, I think it makes sense to not emphasize on OSGi. The
>> fact that Karaf runs OSGi is not really interesting for most of end
>> users (of course, it is for advanced/power users). We have to explain
>> that Karaf is modern and multi-purpose container. More over, with
>> karaf-boot, it becomes also a bootstrapper and "run anywhere" paradigm
>> platform.
>> So, I started a new website, changing the look'n feel (to give a more
>> professional shape) and the content (changing the marketing message):
>> 
>> http://maven.nanthrax.net/goodies/karaf/site/
>> 
>> I will complete the website today (some cleanup, other pages than the
>> home one, etc), but it already gives you an idea.
>> 
>> 2. New guides/documentation
>> I'm working on the improvement in term of content of the documentation.
>> Especially, the dev guide will be more straight forward, providing
>> recipes for users.
>> All guides will use asciidoc now. You can already see the kind of output
>> on the Decanter guide:
>> 
>> http://karaf.apache.org/manual/decanter/latest-1/index.html
>> 
>> All Karaf guides (and subprojects) will be rendered in a popup using
>> such look'n feel.
>> 
>> 3. Meetups
>> I plan to organize a Karaf Meetup beginning of 2016. I have some
>> sponsors in mind. The purpose is to meet most of Karaf users, devs, and
>> enthusiasts.
>> I will give you more details soon.
>> 
>> 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

2015-11-25 Thread Serge Huber
Hello JB, 

I was actually thinking about this this morning too. The website seems more and 
more “critical” I believe to make Karaf appear as a modern “container” 
solution. It would actually be great to have a “roadmap” page that summarizes 
the ideas for the future of Karaf. I was thinking about doing this for the 
Unomi website too. In the roadmap of course Karaf-boot could be referenced and 
even the tentative code could be referenced, making it much more visible.

For karaf-boot I think it would be great to move it to the Karaf repository 
asap, that way it will be more visible. Also I need to play with it to 
understand what you have done so far.

On my way in to the office I was thinking that we should “leverage” existing 
technologies out there for Karaf boot. Much in the same way that projects like 
JHipster (https://jhipster.github.io) do it, it would be fantastic for example 
if JHipster offered a Karaf alternative to Spring-Boot. Also, maybe we could 
find a way to leverage Spring Boot by offering Karaf Features that embed most 
of the Spring libraries so that we could then say, instead of using Spring Boot 
and create yet-another-monolith, you could instead use Karaf Boot and the 
Spring features and easily create a custom distribution that provides any of 
the features listed here : 
https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples

My thinking is that if this is done right we might even convince Pivotal to use 
Karaf instead of their own custom container, which would make sense for them 
too since they are basically (slowly) re-inventing Karaf for their needs.

If we can streamline Karaf boot enough, it has (I believe) a huge potential. 
And I volunteer to do all the work to try to get Pivotal on board once we have 
something very smooth :) 

I’ll do my best to help out in my limited availability.

cheers,
  Serge… 

> On 25 nov. 2015, at 09:13, Achim Nierbeck  wrote:
> 
> Hi JB,
> 
> looks good for me ... especially the move of karaf-boot to apache sounds ok
> for me ...
> it'll will get a broader visibility this way ;)
> 
> regards, Achim
> 
> 2015-11-25 9:09 GMT+01:00 Jean-Baptiste Onofré :
> 
>> 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
>> 
> 
> 
> 
> -- 
> 
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
> 
> Software Architect / Project Manager / Scrum Master



Re: KARAF-2734

2015-11-18 Thread Serge Huber
What about the LGPL stuff, is that a potential problem ?

cheers,
  Serge… 


> On 18 nov. 2015, at 11:51, Jean-Baptiste Onofré  wrote:
> 
> Hi Luca,
> 
> good idea, YAJSW sounds like a good alternative, compliant with Apache 
> license. I worked on an alternative using commons-daemon, but the scope is a 
> bit different.
> 
> Do you already have a patch or do you want I take a look on it ?
> 
> Regards
> JB
> 
> On 11/18/2015 11:47 AM, lb wrote:
>> Hi all,
>> 
>> I'm investigating KARAF-2734 as I'm looking for alternatives to Tanuki JSW
>> to install Karaf as a service so I did a little bit of investigation about
>> YAJSW (http://yajsw.sourceforge.net/) as it claims to be functional and
>> configuration compatible for Tanuki JSW, here my initial findings:
>> 
>> - hosted on sourceforge
>> - uses JNA for OS interactions
>> - provides Java API for embed it
>> - latest version not on maven central etc (asked on sourceforge forum)
>> - some code is still licensed as LGPL (asked on sourceforge forum)
>> - some source code from external dependencies is also in the repository so
>> some classes seem to be duplicated
>> - depends on some not release dependencies (i.e. commons-cli 2)
>> - requires the YAJSW distribution to be provided as the wrapper search for
>> libraries in specific paths (asked on sourceforge if an uber jar can be
>> made)
>> 
>> About the lates point, the wrapper entry point is in wrapper.jar which then
>> loads all the dependencies it needs according to the information included
>> in MANIFEST, i.e. core libraries are defined by the entry
>> Class-Path-Wrapper-Core :
>> 
>> Class-Path-Wrapper-Core: ./wrapperApp.jar ./lib/core/yajsw/ahessian.ja
>>  r ./lib/core/netty/netty-all-4.0.28.Final.jar ./lib/core/jna/jna-4.1.
>>  0.jar ./lib/core/jna/jna-platform-4.1.0.jar ./lib/core/commons/common
>>  s-configuration-1.10.jar ./lib/core/commons/commons-vfs2-2.0.jar ./li
>>  b/core/commons/commons-collections-3.2.1.jar ./lib/core/commons/commo
>>  ns-io-1.3.1.jar ./lib/core/commons/commons-lang-2.4.jar ./lib/core/co
>>  mmons/commons-logging-1.1.jar ./lib/core/commons/commons-cli-2-SNAPSH
>>  OT.jar
>> 
>> 
>> This means that to be included in Karaf the structure of YAJSW distribution
>> has to be replicated somehow or the wrapper.jar has to be manipulated to
>> point to jars in system folder.
>> 
>> 
>> What do you think ?
>> 
>> 
>> Regads,
>> Luca
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
> 
> 3.
> Meetups would be really great. I think we should also try to get some people 
> from Eclipse and the OSGi alliance to join us. We really need to work on 
> converging these communities.
> Do you already have an idea about a good place to meet?

This is a great idea, getting the Eclipse and OSGi alliance communities 
on-board and learning about Karaf would be great for everyone. This might also 
be a way to convince my company to chip in (can’t promise anything at this 
point though).

cheers,
  Serge… 



Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
Actually I wasn’t talking about the Spring Framework, for which I see no use 
inside of Karaf, quite the opposite :) 

I was merely talking about all the other libraries that they offer here : 
http://spring.io/projects

At my company we get the request almost daily on how to integrate these (or 
others) with OSGi bundles. People are ready to try, but they get easily scared 
when they can’t get it to work. And usually it’s not that difficult but it’s 
beyond their current experience level.

cheers,
  Serge… 

> On 12 nov. 2015, at 11:00, Christian Schneider <ch...@die-schneider.net> 
> wrote:
> 
> I also think that using spring is not such a good idea in OSGi. You are right 
> that it offers a lot of stuff that people want to reuse but I think the 
> problems would outweigh the benefits.
> 
> So I think the better way is to show how to do enterprise development in a 
> clean OSGi ready way and show the migration path.
> 
> I have started this with a tutorial about using CDI/JEE annotations for 
> blueprint:
> http://www.liquid-reality.de/x/C4DK
> 
> It leverages the fact that most people use spring with annotations today. So 
> the actual spring part can be quite small if you do it well. So if you use 
> the CDI and JEE annoations in spring it is quite easy to migrate to blueprint.
> The example uses the aries blueprint-maven-plugin. It allows to just continue 
> using the standard annotations that also work in spring.
> 
> I did a migration from spring to OSGi and blueprint for a customer some 
> months ago and the plugin made this so much easier. So I could create another 
> tutorial that shows how to actually migrate from spring to blueprint in some 
> steps. It is still not a trivial task but I think the result can be a better 
> application than using spring dm in OSGi.
> 
> Christian
> 
> On 12.11.2015 10:42, Serge Huber wrote:
>> I agree with you Achim but I was mostly proposing that because basically 
>> lots of developers want to use Spring librairies to avoid writing code 
>> themselves. So unless we can provide a replacement for all they are building 
>> I think we should have some kind of way of helping them get bootstrapped.
>> 
>> Maybe this could be a seperate project outside of Karaf ?
>> 
>> In the meantime I keep trying to convince the Pivotal guys every chance I 
>> get to see the light and come back to OSGi and embrace Karaf :)
>> 
>> cheers,
>>   Serge…
>> 
>>> On 12 nov. 2015, at 10:40, Achim Nierbeck <bcanh...@googlemail.com> wrote:
>>> 
>>> Hi Serge,
>>> 
>>> one note about the spring idea ...
>>> right now spring isn't a nice osgi citizen anymore.
>>> So I fear Karaf will get blamed for Spring issues around Spring running
>>> inside OSGi.
>>> That's why I would keep away from that.
>>> 
>>> regards, Achim
>>> 
>>> 
>>> 2015-11-12 10:32 GMT+01:00 Serge Huber <shu...@jahia.com>:
>>> 
>>>> Hello,
>>>> 
>>>>> On 12 nov. 2015, at 07:54, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I already discussed with some of you about my plan on Karaf marketing.
>>>>> 
>>>>> I think clearly that we had a great project, a great team, a great tool,
>>>> but we're not really good in term of promotion and marketing.
>>>> 
>>>> Yes Karaf is clearly one of the hidden gems of the ASF, and if marketing
>>>> it properly can make it more visible and people understand it’s value
>>>> better, everybody wins.
>>>> 
>>>>> Especially, we have to be clear in the message and the projects that we
>>>> deliver. For instance, again, I'm sure that karaf-boot is a huge step
>>>> forward in Karaf adoption. I'm not sure that all users are aware and know
>>>> the purpose of Cellar, Cave, Decanter, and even some Karaf areas.
>>>> 
>>>> Yes, and at the same time positioning Karaf as compatible with lots of
>>>> technologies would help. For example tell everyone that they can realize
>>>> their projects in Karaf that use Spring technologies would be helpful, not
>>>> making them have to choose between Karaf or Spring, but rather just use
>>>> Karaf as the runtime and build on top of it using Spring librairies. Of
>>>> course this requires that we provide features for all of these.
>>>> 
>>>>> In order to improve the Karaf marketing area, I would like to propose
>>>> the following plan:
>>>>&

Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
I’m sorry I didn’t express my ideas clearly about Spring, what I meant to say 
was provide some quick getting started resources so that if someone wants to 
use Spring-Data, Spring Social, Spring-XD and so forth they don’t have to do 
all the integrating themselves. 

So maybe it could be really cool to start some kind of archetype repository 
that the community could easily contribute to so that you could then simple 
create a project with the appropriate Spring artifacts already embedded. And of 
course this could be done for anything. This would probably greatly ease OSGi’s 
main pain point of getting the Import-Package statement right.

I believe I even so a project related to this at Eclipse, but I can’t remember 
it right now.

cheers,
  Serge… 

> On 12 nov. 2015, at 10:43, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi Serge,
> 
> thanks for the update !
> 
> Honestly, I'm not sure at all about Spring, as they don't support OSGI 
> anymore, so not easy.
> 
> For Jigsaw, good idea ;)
> 
> Regards
> JB
> 
> On 11/12/2015 10:32 AM, Serge Huber wrote:
>> Hello,
>> 
>>> On 12 nov. 2015, at 07:54, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I already discussed with some of you about my plan on Karaf marketing.
>>> 
>>> I think clearly that we had a great project, a great team, a great tool, 
>>> but we're not really good in term of promotion and marketing.
>> 
>> Yes Karaf is clearly one of the hidden gems of the ASF, and if marketing it 
>> properly can make it more visible and people understand it’s value better, 
>> everybody wins.
>> 
>>> 
>>> Especially, we have to be clear in the message and the projects that we 
>>> deliver. For instance, again, I'm sure that karaf-boot is a huge step 
>>> forward in Karaf adoption. I'm not sure that all users are aware and know 
>>> the purpose of Cellar, Cave, Decanter, and even some Karaf areas.
>> 
>> Yes, and at the same time positioning Karaf as compatible with lots of 
>> technologies would help. For example tell everyone that they can realize 
>> their projects in Karaf that use Spring technologies would be helpful, not 
>> making them have to choose between Karaf or Spring, but rather just use 
>> Karaf as the runtime and build on top of it using Spring librairies. Of 
>> course this requires that we provide features for all of these.
>> 
>>> 
>>> In order to improve the Karaf marketing area, I would like to propose the 
>>> following plan:
>>> 
>>> 1. More professional website
>>> I think we have to improve both the content and the look'n feel of the 
>>> website.
>>> In term of content, I think it makes sense to not emphasize on OSGi. The 
>>> fact that Karaf runs OSGi is not really interesting for most of end users 
>>> (of course, it is for advanced/power users). We have to explain that Karaf 
>>> is modern and multi-purpose container. More over, with karaf-boot, it 
>>> becomes also a bootstrapper and "run anywhere" paradigm platform.
>>> So, I started a new website, changing the look'n feel (to give a more 
>>> professional shape) and the content (changing the marketing message):
>>> 
>>> http://maven.nanthrax.net/goodies/karaf/site/
>> 
>> Looks really good, there are a few images that have resizing issues but 
>> that’s a detail. One message I also repeat often about Karaf is that it’s 
>> the basic runtime you would end up with if you started a project from 
>> scratch, so why not use that as a start instead of re-implementing it.
>> 
>> Also, at JavaOne Oracle was talking about Jigsaw a lot, so maybe we can 
>> capitalize on this by saying that this is a module system that is proven and 
>> future-ready. I like the enterprise positioning, clearly in opposition of 
>> not-yet-ready-for-production platforms such as docker or in some regards 
>> Spring-boot :)
>> 
>>> 
>>> I will complete the website today (some cleanup, other pages than the home 
>>> one, etc), but it already gives you an idea.
>>> 
>>> 2. New guides/documentation
>>> I'm working on the improvement in term of content of the documentation. 
>>> Especially, the dev guide will be more straight forward, providing recipes 
>>> for users.
>>> All guides will use asciidoc now. You can already see the kind of output on 
>>> the Decanter guide:
>>> 
>>> http://karaf.apache.org/manual/decanter/latest-1/index.html
>>> 
>>> All Karaf guides

Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
Hello,

> On 12 nov. 2015, at 07:54, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I already discussed with some of you about my plan on Karaf marketing.
> 
> I think clearly that we had a great project, a great team, a great tool, but 
> we're not really good in term of promotion and marketing.

Yes Karaf is clearly one of the hidden gems of the ASF, and if marketing it 
properly can make it more visible and people understand it’s value better, 
everybody wins.

> 
> Especially, we have to be clear in the message and the projects that we 
> deliver. For instance, again, I'm sure that karaf-boot is a huge step forward 
> in Karaf adoption. I'm not sure that all users are aware and know the purpose 
> of Cellar, Cave, Decanter, and even some Karaf areas.

Yes, and at the same time positioning Karaf as compatible with lots of 
technologies would help. For example tell everyone that they can realize their 
projects in Karaf that use Spring technologies would be helpful, not making 
them have to choose between Karaf or Spring, but rather just use Karaf as the 
runtime and build on top of it using Spring librairies. Of course this requires 
that we provide features for all of these.

> 
> In order to improve the Karaf marketing area, I would like to propose the 
> following plan:
> 
> 1. More professional website
> I think we have to improve both the content and the look'n feel of the 
> website.
> In term of content, I think it makes sense to not emphasize on OSGi. The fact 
> that Karaf runs OSGi is not really interesting for most of end users (of 
> course, it is for advanced/power users). We have to explain that Karaf is 
> modern and multi-purpose container. More over, with karaf-boot, it becomes 
> also a bootstrapper and "run anywhere" paradigm platform.
> So, I started a new website, changing the look'n feel (to give a more 
> professional shape) and the content (changing the marketing message):
> 
>   http://maven.nanthrax.net/goodies/karaf/site/

Looks really good, there are a few images that have resizing issues but that’s 
a detail. One message I also repeat often about Karaf is that it’s the basic 
runtime you would end up with if you started a project from scratch, so why not 
use that as a start instead of re-implementing it. 

Also, at JavaOne Oracle was talking about Jigsaw a lot, so maybe we can 
capitalize on this by saying that this is a module system that is proven and 
future-ready. I like the enterprise positioning, clearly in opposition of 
not-yet-ready-for-production platforms such as docker or in some regards 
Spring-boot :)

> 
> I will complete the website today (some cleanup, other pages than the home 
> one, etc), but it already gives you an idea.
> 
> 2. New guides/documentation
> I'm working on the improvement in term of content of the documentation. 
> Especially, the dev guide will be more straight forward, providing recipes 
> for users.
> All guides will use asciidoc now. You can already see the kind of output on 
> the Decanter guide:
> 
>   http://karaf.apache.org/manual/decanter/latest-1/index.html
> 
> All Karaf guides (and subprojects) will be rendered in a popup using such 
> look'n feel.

Looks good but it would be fantastic if it was also responsive so that it can 
be used on tablets and or phablets :) 

> 
> 3. Meetups
> I plan to organize a Karaf Meetup beginning of 2016. I have some sponsors in 
> mind. The purpose is to meet most of Karaf users, devs, and enthusiasts.
> I will give you more details soon.

Sounds fantastic. If you need help with the sponsoring I could try to talk to 
people here.

> 
> Thoughts ?

Love the approach, the old website really needed revamping, and this is 
definitely a great step forward ! 

cheers,
  Serge… 

Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
I agree with you Achim but I was mostly proposing that because basically lots 
of developers want to use Spring librairies to avoid writing code themselves. 
So unless we can provide a replacement for all they are building I think we 
should have some kind of way of helping them get bootstrapped. 

Maybe this could be a seperate project outside of Karaf ? 

In the meantime I keep trying to convince the Pivotal guys every chance I get 
to see the light and come back to OSGi and embrace Karaf :) 

cheers,
  Serge… 

> On 12 nov. 2015, at 10:40, Achim Nierbeck <bcanh...@googlemail.com> wrote:
> 
> Hi Serge,
> 
> one note about the spring idea ...
> right now spring isn't a nice osgi citizen anymore.
> So I fear Karaf will get blamed for Spring issues around Spring running
> inside OSGi.
> That's why I would keep away from that.
> 
> regards, Achim
> 
> 
> 2015-11-12 10:32 GMT+01:00 Serge Huber <shu...@jahia.com>:
> 
>> Hello,
>> 
>>> On 12 nov. 2015, at 07:54, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I already discussed with some of you about my plan on Karaf marketing.
>>> 
>>> I think clearly that we had a great project, a great team, a great tool,
>> but we're not really good in term of promotion and marketing.
>> 
>> Yes Karaf is clearly one of the hidden gems of the ASF, and if marketing
>> it properly can make it more visible and people understand it’s value
>> better, everybody wins.
>> 
>>> 
>>> Especially, we have to be clear in the message and the projects that we
>> deliver. For instance, again, I'm sure that karaf-boot is a huge step
>> forward in Karaf adoption. I'm not sure that all users are aware and know
>> the purpose of Cellar, Cave, Decanter, and even some Karaf areas.
>> 
>> Yes, and at the same time positioning Karaf as compatible with lots of
>> technologies would help. For example tell everyone that they can realize
>> their projects in Karaf that use Spring technologies would be helpful, not
>> making them have to choose between Karaf or Spring, but rather just use
>> Karaf as the runtime and build on top of it using Spring librairies. Of
>> course this requires that we provide features for all of these.
>> 
>>> 
>>> In order to improve the Karaf marketing area, I would like to propose
>> the following plan:
>>> 
>>> 1. More professional website
>>> I think we have to improve both the content and the look'n feel of the
>> website.
>>> In term of content, I think it makes sense to not emphasize on OSGi. The
>> fact that Karaf runs OSGi is not really interesting for most of end users
>> (of course, it is for advanced/power users). We have to explain that Karaf
>> is modern and multi-purpose container. More over, with karaf-boot, it
>> becomes also a bootstrapper and "run anywhere" paradigm platform.
>>> So, I started a new website, changing the look'n feel (to give a more
>> professional shape) and the content (changing the marketing message):
>>> 
>>>  http://maven.nanthrax.net/goodies/karaf/site/
>> 
>> Looks really good, there are a few images that have resizing issues but
>> that’s a detail. One message I also repeat often about Karaf is that it’s
>> the basic runtime you would end up with if you started a project from
>> scratch, so why not use that as a start instead of re-implementing it.
>> 
>> Also, at JavaOne Oracle was talking about Jigsaw a lot, so maybe we can
>> capitalize on this by saying that this is a module system that is proven
>> and future-ready. I like the enterprise positioning, clearly in opposition
>> of not-yet-ready-for-production platforms such as docker or in some regards
>> Spring-boot :)
>> 
>>> 
>>> I will complete the website today (some cleanup, other pages than the
>> home one, etc), but it already gives you an idea.
>>> 
>>> 2. New guides/documentation
>>> I'm working on the improvement in term of content of the documentation.
>> Especially, the dev guide will be more straight forward, providing recipes
>> for users.
>>> All guides will use asciidoc now. You can already see the kind of output
>> on the Decanter guide:
>>> 
>>>  http://karaf.apache.org/manual/decanter/latest-1/index.html
>>> 
>>> All Karaf guides (and subprojects) will be rendered in a popup using
>> such look'n feel.
>> 
>> Looks good but it would be fantastic if it was also responsive so that it
>> can be used on tablets and or phablets :)
>&

Re: [PROPOSAL] Karaf marketing

2015-11-12 Thread Serge Huber
Actually I have been working on an improved Felix Maven plugin that tries to do 
a lot more scanning to improve the generation of Import-Packages, but for the 
moment it’s embedded in the same plugin as our corporate Maven plugin. I would 
need to look at extracting it to make it more generic and therefore re-usable. 

Oh I found the project I was thinking about : 
http://www.eclipse.org/proposals/rt.ebr/

with the templates here : 
https://github.com/glyn/bundlerepo/tree/master/templates

Unfortunately it is not very active since Spring dropped it.

cheers,
  Serge… 

> On 12 nov. 2015, at 11:07, Christian Schneider <ch...@die-schneider.net> 
> wrote:
> 
> That might be interesting. Perhaps you can provide some examples what could 
> be useful in karaf in form of blog posts or similar.
> 
> The problem though is that the spring people do not really support OSGi. So 
> while we might get it working it could break with any new version.
> 
> Christian
> 
> On 12.11.2015 11:04, Serge Huber wrote:
>> Actually I wasn’t talking about the Spring Framework, for which I see no use 
>> inside of Karaf, quite the opposite :)
>> 
>> I was merely talking about all the other libraries that they offer here : 
>> http://spring.io/projects
>> 
>> At my company we get the request almost daily on how to integrate these (or 
>> others) with OSGi bundles. People are ready to try, but they get easily 
>> scared when they can’t get it to work. And usually it’s not that difficult 
>> but it’s beyond their current experience level.
>> 
>> cheers,
>>   Serge…
>> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 



Re: [DISCUSSION] Karaf docker.io

2015-10-15 Thread Serge Huber
I love it ! Is it production ready ?… uh wait docker is not :) 

More seriously, between this and karaf-boot I think that the story in terms of 
starting to deploying a project can really be improved greatly. We could then 
even push the docker images to a docker repository.

That way you can launch Docker Unomi instances in a large cluster with just a 
few CLI instructions :) 

cheers,
  Serge… 

> On 15 oct. 2015, at 14:09, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> let me "relaunch" this very old thread ;)
> 
> Even if most of us already use docker to run Karaf, I think that karaf-docker 
> could be a key and very interesting combination with karaf-boot.
> 
> Imagine the following scenario:
> - you construct your application thanks to karaf-boot (and the different 
> starters, karaf-boot-maven-plugin, etc)
> - using your codebase, and the different starters that you use, the 
> karaf-boot-maven-plugin creates a Karaf custom distribution for you
> - now, you can directly start your Karaf custom distribution on your 
> machines, your cloud, or docker: it's where karaf-docker can help.
> In addition of the Karaf custom distribution, karaf-docker (and so the 
> karaf-docker-plugin that could be part of karaf-boot) can provide a ready to 
> run docker image with your custom Karaf distribution: you don't have to 
> prepare anything, the dockerfile, or whatever, it will be done for you.
> 
> Of course, we keep the current features part of karaf-docker (the fact to 
> manage docker images directly in Karaf). I would like to add a new set of 
> features in karaf-docker: be able to create "business oriented" Karaf (based 
> on the first point). For instance, you want a Karaf WebContainer, Karaf 
> Hibernate, just use docker:create command to create a custom Karaf 
> distribution in a docker image, this distribution will have 
> "pre-installed/bootFeatures" as you described in the shell command.
> 
> Basically, karaf-boot and karaf-docker are in the same boat to provide more 
> user experience, flexible systems (profiles oriented) and killer services 
> platform.
> 
> I know that it's ambitious, but I trust in you all guys to help and drive 
> Karaf to a new dimension.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> On 02/11/2015 08:43 PM, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> In order to provide an alternative to the instances, I started to work
>> on a small PoC providing simple and convenient docker.io support in Karaf.
>> 
>> The purpose is to easily manage images, containers, and be able to
>> provision/create container with Karaf instances.
>> 
>> For instance, this is a current available use case:
>> 
>> 1/ You can create a docker.io container in two ways:
>> 1.1/ karaf@root()> docker:bootstrap mydock
>> creates a fresh docker.io container using karaf:3.0.3 image. I prepared
>> different ready to use docker.io images for Karaf. I'm working on an
>> embedded docker hub, with the appropriate commands to administrate it.
>> 1.2/ karaf@root()> docker:provision mydock
>> creates a docker.io container (using a karaf image) and copy the current
>> running instance in the dock.
>> 1.3/ It's also possible to start from a dockerfile.
>> 2/ Once the dock (I named it dock meaning docker.io container where a
>> karaf instance is living) is ready, you can control it using
>> docker:start, docker:stop, docker:delete commands.
>> 3/ it's possible to connect to a running dock using docker:connect command
>> 
>> I'm working on docker:image*, docker:hub, and improve the existing
>> docker* features.
>> 
>> However, before moving forward on this, I would like to know if it makes
>> sense and if people are interested by it.
>> 
>> By the way, the code is on my github:
>> http://github.com/jbonofre/karaf-docker.
>> 
>> I will push my last changes tomorrow morning.
>> 
>> Any comment is welcome.
>> 
>> Thanks,
>> Regards
>> JB
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com