Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-10 Thread Jean-Baptiste Onofré
IMHO, Camel is slightly different as camel repo is used by camel-k,
camel-quarkus (it's kind of core/common lib).

However, we have a consensus: we don't rename karaf, we just rework
the website to give space to all projects.

If there is no objection, I will start a formal vote tomorrow with:
- create karaf-minho repo
- donate code from my github here
- rework the website

I will start to rename all on my github to use org.apache.karaf.minsho space.

Regards
JB

On Mon, Oct 10, 2022 at 8:15 AM Grzegorz Grzybek  wrote:
>
> Hello (also a bit late)
>
> niedz., 9 paź 2022 o 12:46 Achim Nierbeck 
> napisał(a):
>
> > a bit late to the party, nevertheless I'm also in favor of making it
> > crystal clear that Karaf is for OSGi and Karaf Minho is the new kid in
> > town.
> >
>
> I agree. Same as with Camel - there's "Camel", "Camel-K" and
> "Camel-Quarkus". Original Camel wasn't renamed ;)
>
> regards
> Grzegorz Grzybek
>
>
> > besides that I'm also in favor of accepting this new runtime into the karaf
> > community.
> >
> > regards, Achim
> >
> > Am So., 9. Okt. 2022 um 09:13 Uhr schrieb 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...?)
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf  Committer & PMC
> > OPS4J Pax Web  Committer &
> > Project Lead
> > blog 
> > Co-Author of Apache Karaf Cookbook 
> >


Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-10 Thread Grzegorz Grzybek
Hello (also a bit late)

niedz., 9 paź 2022 o 12:46 Achim Nierbeck 
napisał(a):

> a bit late to the party, nevertheless I'm also in favor of making it
> crystal clear that Karaf is for OSGi and Karaf Minho is the new kid in
> town.
>

I agree. Same as with Camel - there's "Camel", "Camel-K" and
"Camel-Quarkus". Original Camel wasn't renamed ;)

regards
Grzegorz Grzybek


> besides that I'm also in favor of accepting this new runtime into the karaf
> community.
>
> regards, Achim
>
> Am So., 9. Okt. 2022 um 09:13 Uhr schrieb 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...?)
> > > >
> > >
> >
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>


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-08 Thread Jean-Baptiste Onofré
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-08 Thread Steinar Bang
> 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-08 Thread Eric Lilja
On Sat, Oct 8, 2022 at 3:46 PM Steinar Bang  wrote:

> > Łukasz Dywicki :
>
> > Why rename karaf if it is what it was since begining?
>
> I agree!
>
>

Because it's shedding its OSGi core, making it optional. It's a different
product stack.

- Eric L


Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-08 Thread Steinar Bang
> Łukasz Dywicki :

> Why rename karaf if it is what it was since begining?

I agree!



Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-08 Thread Francois Papon

Sounds good

On 08/10/2022 07:43, Jean-Baptiste Onofré wrote:

Just to be clear, my proposal is:

1. We keep all artifacts as they are today, no renaming, we keep the
same code repo, etc
2. On Jira, the karaf component will be renamed to osgi (as we have
decanter, cellar, etc)
3. On the website, Karaf "runtime" is already presented as a
subproject (karaf.apache.org), same level as Cellar, Decanter, etc.
So, Karaf "runtime" will appear as Karaf "OSGi" on the runtime, no big
change.
4. We will have then Karaf "Minho" as new subproject, presented as
Modulith Runtime

Thoughts ?

Regards
JB

On Sat, Oct 8, 2022 at 6:12 AM Jean-Baptiste Onofré  wrote:

OK, so let's focus on "K5" name.

Actually, I wanted the opposite and give a chance for any subproject:
for most people karaf == the runtime (they don't necessarily see
winegrower, decanter, etc.

But OK, let's keep the Karaf name and use a new subproject name.

Maybe we can use just a tag name: no rename, but on the website use
Karaf (OSGi) to clearly stand it's the OSGi runtime.

Regards
JB

On Fri, Oct 7, 2022 at 9:09 PM Łukasz Dywicki  wrote:

Why rename karaf if it is what it was since begining?
Karaf is with us since more than decade changing names is not going to help it. 
More over it will definitely confuse people and users as we do not have a 
communication channel to all of them other than this mailing list and website.
We had multiple subprojects under Karaf till now. New runtime is yet another 
subproject. If it will evolve into something larger it can become its own TLP 
just like Karaf did back after leaving ServiceMix core and Felix.
For now we dont know how it will grow hence I would abstain from making any 
changes to primary project/use.

Best
Łukasz Dywicki
--
Code-House
http://code-house.org


On 7 Oct 2022, at 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

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 <

l...@code-house.org>

wrote:

Hello,
Looking forward towards donation of it as a subproject with 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
Just to be clear, my proposal is:

1. We keep all artifacts as they are today, no renaming, we keep the
same code repo, etc
2. On Jira, the karaf component will be renamed to osgi (as we have
decanter, cellar, etc)
3. On the website, Karaf "runtime" is already presented as a
subproject (karaf.apache.org), same level as Cellar, Decanter, etc.
So, Karaf "runtime" will appear as Karaf "OSGi" on the runtime, no big
change.
4. We will have then Karaf "Minho" as new subproject, presented as
Modulith Runtime

Thoughts ?

Regards
JB

On Sat, Oct 8, 2022 at 6:12 AM Jean-Baptiste Onofré  wrote:
>
> OK, so let's focus on "K5" name.
>
> Actually, I wanted the opposite and give a chance for any subproject:
> for most people karaf == the runtime (they don't necessarily see
> winegrower, decanter, etc.
>
> But OK, let's keep the Karaf name and use a new subproject name.
>
> Maybe we can use just a tag name: no rename, but on the website use
> Karaf (OSGi) to clearly stand it's the OSGi runtime.
>
> Regards
> JB
>
> On Fri, Oct 7, 2022 at 9:09 PM Łukasz Dywicki  wrote:
> >
> > Why rename karaf if it is what it was since begining?
> > Karaf is with us since more than decade changing names is not going to help 
> > it. More over it will definitely confuse people and users as we do not have 
> > a communication channel to all of them other than this mailing list and 
> > website.
> > We had multiple subprojects under Karaf till now. New runtime is yet 
> > another subproject. If it will evolve into something larger it can become 
> > its own TLP just like Karaf did back after leaving ServiceMix core and 
> > Felix.
> > For now we dont know how it will grow hence I would abstain from making any 
> > changes to primary project/use.
> >
> > Best
> > Łukasz Dywicki
> > --
> > Code-House
> > http://code-house.org
> >
> > > On 7 Oct 2022, at 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 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
OK, so let's focus on "K5" name.

Actually, I wanted the opposite and give a chance for any subproject:
for most people karaf == the runtime (they don't necessarily see
winegrower, decanter, etc.

But OK, let's keep the Karaf name and use a new subproject name.

Maybe we can use just a tag name: no rename, but on the website use
Karaf (OSGi) to clearly stand it's the OSGi runtime.

Regards
JB

On Fri, Oct 7, 2022 at 9:09 PM Łukasz Dywicki  wrote:
>
> Why rename karaf if it is what it was since begining?
> Karaf is with us since more than decade changing names is not going to help 
> it. More over it will definitely confuse people and users as we do not have a 
> communication channel to all of them other than this mailing list and website.
> We had multiple subprojects under Karaf till now. New runtime is yet another 
> subproject. If it will evolve into something larger it can become its own TLP 
> just like Karaf did back after leaving ServiceMix core and Felix.
> For now we dont know how it will grow hence I would abstain from making any 
> changes to primary project/use.
>
> Best
> Łukasz Dywicki
> --
> Code-House
> http://code-house.org
>
> > On 7 Oct 2022, at 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
> > 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?
> >>
> 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Łukasz Dywicki
Why rename karaf if it is what it was since begining?
Karaf is with us since more than decade changing names is not going to help it. 
More over it will definitely confuse people and users as we do not have a 
communication channel to all of them other than this mailing list and website.
We had multiple subprojects under Karaf till now. New runtime is yet another 
subproject. If it will evolve into something larger it can become its own TLP 
just like Karaf did back after leaving ServiceMix core and Felix.
For now we dont know how it will grow hence I would abstain from making any 
changes to primary project/use.

Best
Łukasz Dywicki
--
Code-House
http://code-house.org

> On 7 Oct 2022, at 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
> 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 <
>> l...@code-house.org>
>> 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 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
Easy and straightforward ! I like it :)

+1 for Karaf OSGi and Karaf Minho ?

Thanks,
Regards
JB

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

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 
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.


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
>  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. <
> jamie.goody...@gmail.com>
>  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
> >>> 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.
> >>>
> >>> 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Francois Papon

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

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

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 <

l...@code-house.org>

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


Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Francois Papon

:D

On 07/10/2022 13:37, Serge Huber wrote:

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

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. <

jamie.goody...@gmail.com>

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 <

l...@code-house.org>

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é <

j...@nanthrax.net>

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.

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
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
> >> 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
> > 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 <
> >> l...@code-house.org>
> >> 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 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
No :) not classic.

I think something brand new in the wine wording ;)

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
> >> 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
> > 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 <
> >> l...@code-house.org>
> >> 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
> >>> 

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
> > 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. <
> jamie.goody...@gmail.com>
> >> 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 <
> >> l...@code-house.org>
> >> 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
> >> 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Francois Papon

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

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 <

