You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Andrea Cosentino <an...@yahoo.com.INVALID> on 2020/03/13 09:00:20 UTC
Moving Karaf/OSGi code into a Camel sub project
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: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Claus,
Thanks, I will tackle that ;)
Regards
JB
> Le 14 mars 2020 à 07:18, Claus Ibsen <cl...@gmail.com> 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
> <an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
>> Twitter: @oscerd2
>> Github: oscerd
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Claus Ibsen <cl...@gmail.com>.
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
<an...@yahoo.com.invalid> 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: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Agree, that’s the easiest way (at least for reviewer not the release manager ;) ).
Regards
JB
> Le 13 mars 2020 à 15:29, Andrea Cosentino <an...@gmail.com> 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 <gn...@apache.org>
> 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 <an...@gmail.com> 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 <
>>> jb@nanthrax.net> 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 <zo...@regvart.com> 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 <
>> jb@nanthrax.net
>>>>
>>>> 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
>>>> <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
>>>>>>> Twitter: @oscerd2
>>>>>>> Github: oscerd
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Zoran Regvart
>>>>
>>>>
>>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Andrea Cosentino <an...@gmail.com>.
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 <gn...@apache.org>
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 <an...@gmail.com> 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 <
> > jb@nanthrax.net> 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 <zo...@regvart.com> 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 <
> jb@nanthrax.net
> > >
> > > 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
> > > <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
> > > >>> Twitter: @oscerd2
> > > >>> Github: oscerd
> > > >>
> > > >
> > > >
> > > > --
> > > > Zoran Regvart
> > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gn...@apache.org> 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 <an...@gmail.com> 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 <
>> jb@nanthrax.net> 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 <zo...@regvart.com> 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 <jb@nanthrax.net
>>>
>>> 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
>>> <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
>>>>>> Twitter: @oscerd2
>>>>>> Github: oscerd
>>>>>
>>>>
>>>>
>>>> --
>>>> Zoran Regvart
>>>
>>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Guillaume Nodet <gn...@apache.org>.
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 <an...@gmail.com> 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 <
> jb@nanthrax.net> 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 <zo...@regvart.com> 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 <jb@nanthrax.net
> >
> > 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
> > <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
> > >>> Twitter: @oscerd2
> > >>> Github: oscerd
> > >>
> > >
> > >
> > > --
> > > Zoran Regvart
> >
> >
>
--
------------------------
Guillaume Nodet
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Andrea Cosentino <an...@gmail.com>.
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 <
jb@nanthrax.net> 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 <zo...@regvart.com> 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 <jb...@nanthrax.net>
> 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
> <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
> >>> Twitter: @oscerd2
> >>> Github: oscerd
> >>
> >
> >
> > --
> > Zoran Regvart
>
>
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <zo...@regvart.com> 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 <jb...@nanthrax.net> 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 <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
>>> Twitter: @oscerd2
>>> Github: oscerd
>>
>
>
> --
> Zoran Regvart
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Zoran Regvart <zo...@regvart.com>.
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 <jb...@nanthrax.net> 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 <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
> > Twitter: @oscerd2
> > Github: oscerd
>
--
Zoran Regvart
Re: Moving Karaf/OSGi code into a Camel sub project
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <an...@yahoo.com.INVALID> 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: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd