Moving Karaf/OSGi code into a Camel sub project

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving Karaf/OSGi code into a Camel sub project

Andrea Cosentino-2
Hello,

We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.

We should do the same for Karaf/OSGi support for multiple reasons:
- Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
- We could have separated documentation as we already have for Spring Boot
- We could make the main camel repository lighter
- It’s much easier to find code related to OSGi/Karaf as its all together in 
- We can then add Karaf as a sub project to the Camel website (see projects menu item)
- We can have separated documentation on the website for Karaf/OSGi
- We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website

If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.

We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.

The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.

And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.

This will require some effort but we do believe it’s worth the work.

Thoughts?

--
Andrea Cosentino 
----------------------------------
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: [hidden email]
Twitter: @oscerd2
Github: oscerd
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

jbonofre
Hi Andrea,

It makes sense to "mimic" spring-boot.

I have some WIP on Camel Karaf (not directly related to OSGi). I also have some non-OSGi Karaf support, but it will be similar to some starter/BOM similar to spring-boot.

Regards
JB

> Le 13 mars 2020 à 10:00, Andrea Cosentino <[hidden email]> a écrit :
>
> Hello,
>
> We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.
>
> We should do the same for Karaf/OSGi support for multiple reasons:
> - Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
> - We could have separated documentation as we already have for Spring Boot
> - We could make the main camel repository lighter
> - It’s much easier to find code related to OSGi/Karaf as its all together in
> - We can then add Karaf as a sub project to the Camel website (see projects menu item)
> - We can have separated documentation on the website for Karaf/OSGi
> - We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website
>
> If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.
>
> We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.
>
> The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.
>
> And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.
>
> This will require some effort but we do believe it’s worth the work.
>
> Thoughts?
>
> --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: [hidden email]
> Twitter: @oscerd2
> Github: oscerd

Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

Zoran Regvart-2
Hi Cameleers,
I'm for splitting, I think in mid to long term this will enable us to
run checks on pull requests and allow us to iterate faster.

I think we should rethink release process, in a sense that I think we
should try to release from several repositories at the same time. Not
sure if there's a way to ease the effort for the release manager, but
perhaps we should try to invest into that as well.

zoran

On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <[hidden email]> wrote:

>
> Hi Andrea,
>
> It makes sense to "mimic" spring-boot.
>
> I have some WIP on Camel Karaf (not directly related to OSGi). I also have some non-OSGi Karaf support, but it will be similar to some starter/BOM similar to spring-boot.
>
> Regards
> JB
>
> > Le 13 mars 2020 à 10:00, Andrea Cosentino <[hidden email]> a écrit :
> >
> > Hello,
> >
> > We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.
> >
> > We should do the same for Karaf/OSGi support for multiple reasons:
> > - Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
> > - We could have separated documentation as we already have for Spring Boot
> > - We could make the main camel repository lighter
> > - It’s much easier to find code related to OSGi/Karaf as its all together in
> > - We can then add Karaf as a sub project to the Camel website (see projects menu item)
> > - We can have separated documentation on the website for Karaf/OSGi
> > - We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website
> >
> > If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.
> >
> > We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.
> >
> > The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.
> >
> > And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.
> >
> > This will require some effort but we do believe it’s worth the work.
> >
> > Thoughts?
> >
> > --
> > Andrea Cosentino
> > ----------------------------------
> > Apache Camel PMC Chair
> > Apache Karaf Committer
> > Apache Servicemix PMC Member
> > Email: [hidden email]
> > Twitter: @oscerd2
> > Github: oscerd
>


--
Zoran Regvart
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

jbonofre
Hi Zoran,

I think we can do all releases in a row using kind of meta repository.
The release manager should be careful to checkout all required repositories.

Thoughts ?

Regards
JB

> Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
>
> Hi Cameleers,
> I'm for splitting, I think in mid to long term this will enable us to
> run checks on pull requests and allow us to iterate faster.
>
> I think we should rethink release process, in a sense that I think we
> should try to release from several repositories at the same time. Not
> sure if there's a way to ease the effort for the release manager, but
> perhaps we should try to invest into that as well.
>
> zoran
>
> On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <[hidden email]> wrote:
>>
>> Hi Andrea,
>>
>> It makes sense to "mimic" spring-boot.
>>
>> I have some WIP on Camel Karaf (not directly related to OSGi). I also have some non-OSGi Karaf support, but it will be similar to some starter/BOM similar to spring-boot.
>>
>> Regards
>> JB
>>
>>> Le 13 mars 2020 à 10:00, Andrea Cosentino <[hidden email]> a écrit :
>>>
>>> Hello,
>>>
>>> We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.
>>>
>>> We should do the same for Karaf/OSGi support for multiple reasons:
>>> - Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
>>> - We could have separated documentation as we already have for Spring Boot
>>> - We could make the main camel repository lighter
>>> - It’s much easier to find code related to OSGi/Karaf as its all together in
>>> - We can then add Karaf as a sub project to the Camel website (see projects menu item)
>>> - We can have separated documentation on the website for Karaf/OSGi
>>> - We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website
>>>
>>> If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.
>>>
>>> We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.
>>>
>>> The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.
>>>
>>> And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.
>>>
>>> This will require some effort but we do believe it’s worth the work.
>>>
>>> Thoughts?
>>>
>>> --
>>> Andrea Cosentino
>>> ----------------------------------
>>> Apache Camel PMC Chair
>>> Apache Karaf Committer
>>> Apache Servicemix PMC Member
>>> Email: [hidden email]
>>> Twitter: @oscerd2
>>> Github: oscerd
>>
>
>
> --
> Zoran Regvart

Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

Andrea Cosentino-3
No, we can't do in this way. We need to first release the camel bits, then
we can also decide to go in parallel, but the first step is release the
main camel baseline.

Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre <
[hidden email]> ha scritto:

> Hi Zoran,
>
> I think we can do all releases in a row using kind of meta repository.
> The release manager should be careful to checkout all required
> repositories.
>
> Thoughts ?
>
> Regards
> JB
>
> > Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
> >
> > Hi Cameleers,
> > I'm for splitting, I think in mid to long term this will enable us to
> > run checks on pull requests and allow us to iterate faster.
> >
> > I think we should rethink release process, in a sense that I think we
> > should try to release from several repositories at the same time. Not
> > sure if there's a way to ease the effort for the release manager, but
> > perhaps we should try to invest into that as well.
> >
> > zoran
> >
> > On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <[hidden email]>
> wrote:
> >>
> >> Hi Andrea,
> >>
> >> It makes sense to "mimic" spring-boot.
> >>
> >> I have some WIP on Camel Karaf (not directly related to OSGi). I also
> have some non-OSGi Karaf support, but it will be similar to some
> starter/BOM similar to spring-boot.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 13 mars 2020 à 10:00, Andrea Cosentino
> <[hidden email]> a écrit :
> >>>
> >>> Hello,
> >>>
> >>> We already moved the Spring Boot code and all the SB starters into a
> separated git repository for convenience and to make the core independent.
> And the same was done for Camel Quarkus, which started as a separated sub
> project from the beginning. And we also recently moved the examples out
> into its own git repository.
> >>>
> >>> We should do the same for Karaf/OSGi support for multiple reasons:
> >>> - Having a separated repository will make easier and faster to release
> new stuff and fixes without rebuilding the core part (this would be
> something really useful)
> >>> - We could have separated documentation as we already have for Spring
> Boot
> >>> - We could make the main camel repository lighter
> >>> - It’s much easier to find code related to OSGi/Karaf as its all
> together in
> >>> - We can then add Karaf as a sub project to the Camel website (see
> projects menu item)
> >>> - We can have separated documentation on the website for Karaf/OSGi
> >>> - We can generate a list of components that are supported in
> Karaf/OSGi and also publish this on the website
> >>>
> >>> If we follow this path, we could be able to add new supported
> platforms in the future without having to modify the core part.
> >>>
> >>> We envision that we only need to move core/camel-core-osgi, and all
> the osgi components, and together with the karaf features and karaf
> commands, and the itests. We will continue to generate OSGi MANIFEST.MF in
> the JARs from the main Camel so they are still OSGi bundles.
> >>>
> >>> The end result would essentially be the same as today. Camel will
> continue to be supported and work on Karaf.
> >>>
> >>> And we think we should do this before the first LTS release of Apache
> Camel, which is planned to be Camel 3.3.0. So ideally we get this done for
> Camel 3.2.0 so more people in the community can get their hands on a
> release and provide feedback.
> >>>
> >>> This will require some effort but we do believe it’s worth the work.
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Andrea Cosentino
> >>> ----------------------------------
> >>> Apache Camel PMC Chair
> >>> Apache Karaf Committer
> >>> Apache Servicemix PMC Member
> >>> Email: [hidden email]
> >>> Twitter: @oscerd2
> >>> Github: oscerd
> >>
> >
> >
> > --
> > Zoran Regvart
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

gnodet
I think what JB meant is that we can use a single staging repo and a single
vote.
It's not a problem to do all releases at once.

Le ven. 13 mars 2020 à 15:06, Andrea Cosentino <[hidden email]> a écrit :

> No, we can't do in this way. We need to first release the camel bits, then
> we can also decide to go in parallel, but the first step is release the
> main camel baseline.
>
> Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre <
> [hidden email]> ha scritto:
>
> > Hi Zoran,
> >
> > I think we can do all releases in a row using kind of meta repository.
> > The release manager should be careful to checkout all required
> > repositories.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > > Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
> > >
> > > Hi Cameleers,
> > > I'm for splitting, I think in mid to long term this will enable us to
> > > run checks on pull requests and allow us to iterate faster.
> > >
> > > I think we should rethink release process, in a sense that I think we
> > > should try to release from several repositories at the same time. Not
> > > sure if there's a way to ease the effort for the release manager, but
> > > perhaps we should try to invest into that as well.
> > >
> > > zoran
> > >
> > > On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <[hidden email]
> >
> > wrote:
> > >>
> > >> Hi Andrea,
> > >>
> > >> It makes sense to "mimic" spring-boot.
> > >>
> > >> I have some WIP on Camel Karaf (not directly related to OSGi). I also
> > have some non-OSGi Karaf support, but it will be similar to some
> > starter/BOM similar to spring-boot.
> > >>
> > >> Regards
> > >> JB
> > >>
> > >>> Le 13 mars 2020 à 10:00, Andrea Cosentino
> > <[hidden email]> a écrit :
> > >>>
> > >>> Hello,
> > >>>
> > >>> We already moved the Spring Boot code and all the SB starters into a
> > separated git repository for convenience and to make the core
> independent.
> > And the same was done for Camel Quarkus, which started as a separated sub
> > project from the beginning. And we also recently moved the examples out
> > into its own git repository.
> > >>>
> > >>> We should do the same for Karaf/OSGi support for multiple reasons:
> > >>> - Having a separated repository will make easier and faster to
> release
> > new stuff and fixes without rebuilding the core part (this would be
> > something really useful)
> > >>> - We could have separated documentation as we already have for Spring
> > Boot
> > >>> - We could make the main camel repository lighter
> > >>> - It’s much easier to find code related to OSGi/Karaf as its all
> > together in
> > >>> - We can then add Karaf as a sub project to the Camel website (see
> > projects menu item)
> > >>> - We can have separated documentation on the website for Karaf/OSGi
> > >>> - We can generate a list of components that are supported in
> > Karaf/OSGi and also publish this on the website
> > >>>
> > >>> If we follow this path, we could be able to add new supported
> > platforms in the future without having to modify the core part.
> > >>>
> > >>> We envision that we only need to move core/camel-core-osgi, and all
> > the osgi components, and together with the karaf features and karaf
> > commands, and the itests. We will continue to generate OSGi MANIFEST.MF
> in
> > the JARs from the main Camel so they are still OSGi bundles.
> > >>>
> > >>> The end result would essentially be the same as today. Camel will
> > continue to be supported and work on Karaf.
> > >>>
> > >>> And we think we should do this before the first LTS release of Apache
> > Camel, which is planned to be Camel 3.3.0. So ideally we get this done
> for
> > Camel 3.2.0 so more people in the community can get their hands on a
> > release and provide feedback.
> > >>>
> > >>> This will require some effort but we do believe it’s worth the work.
> > >>>
> > >>> Thoughts?
> > >>>
> > >>> --
> > >>> Andrea Cosentino
> > >>> ----------------------------------
> > >>> Apache Camel PMC Chair
> > >>> Apache Karaf Committer
> > >>> Apache Servicemix PMC Member
> > >>> Email: [hidden email]
> > >>> Twitter: @oscerd2
> > >>> Github: oscerd
> > >>
> > >
> > >
> > > --
> > > Zoran Regvart
> >
> >
>


--
------------------------
Guillaume Nodet
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