l...@code-house.org>

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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-07 Thread Jean-Baptiste Onofré
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
> >>> 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 <
> l...@code-house.org>
>  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:
> >>
> >> 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Matt Pavlovich
+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 
>>> 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
 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jean-Baptiste Onofré
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 
> > 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 

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Łukasz Dywicki

Hi,
K5 is definitely a bit too close and too cryptic to avoid confusion. I 
understand that we would like to have continuity and, at the same time 
show new thing as a evolution/revolution in how applications can be 
built, however staying with Apache Karaf K5 will make more harm than 
good. See that K5 might be mistakenly understood as next major release 
of karaf runtime.


From names you mentioned Minho seems to be closest to Karaf, Winegrower 
and Cellar. ;)


Best,
Łukasz

On 6.10.2022 15:50, Jean-Baptiste Onofré wrote:

Yes, it seems that K5 is confusing and too close to Karaf current
"runtime" naming.

I'm OK to use a brand new name for K5 (and I will do all renaming).

I would like to propose:

- Apache Karaf Kepsilon (Epsilon means 5 in Greek, Kepsilon == K5 ;))
- Apache Karaf Verde (using the Green aspect of K5, power efficient, etc)
- Apache Karaf Minho (Minho is a Portuguese region where they produce
green wine ;))

Thoughts ?

Regards
JB

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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jamie G.
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 
> 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: [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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jean-Baptiste Onofré
Yes, it seems that K5 is confusing and too close to Karaf current
"runtime" naming.

I'm OK to use a brand new name for K5 (and I will do all renaming).

I would like to propose:

- Apache Karaf Kepsilon (Epsilon means 5 in Greek, Kepsilon == K5 ;))
- Apache Karaf Verde (using the Green aspect of K5, power efficient, etc)
- Apache Karaf Minho (Minho is a Portuguese region where they produce
green wine ;))

Thoughts ?

Regards
JB

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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Francois Papon

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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jean-Baptiste Onofré
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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jamie G.
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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jean-Baptiste Onofré
Hi Lukasz,

If you are right about K5 doesn't use OSGi at core, K5 is new
milestone on Karaf as:

1. It can still optionally support OSGi
2. It will provide few similar features as Karaf (JMX, shell, etc) but
not powered by OSGi anymore.

That's why I'm using K5 (and not Karaf5 ;)). K5 is its own name.

If the others want something "more different", I can provide some. I
think K5 is strong enough.

Thoughts ?
Regards
JB

On Thu, Oct 6, 2022 at 2:06 PM Ł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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Jamie G.
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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-06 Thread Łukasz Dywicki
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: [DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-04 Thread fpapon

Hi,

As a contributor of K5, I cannot said anything than +1 :)

regards,

Francois

On 04/10/2022 18:34, 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


--
--
François



[DISCUSS] Accepting K5 in the Karaf ecosystem

2022-10-04 Thread Jean-Baptiste Onofré
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