Andrea Cosentino-3
Ah yeah, absolutely, we can do exactly as we've done for 3.1.0.

The release process time will be more, but the time for voting will be less
than going in row.

Il giorno ven 13 mar 2020 alle ore 15:27 Guillaume Nodet <[hidden email]>
ha scritto:

> I think what JB meant is that we can use a single staging repo and a single
> vote.
> It's not a problem to do all releases at once.
>
> Le ven. 13 mars 2020 à 15:06, Andrea Cosentino <[hidden email]> a
> écrit :
>
> > No, we can't do in this way. We need to first release the camel bits,
> then
> > we can also decide to go in parallel, but the first step is release the
> > main camel baseline.
> >
> > Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre <
> > [hidden email]> ha scritto:
> >
> > > Hi Zoran,
> > >
> > > I think we can do all releases in a row using kind of meta repository.
> > > The release manager should be careful to checkout all required
> > > repositories.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > >
> > > > Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
> > > >
> > > > Hi Cameleers,
> > > > I'm for splitting, I think in mid to long term this will enable us to
> > > > run checks on pull requests and allow us to iterate faster.
> > > >
> > > > I think we should rethink release process, in a sense that I think we
> > > > should try to release from several repositories at the same time. Not
> > > > sure if there's a way to ease the effort for the release manager, but
> > > > perhaps we should try to invest into that as well.
> > > >
> > > > zoran
> > > >
> > > > On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <
> [hidden email]
> > >
> > > wrote:
> > > >>
> > > >> Hi Andrea,
> > > >>
> > > >> It makes sense to "mimic" spring-boot.
> > > >>
> > > >> I have some WIP on Camel Karaf (not directly related to OSGi). I
> also
> > > have some non-OSGi Karaf support, but it will be similar to some
> > > starter/BOM similar to spring-boot.
> > > >>
> > > >> Regards
> > > >> JB
> > > >>
> > > >>> Le 13 mars 2020 à 10:00, Andrea Cosentino
> > > <[hidden email]> a écrit :
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> We already moved the Spring Boot code and all the SB starters into
> a
> > > separated git repository for convenience and to make the core
> > independent.
> > > And the same was done for Camel Quarkus, which started as a separated
> sub
> > > project from the beginning. And we also recently moved the examples out
> > > into its own git repository.
> > > >>>
> > > >>> We should do the same for Karaf/OSGi support for multiple reasons:
> > > >>> - Having a separated repository will make easier and faster to
> > release
> > > new stuff and fixes without rebuilding the core part (this would be
> > > something really useful)
> > > >>> - We could have separated documentation as we already have for
> Spring
> > > Boot
> > > >>> - We could make the main camel repository lighter
> > > >>> - It’s much easier to find code related to OSGi/Karaf as its all
> > > together in
> > > >>> - We can then add Karaf as a sub project to the Camel website (see
> > > projects menu item)
> > > >>> - We can have separated documentation on the website for Karaf/OSGi
> > > >>> - We can generate a list of components that are supported in
> > > Karaf/OSGi and also publish this on the website
> > > >>>
> > > >>> If we follow this path, we could be able to add new supported
> > > platforms in the future without having to modify the core part.
> > > >>>
> > > >>> We envision that we only need to move core/camel-core-osgi, and all
> > > the osgi components, and together with the karaf features and karaf
> > > commands, and the itests. We will continue to generate OSGi MANIFEST.MF
> > in
> > > the JARs from the main Camel so they are still OSGi bundles.
> > > >>>
> > > >>> The end result would essentially be the same as today. Camel will
> > > continue to be supported and work on Karaf.
> > > >>>
> > > >>> And we think we should do this before the first LTS release of
> Apache
> > > Camel, which is planned to be Camel 3.3.0. So ideally we get this done
> > for
> > > Camel 3.2.0 so more people in the community can get their hands on a
> > > release and provide feedback.
> > > >>>
> > > >>> This will require some effort but we do believe it’s worth the
> work.
> > > >>>
> > > >>> Thoughts?
> > > >>>
> > > >>> --
> > > >>> Andrea Cosentino
> > > >>> ----------------------------------
> > > >>> Apache Camel PMC Chair
> > > >>> Apache Karaf Committer
> > > >>> Apache Servicemix PMC Member
> > > >>> Email: [hidden email]
> > > >>> Twitter: @oscerd2
> > > >>> Github: oscerd
> > > >>
> > > >
> > > >
> > > > --
> > > > Zoran Regvart
> > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

jbonofre
In reply to this post by gnodet
Yes, that’s my point. Source repositories is one think, but kind of "assembly" on single staging repository is more convenient IMHO.

Regards
JB

> Le 13 mars 2020 à 15:27, Guillaume Nodet <[hidden email]> a écrit :
>
> I think what JB meant is that we can use a single staging repo and a single
> vote.
> It's not a problem to do all releases at once.
>
> Le ven. 13 mars 2020 à 15:06, Andrea Cosentino <[hidden email]> a écrit :
>
>> No, we can't do in this way. We need to first release the camel bits, then
>> we can also decide to go in parallel, but the first step is release the
>> main camel baseline.
>>
>> Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre <
>> [hidden email]> ha scritto:
>>
>>> Hi Zoran,
>>>
>>> I think we can do all releases in a row using kind of meta repository.
>>> The release manager should be careful to checkout all required
>>> repositories.
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>>> Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
>>>>
>>>> Hi Cameleers,
>>>> I'm for splitting, I think in mid to long term this will enable us to
>>>> run checks on pull requests and allow us to iterate faster.
>>>>
>>>> I think we should rethink release process, in a sense that I think we
>>>> should try to release from several repositories at the same time. Not
>>>> sure if there's a way to ease the effort for the release manager, but
>>>> perhaps we should try to invest into that as well.
>>>>
>>>> zoran
>>>>
>>>> On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <[hidden email]
>>>
>>> wrote:
>>>>>
>>>>> Hi Andrea,
>>>>>
>>>>> It makes sense to "mimic" spring-boot.
>>>>>
>>>>> I have some WIP on Camel Karaf (not directly related to OSGi). I also
>>> have some non-OSGi Karaf support, but it will be similar to some
>>> starter/BOM similar to spring-boot.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 13 mars 2020 à 10:00, Andrea Cosentino
>>> <[hidden email]> a écrit :
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> We already moved the Spring Boot code and all the SB starters into a
>>> separated git repository for convenience and to make the core
>> independent.
>>> And the same was done for Camel Quarkus, which started as a separated sub
>>> project from the beginning. And we also recently moved the examples out
>>> into its own git repository.
>>>>>>
>>>>>> We should do the same for Karaf/OSGi support for multiple reasons:
>>>>>> - Having a separated repository will make easier and faster to
>> release
>>> new stuff and fixes without rebuilding the core part (this would be
>>> something really useful)
>>>>>> - We could have separated documentation as we already have for Spring
>>> Boot
>>>>>> - We could make the main camel repository lighter
>>>>>> - It’s much easier to find code related to OSGi/Karaf as its all
>>> together in
>>>>>> - We can then add Karaf as a sub project to the Camel website (see
>>> projects menu item)
>>>>>> - We can have separated documentation on the website for Karaf/OSGi
>>>>>> - We can generate a list of components that are supported in
>>> Karaf/OSGi and also publish this on the website
>>>>>>
>>>>>> If we follow this path, we could be able to add new supported
>>> platforms in the future without having to modify the core part.
>>>>>>
>>>>>> We envision that we only need to move core/camel-core-osgi, and all
>>> the osgi components, and together with the karaf features and karaf
>>> commands, and the itests. We will continue to generate OSGi MANIFEST.MF
>> in
>>> the JARs from the main Camel so they are still OSGi bundles.
>>>>>>
>>>>>> The end result would essentially be the same as today. Camel will
>>> continue to be supported and work on Karaf.
>>>>>>
>>>>>> And we think we should do this before the first LTS release of Apache
>>> Camel, which is planned to be Camel 3.3.0. So ideally we get this done
>> for
>>> Camel 3.2.0 so more people in the community can get their hands on a
>>> release and provide feedback.
>>>>>>
>>>>>> This will require some effort but we do believe it’s worth the work.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> --
>>>>>> Andrea Cosentino
>>>>>> ----------------------------------
>>>>>> Apache Camel PMC Chair
>>>>>> Apache Karaf Committer
>>>>>> Apache Servicemix PMC Member
>>>>>> Email: [hidden email]
>>>>>> Twitter: @oscerd2
>>>>>> Github: oscerd
>>>>>
>>>>
>>>>
>>>> --
>>>> Zoran Regvart
>>>
>>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet

Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

jbonofre
In reply to this post by Andrea Cosentino-3
Agree, that’s the easiest way (at least for reviewer not the release manager ;) ).

Regards
JB

> Le 13 mars 2020 à 15:29, Andrea Cosentino <[hidden email]> a écrit :
>
> Ah yeah, absolutely, we can do exactly as we've done for 3.1.0.
>
> The release process time will be more, but the time for voting will be less
> than going in row.
>
> Il giorno ven 13 mar 2020 alle ore 15:27 Guillaume Nodet <[hidden email]>
> ha scritto:
>
>> I think what JB meant is that we can use a single staging repo and a single
>> vote.
>> It's not a problem to do all releases at once.
>>
>> Le ven. 13 mars 2020 à 15:06, Andrea Cosentino <[hidden email]> a
>> écrit :
>>
>>> No, we can't do in this way. We need to first release the camel bits,
>> then
>>> we can also decide to go in parallel, but the first step is release the
>>> main camel baseline.
>>>
>>> Il giorno ven 13 mar 2020 alle ore 15:04 Jean-Baptiste Onofre <
>>> [hidden email]> ha scritto:
>>>
>>>> Hi Zoran,
>>>>
>>>> I think we can do all releases in a row using kind of meta repository.
>>>> The release manager should be careful to checkout all required
>>>> repositories.
>>>>
>>>> Thoughts ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 13 mars 2020 à 15:02, Zoran Regvart <[hidden email]> a écrit :
>>>>>
>>>>> Hi Cameleers,
>>>>> I'm for splitting, I think in mid to long term this will enable us to
>>>>> run checks on pull requests and allow us to iterate faster.
>>>>>
>>>>> I think we should rethink release process, in a sense that I think we
>>>>> should try to release from several repositories at the same time. Not
>>>>> sure if there's a way to ease the effort for the release manager, but
>>>>> perhaps we should try to invest into that as well.
>>>>>
>>>>> zoran
>>>>>
>>>>> On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <
>> [hidden email]
>>>>
>>>> wrote:
>>>>>>
>>>>>> Hi Andrea,
>>>>>>
>>>>>> It makes sense to "mimic" spring-boot.
>>>>>>
>>>>>> I have some WIP on Camel Karaf (not directly related to OSGi). I
>> also
>>>> have some non-OSGi Karaf support, but it will be similar to some
>>>> starter/BOM similar to spring-boot.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 13 mars 2020 à 10:00, Andrea Cosentino
>>>> <[hidden email]> a écrit :
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We already moved the Spring Boot code and all the SB starters into
>> a
>>>> separated git repository for convenience and to make the core
>>> independent.
>>>> And the same was done for Camel Quarkus, which started as a separated
>> sub
>>>> project from the beginning. And we also recently moved the examples out
>>>> into its own git repository.
>>>>>>>
>>>>>>> We should do the same for Karaf/OSGi support for multiple reasons:
>>>>>>> - Having a separated repository will make easier and faster to
>>> release
>>>> new stuff and fixes without rebuilding the core part (this would be
>>>> something really useful)
>>>>>>> - We could have separated documentation as we already have for
>> Spring
>>>> Boot
>>>>>>> - We could make the main camel repository lighter
>>>>>>> - It’s much easier to find code related to OSGi/Karaf as its all
>>>> together in
>>>>>>> - We can then add Karaf as a sub project to the Camel website (see
>>>> projects menu item)
>>>>>>> - We can have separated documentation on the website for Karaf/OSGi
>>>>>>> - We can generate a list of components that are supported in
>>>> Karaf/OSGi and also publish this on the website
>>>>>>>
>>>>>>> If we follow this path, we could be able to add new supported
>>>> platforms in the future without having to modify the core part.
>>>>>>>
>>>>>>> We envision that we only need to move core/camel-core-osgi, and all
>>>> the osgi components, and together with the karaf features and karaf
>>>> commands, and the itests. We will continue to generate OSGi MANIFEST.MF
>>> in
>>>> the JARs from the main Camel so they are still OSGi bundles.
>>>>>>>
>>>>>>> The end result would essentially be the same as today. Camel will
>>>> continue to be supported and work on Karaf.
>>>>>>>
>>>>>>> And we think we should do this before the first LTS release of
>> Apache
>>>> Camel, which is planned to be Camel 3.3.0. So ideally we get this done
>>> for
>>>> Camel 3.2.0 so more people in the community can get their hands on a
>>>> release and provide feedback.
>>>>>>>
>>>>>>> This will require some effort but we do believe it’s worth the
>> work.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> --
>>>>>>> Andrea Cosentino
>>>>>>> ----------------------------------
>>>>>>> Apache Camel PMC Chair
>>>>>>> Apache Karaf Committer
>>>>>>> Apache Servicemix PMC Member
>>>>>>> Email: [hidden email]
>>>>>>> Twitter: @oscerd2
>>>>>>> Github: oscerd
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Zoran Regvart
>>>>
>>>>
>>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>

Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

Claus Ibsen-2
In reply to this post by Andrea Cosentino-2
Hi

+1

I have created a JIRA ticket about this
https://issues.apache.org/jira/browse/CAMEL-14715

Andrea I think you helped last time with setting up for both SB and examples.
We need a repo for this named: camel-karaf


On Fri, Mar 13, 2020 at 10:00 AM Andrea Cosentino
<[hidden email]> wrote:

>
> Hello,
>
> We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.
>
> We should do the same for Karaf/OSGi support for multiple reasons:
> - Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
> - We could have separated documentation as we already have for Spring Boot
> - We could make the main camel repository lighter
> - It’s much easier to find code related to OSGi/Karaf as its all together in
> - We can then add Karaf as a sub project to the Camel website (see projects menu item)
> - We can have separated documentation on the website for Karaf/OSGi
> - We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website
>
> If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.
>
> We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.
>
> The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.
>
> And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.
>
> This will require some effort but we do believe it’s worth the work.
>
> Thoughts?
>
> --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Chair
> Apache Karaf Committer
> Apache Servicemix PMC Member
> Email: [hidden email]
> Twitter: @oscerd2
> Github: oscerd



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: Moving Karaf/OSGi code into a Camel sub project

jbonofre
Hi Claus,

Thanks, I will tackle that ;)

Regards
JB

> Le 14 mars 2020 à 07:18, Claus Ibsen <[hidden email]> a écrit :
>
> Hi
>
> +1
>
> I have created a JIRA ticket about this
> https://issues.apache.org/jira/browse/CAMEL-14715
>
> Andrea I think you helped last time with setting up for both SB and examples.
> We need a repo for this named: camel-karaf
>
>
> On Fri, Mar 13, 2020 at 10:00 AM Andrea Cosentino
> <[hidden email]> wrote:
>>
>> Hello,
>>
>> We already moved the Spring Boot code and all the SB starters into a separated git repository for convenience and to make the core independent. And the same was done for Camel Quarkus, which started as a separated sub project from the beginning. And we also recently moved the examples out into its own git repository.
>>
>> We should do the same for Karaf/OSGi support for multiple reasons:
>> - Having a separated repository will make easier and faster to release new stuff and fixes without rebuilding the core part (this would be something really useful)
>> - We could have separated documentation as we already have for Spring Boot
>> - We could make the main camel repository lighter
>> - It’s much easier to find code related to OSGi/Karaf as its all together in
>> - We can then add Karaf as a sub project to the Camel website (see projects menu item)
>> - We can have separated documentation on the website for Karaf/OSGi
>> - We can generate a list of components that are supported in Karaf/OSGi and also publish this on the website
>>
>> If we follow this path, we could be able to add new supported platforms in the future without having to modify the core part.
>>
>> We envision that we only need to move core/camel-core-osgi, and all the osgi components, and together with the karaf features and karaf commands, and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs from the main Camel so they are still OSGi bundles.
>>
>> The end result would essentially be the same as today. Camel will continue to be supported and work on Karaf.
>>
>> And we think we should do this before the first LTS release of Apache Camel, which is planned to be Camel 3.3.0. So ideally we get this done for Camel 3.2.0 so more people in the community can get their hands on a release and provide feedback.
>>
>> This will require some effort but we do believe it’s worth the work.
>>
>> Thoughts?
>>
>> --
>> Andrea Cosentino
>> ----------------------------------
>> Apache Camel PMC Chair
>> Apache Karaf Committer
>> Apache Servicemix PMC Member
>> Email: [hidden email]
>> Twitter: @oscerd2
>> Github: oscerd
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2