Re: [CANCEL] [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 Thanks JB for the proposal. regards, François On 10/02/2023 09:43, Jean-Baptiste Onofré wrote: Hi guys, According to the vote and discussion on this thread, we don't have a consensus to move camel-karaf into the Karaf community. 1. As we have a decent/large number of users on Karaf running Camel routes. 2. As the Camel "core" community doesn't want to maintain OSGi related stuff in camel-core. I propose the following: 1. We keep camel-karaf at Camel (as we have camel-quarkus, camel-spring-boot, ..., I hope we don't have anything in camel-core needed/required by camel-quarkus or camel-spring-boot, else it wouldn't be fair for camel-karaf ;) ) 2. Camel Core can remove OSGi related stuff (headers, maven-bundle-plugin, ...), we will implement a new approach in camel-karaf (with a custom deployer as I proposed before for instance). 3. I will do a complete cleanup on the camel-karaf main branch, already upgrading to camel 4 to prepare camel-karaf 4. Thoughts ? Regards JB -- -- François
[CANCEL] [VOTE] Accept karaf-camel as new Apache Karaf subproject
Hi guys, According to the vote and discussion on this thread, we don't have a consensus to move camel-karaf into the Karaf community. 1. As we have a decent/large number of users on Karaf running Camel routes. 2. As the Camel "core" community doesn't want to maintain OSGi related stuff in camel-core. I propose the following: 1. We keep camel-karaf at Camel (as we have camel-quarkus, camel-spring-boot, ..., I hope we don't have anything in camel-core needed/required by camel-quarkus or camel-spring-boot, else it wouldn't be fair for camel-karaf ;) ) 2. Camel Core can remove OSGi related stuff (headers, maven-bundle-plugin, ...), we will implement a new approach in camel-karaf (with a custom deployer as I proposed before for instance). 3. I will do a complete cleanup on the camel-karaf main branch, already upgrading to camel 4 to prepare camel-karaf 4. Thoughts ? Regards JB
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Hi, I think it's important to split the discussion into two major aspects: technical aspect and community aspect. - Technically speaking, I don't see camel-karaf very different from camel-spring-boot or camel-quarkus or camel-k. It contains Camel specific to a platform, exactly like camel-quarkus or camel-spring-boot. The painful part is the wrapping of Camel components as features and sometimes the "impact" of OSGi on the Camel components behavior. However, I send a message while ago on the Camel dev mailing about couple of proposal to improve this, with highly simplified Camel Karaf features repository, no need to use SMX bundles anymore, no even need to wrap the Camel component as a bundle (most of the logic is done at build and camel-osgi-core). So, I think that technically speaking, we have room to improve the current situation and for me it's not a blocker. - Now about the community. I think we have to say things clearly: we know that the company mainly contributing on Camel doesn't want to support Karaf/OSGi anymore, due to roadmap change and business perspective. That's fair and fully understable. Where we have to be careful is that, as Apache project, if the community still wants to contribute and maintain Camel Karaf in Camel project, it's also a fair request, and this company should be supportive of that (and not "block" this community driven decision). Since the beginning of this discussion, I have tried to find a consensus matching everyone's expectation and wish (that's one of the core values of the Apache way). I thought the different communities wanted to move Camel Karaf to Karaf. But this thread shows it's not the case for everyone. So, I think it makes sense to cancel the formal vote now and start a new discussion round. If we don't have consensus about the move, then we will focus on the first point: keeping camel-karaf at camel and improving use/maintenance/etc from a technical standpoint. Thoughts ? Regards JB On Wed, Jan 18, 2023 at 9:14 PM Andrea Cosentino wrote: > > As a side note, it's not only aligning the features, it's also upgrading > the servicemix bundles to be able to align, JB knows what I'm talking about. > > I helped there a lot too (less in the last year or so) and it's really a > mess. > > Il mer 18 gen 2023, 20:43 Romain Manni-Bucau ha > scritto: > > > Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino a > > écrit : > > > > > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau ha > > > scritto: > > > > > > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a > > > > écrit : > > > > > > > > > Hello, > > > > > > > > > > The point is just one in relation to OSGi metadata. The components > > will > > > > be > > > > > consumed, also, by runtimes that don't need OSGi metadata, so why all > > > the > > > > > components should be with OSGi metadata and packaged as bundles? > > > > > > > > > > > > > I'm maybe a bit dumb but why all the work and meta for quarkus and > > spring > > > > boot if the reasoning is right? > > > > I perfectly understand spring or quarkus have their own programming > > > > model/runtime so need specific code and meta but then how is OSGi > > > > different? > > > > > > > > A simple example is that you should be able to drop most jandex indices > > > if > > > > your statement is true. > > > > > > > > > > My point is related more to have the components as bundles with OSGi > > > metadata. To me they should be just JAR. > > > Mainly the reason I'm saying this about supporting camel-karaf because > > > the work wi be on the shoulders of 1 developer and this is not right for > > me > > > and for the community. > > > > > > > Sure but osgi bundles always had been designed to be just jars as much as a > > jar with a jandex index or even with a custom manifest metadata or a json > > containing the pom description ;). > > > > But I fully share with you the ownership point. > > Any bundle (more generally meta maintenance) should be owned by the core > > code writer otherwise we end in weird state all the time, in particular > > when parts are optionals or need some specific loading mecanism > > (serviceloader for ex). The lifecycle is also an issue in time, we already > > are there with features around whiteboards for ex and camel itself has a > > hard time ensuring components work together so fear camel can be a bit big > > to have this enrichment work done properly outside camel in a project with > > less task force than camel itself. > > > > > > > Just this. > > > > > > > > > > > > > > > > > > > > > I don't see the reason why. At least the OSGi metadata should be > > > > generated > > > > > under camel Karaf project, instead of being part of the core > > components > > > > > > > > > > > > > I think the exact opposite since handling metadata in a 3rd always got > > > > proven not working very well for end user. > > > > SMix did a bunch of forks for that reason - which was enabling users > > but > > > > also a big constrait since users were not able to use
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
As a side note, it's not only aligning the features, it's also upgrading the servicemix bundles to be able to align, JB knows what I'm talking about. I helped there a lot too (less in the last year or so) and it's really a mess. Il mer 18 gen 2023, 20:43 Romain Manni-Bucau ha scritto: > Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino a > écrit : > > > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau ha > > scritto: > > > > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a > > > écrit : > > > > > > > Hello, > > > > > > > > The point is just one in relation to OSGi metadata. The components > will > > > be > > > > consumed, also, by runtimes that don't need OSGi metadata, so why all > > the > > > > components should be with OSGi metadata and packaged as bundles? > > > > > > > > > > I'm maybe a bit dumb but why all the work and meta for quarkus and > spring > > > boot if the reasoning is right? > > > I perfectly understand spring or quarkus have their own programming > > > model/runtime so need specific code and meta but then how is OSGi > > > different? > > > > > > A simple example is that you should be able to drop most jandex indices > > if > > > your statement is true. > > > > > > > My point is related more to have the components as bundles with OSGi > > metadata. To me they should be just JAR. > > Mainly the reason I'm saying this about supporting camel-karaf because > > the work wi be on the shoulders of 1 developer and this is not right for > me > > and for the community. > > > > Sure but osgi bundles always had been designed to be just jars as much as a > jar with a jandex index or even with a custom manifest metadata or a json > containing the pom description ;). > > But I fully share with you the ownership point. > Any bundle (more generally meta maintenance) should be owned by the core > code writer otherwise we end in weird state all the time, in particular > when parts are optionals or need some specific loading mecanism > (serviceloader for ex). The lifecycle is also an issue in time, we already > are there with features around whiteboards for ex and camel itself has a > hard time ensuring components work together so fear camel can be a bit big > to have this enrichment work done properly outside camel in a project with > less task force than camel itself. > > > > Just this. > > > > > > > > > > > > > > > > I don't see the reason why. At least the OSGi metadata should be > > > generated > > > > under camel Karaf project, instead of being part of the core > components > > > > > > > > > > I think the exact opposite since handling metadata in a 3rd always got > > > proven not working very well for end user. > > > SMix did a bunch of forks for that reason - which was enabling users > but > > > also a big constrait since users were not able to use the actual > binaries > > > for ex. > > > Having metada on the fly is a neat solution but does not work very > long, > > > even when you have a bunch of people to maintain is - graalvm metadata > > > repository is poorly usable for that reason today so for the camel > > > ecosystem it sounds impossible to do with a good quality and being able > > to > > > say "next release" at each release for end users is just not an option > - > > > but what it would mean concretely to not handle it in camel. > > > > > > > > > > > > > > I see there is a veto about moving to apache Karaf. It was already a > > mess > > > > before to maintain the features and release camel-karaf with Camel 3, > > in > > > > the end there were one contributor (myself) taking care of them, with > > > some > > > > sporadic help. I really don't have the capacity in the future. > > > > > > > > > > Guess it joins my previous point and actually justifies it should be in > > > camel project or not at the end since it looks like the status of the > > > camel-osgi ecosystem as of today - inter projects. > > > > > > > > > > > > > > If the situation is this, as Camel PMC we'll need to discuss this and > > > > eventually discontinue, deprecating or make the camel-karaf releases > > > > optional. > > > > > > > > > > +1 if there is no real ownership, better to go to attic than have a not > > > living project IMHO > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha > > > scritto: > > > > > > > > > I have a similar question on this point-- > > > > > > > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki < > l...@code-house.org> > > > > > wrote: > > > > > > > > > > > > 6) I do not see any sign of what is going to happen with OSGi > > > metadata > > > > > which is present for Apache Camel 3.x components. Is Camel 4.x > going > > to > > > > > retain OSGi metadata? > > > > > > > > > > How is maintaining OGSI metadata in Camel a concern? > > > > > > > > > > Thanks, > > > > > Matt Pavlovich > > > > > > > > > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino a écrit : > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau ha > scritto: > > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a > > écrit : > > > > > Hello, > > > > > > The point is just one in relation to OSGi metadata. The components will > > be > > > consumed, also, by runtimes that don't need OSGi metadata, so why all > the > > > components should be with OSGi metadata and packaged as bundles? > > > > > > > I'm maybe a bit dumb but why all the work and meta for quarkus and spring > > boot if the reasoning is right? > > I perfectly understand spring or quarkus have their own programming > > model/runtime so need specific code and meta but then how is OSGi > > different? > > > > A simple example is that you should be able to drop most jandex indices > if > > your statement is true. > > > > My point is related more to have the components as bundles with OSGi > metadata. To me they should be just JAR. > Mainly the reason I'm saying this about supporting camel-karaf because > the work wi be on the shoulders of 1 developer and this is not right for me > and for the community. > Sure but osgi bundles always had been designed to be just jars as much as a jar with a jandex index or even with a custom manifest metadata or a json containing the pom description ;). But I fully share with you the ownership point. Any bundle (more generally meta maintenance) should be owned by the core code writer otherwise we end in weird state all the time, in particular when parts are optionals or need some specific loading mecanism (serviceloader for ex). The lifecycle is also an issue in time, we already are there with features around whiteboards for ex and camel itself has a hard time ensuring components work together so fear camel can be a bit big to have this enrichment work done properly outside camel in a project with less task force than camel itself. > Just this. > > > > > > > > > > > I don't see the reason why. At least the OSGi metadata should be > > generated > > > under camel Karaf project, instead of being part of the core components > > > > > > > I think the exact opposite since handling metadata in a 3rd always got > > proven not working very well for end user. > > SMix did a bunch of forks for that reason - which was enabling users but > > also a big constrait since users were not able to use the actual binaries > > for ex. > > Having metada on the fly is a neat solution but does not work very long, > > even when you have a bunch of people to maintain is - graalvm metadata > > repository is poorly usable for that reason today so for the camel > > ecosystem it sounds impossible to do with a good quality and being able > to > > say "next release" at each release for end users is just not an option - > > but what it would mean concretely to not handle it in camel. > > > > > > > > > > I see there is a veto about moving to apache Karaf. It was already a > mess > > > before to maintain the features and release camel-karaf with Camel 3, > in > > > the end there were one contributor (myself) taking care of them, with > > some > > > sporadic help. I really don't have the capacity in the future. > > > > > > > Guess it joins my previous point and actually justifies it should be in > > camel project or not at the end since it looks like the status of the > > camel-osgi ecosystem as of today - inter projects. > > > > > > > > > > If the situation is this, as Camel PMC we'll need to discuss this and > > > eventually discontinue, deprecating or make the camel-karaf releases > > > optional. > > > > > > > +1 if there is no real ownership, better to go to attic than have a not > > living project IMHO > > > > > > > > > > Thanks. > > > > > > > > > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha > > scritto: > > > > > > > I have a similar question on this point-- > > > > > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > > > > wrote: > > > > > > > > > > 6) I do not see any sign of what is going to happen with OSGi > > metadata > > > > which is present for Apache Camel 3.x components. Is Camel 4.x going > to > > > > retain OSGi metadata? > > > > > > > > How is maintaining OGSI metadata in Camel a concern? > > > > > > > > Thanks, > > > > Matt Pavlovich > > > > > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Il mer 18 gen 2023, 20:06 Romain Manni-Bucau ha scritto: > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a > écrit : > > > Hello, > > > > The point is just one in relation to OSGi metadata. The components will > be > > consumed, also, by runtimes that don't need OSGi metadata, so why all the > > components should be with OSGi metadata and packaged as bundles? > > > > I'm maybe a bit dumb but why all the work and meta for quarkus and spring > boot if the reasoning is right? > I perfectly understand spring or quarkus have their own programming > model/runtime so need specific code and meta but then how is OSGi > different? > > A simple example is that you should be able to drop most jandex indices if > your statement is true. > My point is related more to have the components as bundles with OSGi metadata. To me they should be just JAR. Mainly the reason I'm saying this about supporting camel-karaf because the work wi be on the shoulders of 1 developer and this is not right for me and for the community. Just this. > > > > > > I don't see the reason why. At least the OSGi metadata should be > generated > > under camel Karaf project, instead of being part of the core components > > > > I think the exact opposite since handling metadata in a 3rd always got > proven not working very well for end user. > SMix did a bunch of forks for that reason - which was enabling users but > also a big constrait since users were not able to use the actual binaries > for ex. > Having metada on the fly is a neat solution but does not work very long, > even when you have a bunch of people to maintain is - graalvm metadata > repository is poorly usable for that reason today so for the camel > ecosystem it sounds impossible to do with a good quality and being able to > say "next release" at each release for end users is just not an option - > but what it would mean concretely to not handle it in camel. > > > > > > I see there is a veto about moving to apache Karaf. It was already a mess > > before to maintain the features and release camel-karaf with Camel 3, in > > the end there were one contributor (myself) taking care of them, with > some > > sporadic help. I really don't have the capacity in the future. > > > > Guess it joins my previous point and actually justifies it should be in > camel project or not at the end since it looks like the status of the > camel-osgi ecosystem as of today - inter projects. > > > > > > If the situation is this, as Camel PMC we'll need to discuss this and > > eventually discontinue, deprecating or make the camel-karaf releases > > optional. > > > > +1 if there is no real ownership, better to go to attic than have a not > living project IMHO > > > > > > Thanks. > > > > > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha > scritto: > > > > > I have a similar question on this point-- > > > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > > > wrote: > > > > > > > > 6) I do not see any sign of what is going to happen with OSGi > metadata > > > which is present for Apache Camel 3.x components. Is Camel 4.x going to > > > retain OSGi metadata? > > > > > > How is maintaining OGSI metadata in Camel a concern? > > > > > > Thanks, > > > Matt Pavlovich > > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
> On Jan 18, 2023, at 12:43 PM, Andrea Cosentino wrote: > > Hello, > > The point is just one in relation to OSGi metadata. The components will be > consumed, also, by runtimes that don't need OSGi metadata, so why all the > components should be with OSGi metadata and packaged as bundles? Hi Andrea- This is really the gist of my inquiry — What is the level of effort involved in maintaining OSGi metadata for Camel? From the high level it appears to be handled automatically at this point. Thanks, Matt Pavlovich
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino a écrit : > Hello, > > The point is just one in relation to OSGi metadata. The components will be > consumed, also, by runtimes that don't need OSGi metadata, so why all the > components should be with OSGi metadata and packaged as bundles? > I'm maybe a bit dumb but why all the work and meta for quarkus and spring boot if the reasoning is right? I perfectly understand spring or quarkus have their own programming model/runtime so need specific code and meta but then how is OSGi different? A simple example is that you should be able to drop most jandex indices if your statement is true. > > I don't see the reason why. At least the OSGi metadata should be generated > under camel Karaf project, instead of being part of the core components > I think the exact opposite since handling metadata in a 3rd always got proven not working very well for end user. SMix did a bunch of forks for that reason - which was enabling users but also a big constrait since users were not able to use the actual binaries for ex. Having metada on the fly is a neat solution but does not work very long, even when you have a bunch of people to maintain is - graalvm metadata repository is poorly usable for that reason today so for the camel ecosystem it sounds impossible to do with a good quality and being able to say "next release" at each release for end users is just not an option - but what it would mean concretely to not handle it in camel. > > I see there is a veto about moving to apache Karaf. It was already a mess > before to maintain the features and release camel-karaf with Camel 3, in > the end there were one contributor (myself) taking care of them, with some > sporadic help. I really don't have the capacity in the future. > Guess it joins my previous point and actually justifies it should be in camel project or not at the end since it looks like the status of the camel-osgi ecosystem as of today - inter projects. > > If the situation is this, as Camel PMC we'll need to discuss this and > eventually discontinue, deprecating or make the camel-karaf releases > optional. > +1 if there is no real ownership, better to go to attic than have a not living project IMHO > > Thanks. > > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich ha scritto: > > > I have a similar question on this point-- > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > > wrote: > > > > > > 6) I do not see any sign of what is going to happen with OSGi metadata > > which is present for Apache Camel 3.x components. Is Camel 4.x going to > > retain OSGi metadata? > > > > How is maintaining OGSI metadata in Camel a concern? > > > > Thanks, > > Matt Pavlovich >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Hello, The point is just one in relation to OSGi metadata. The components will be consumed, also, by runtimes that don't need OSGi metadata, so why all the components should be with OSGi metadata and packaged as bundles? I don't see the reason why. At least the OSGi metadata should be generated under camel Karaf project, instead of being part of the core components I see there is a veto about moving to apache Karaf. It was already a mess before to maintain the features and release camel-karaf with Camel 3, in the end there were one contributor (myself) taking care of them, with some sporadic help. I really don't have the capacity in the future. If the situation is this, as Camel PMC we'll need to discuss this and eventually discontinue, deprecating or make the camel-karaf releases optional. Thanks. Il mer 18 gen 2023, 19:27 Matt Pavlovich ha scritto: > I have a similar question on this point-- > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki > wrote: > > > > 6) I do not see any sign of what is going to happen with OSGi metadata > which is present for Apache Camel 3.x components. Is Camel 4.x going to > retain OSGi metadata? > > How is maintaining OGSI metadata in Camel a concern? > > Thanks, > Matt Pavlovich
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
I have a similar question on this point-- > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki wrote: > > 6) I do not see any sign of what is going to happen with OSGi metadata which > is present for Apache Camel 3.x components. Is Camel 4.x going to retain OSGi > metadata? How is maintaining OGSI metadata in Camel a concern? Thanks, Matt Pavlovich
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
-1 from my side Given the scope of work and possible improvements I do not see a strong reason to move camel-karaf into karaf-camel hence my veto on the proposal. This vote opens up a dangerous path where Karaf gains more fat and moves into direction of integration product on its own while, till now, it was always a lightweight runtime. Because Apache ServiceMix is still listed as Apache Software Foundation project we will end up with a functional overlap and potential release cycle between these two. Personally I miss a problem statement which such donation would solve and improve. Will we keep accepting other open source projects doing similar donations. Would we accept in Apache Karaf subprojects formed from opendaylight, opennms, atricore, openhab and more who have a plug-in components and can run under Apache Karaf? Going over points which Jean-Baptiste Onofré mentioned: 1) Maintenance and improvement of existing osgi related code of Apache Camel - does it mean that Camel does not want to maintain code which greatly contributed to its initial success? Are there any obstacles made for people who would like to do it with *camel-karaf* which would be gone with *karaf-camel*? 2) Roadmap - making a roadmap does not depend on place where code is hosted but rather on release cycle and its frequency. Given that Apache Camel has a concept of LTS releases, in some ways, it seems to be a better candidate to constitute a roadmap. 3) Does dealing with various Camel related API changes on Apache Karaf side is going to make it easier or harder to solve problems? Does problem come from Karaf or Camel components? According to my knowledge these are mostly related to third party libraries used by various components which are not determined by Apache Karaf. This means that moving components to Karaf has no positive effect as karaf-camel itself will not make a problem any different than it is for camel-karaf. 4) The documentation part - since Apache Camel has support for variety of containers and runtimes documentation might be more consistent if its less of Karaf specific and more Camel specific. There is literally one component which is tied to runtime version - which is "camel-karaf" itself which ships shell commands for Karaf. Its to little to m My additional concerns which I would like to raise are: 1) Apache Camel community is much larger and it outperforms Karaf community by number of times. There is a significant risk of quality degradation in karaf-camel compared to camel-karaf due to number of people involved on both ends. 2) Number of releases performed by Camel is larger than Karaf. This comes down to nature of things - Camel has more components which require third party dependencies and their updates. Making release cycle sticking to Camel is a one more reason why Karaf integration should stay there, especially that karaf-camel version will be dictated by a Camel, and not Karaf version. 3) Apache Camel already maintains several containers (quarkus, spring-boot); I do not see a similar push for these containers even if they could be donated back to ie. quarkiverse or given under spring source supervision, why is so? 4) Troubles which claims to be solved by donation are related to OSGi itself, almost never to Apache Karaf alone. 5) If any of camel components breaks under Karaf runtime, it is indeed a problem, but this problem of Apache Camel component and not Apache Karaf itself. It comes down to a dependency which is being declared by Camel and not Karaf. 6) I do not see any sign of what is going to happen with OSGi metadata which is present for Apache Camel 3.x components. Is Camel 4.x going to retain OSGi metadata? 7) I saw that Apache Camel recently accepted ie. Apache PLC4X component. What is a criteria for Camel project to acquire or shift things? Kind regards, Łukasz -- Code-House http://code-house.org On 18.01.2023 11:03, Jean-Baptiste Onofré wrote: Hi guys, The Apache Camel community proposed to move Camel Karaf to the Apache Karaf project (as a new subproject). As a reminder, Camel Karaf provides: - support Camel Contexts/Routes as OSGi services (camel-core-osgi) - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, ...) - wrapping of Camel components as Karaf features (providing a features repository XML) I think there are a bunch of users using camel-karaf, so, from a community perspective, it would be great to maintain it. Furthermore, I already have some ideas to improve karaf-camel, like avoiding to wrap each Camel component as an OSGi bundle, but instead creating a kind of Uber jar to simplify deployment and have more reliable behavior. Concretely, accepting camel-karaf as Karaf subproject would mean: - maintain the existing code, and improving it, preparing kind of roadmap for camel-karaf - deal with Camel versions and components (and all difficulties that it could cause in an OSGi context :) ) - maintain
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 (binding as Karaf PMC member) Freeman On Wed, Jan 18, 2023 at 5:03 AM Jean-Baptiste Onofré wrote: > Hi guys, > > The Apache Camel community proposed to move Camel Karaf to the Apache > Karaf project (as a new subproject). > > As a reminder, Camel Karaf provides: > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > ...) > - wrapping of Camel components as Karaf features (providing a features > repository XML) > > I think there are a bunch of users using camel-karaf, so, from a > community perspective, it would be great to maintain it. > Furthermore, I already have some ideas to improve karaf-camel, like > avoiding to wrap each Camel component as an OSGi bundle, but instead > creating a kind of Uber jar to simplify deployment and have more > reliable behavior. > > Concretely, accepting camel-karaf as Karaf subproject would mean: > - maintain the existing code, and improving it, preparing kind of > roadmap for camel-karaf > - deal with Camel versions and components (and all difficulties that > it could cause in an OSGi context :) ) > - maintain camel-karaf specific documentation > - vote for the releases (the PMC members would be the Karaf ones, so > binding vote from Karaf PMC members) > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > subproject to your vote: > > Please vote to approve this release: > [ ] +1 Approve camel-karaf as new Karaf subproject > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 (binding) regards, François On 18/01/2023 11:03, Jean-Baptiste Onofré wrote: Hi guys, The Apache Camel community proposed to move Camel Karaf to the Apache Karaf project (as a new subproject). As a reminder, Camel Karaf provides: - support Camel Contexts/Routes as OSGi services (camel-core-osgi) - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, ...) - wrapping of Camel components as Karaf features (providing a features repository XML) I think there are a bunch of users using camel-karaf, so, from a community perspective, it would be great to maintain it. Furthermore, I already have some ideas to improve karaf-camel, like avoiding to wrap each Camel component as an OSGi bundle, but instead creating a kind of Uber jar to simplify deployment and have more reliable behavior. Concretely, accepting camel-karaf as Karaf subproject would mean: - maintain the existing code, and improving it, preparing kind of roadmap for camel-karaf - deal with Camel versions and components (and all difficulties that it could cause in an OSGi context :) ) - maintain camel-karaf specific documentation - vote for the releases (the PMC members would be the Karaf ones, so binding vote from Karaf PMC members) I submit accepting camel-karaf (so karaf-camel :)) as new Karaf subproject to your vote: Please vote to approve this release: [ ] +1 Approve camel-karaf as new Karaf subproject [ ] -1 Don't approve camel-karaf as new Karaf subproject (please provide specific comments) This vote will be open for at least 72 hours. Thanks, Regards JB -- -- François
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 (binding) On Wed, Jan 18, 2023 at 11:03 AM Jean-Baptiste Onofré wrote: > Hi guys, > > The Apache Camel community proposed to move Camel Karaf to the Apache > Karaf project (as a new subproject). > > As a reminder, Camel Karaf provides: > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > ...) > - wrapping of Camel components as Karaf features (providing a features > repository XML) > > I think there are a bunch of users using camel-karaf, so, from a > community perspective, it would be great to maintain it. > Furthermore, I already have some ideas to improve karaf-camel, like > avoiding to wrap each Camel component as an OSGi bundle, but instead > creating a kind of Uber jar to simplify deployment and have more > reliable behavior. > > Concretely, accepting camel-karaf as Karaf subproject would mean: > - maintain the existing code, and improving it, preparing kind of > roadmap for camel-karaf > - deal with Camel versions and components (and all difficulties that > it could cause in an OSGi context :) ) > - maintain camel-karaf specific documentation > - vote for the releases (the PMC members would be the Karaf ones, so > binding vote from Karaf PMC members) > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > subproject to your vote: > > Please vote to approve this release: > [ ] +1 Approve camel-karaf as new Karaf subproject > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 (binding) Le mer. 18 janv. 2023 à 11:03, Jean-Baptiste Onofré a écrit : > Hi guys, > > The Apache Camel community proposed to move Camel Karaf to the Apache > Karaf project (as a new subproject). > > As a reminder, Camel Karaf provides: > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > ...) > - wrapping of Camel components as Karaf features (providing a features > repository XML) > > I think there are a bunch of users using camel-karaf, so, from a > community perspective, it would be great to maintain it. > Furthermore, I already have some ideas to improve karaf-camel, like > avoiding to wrap each Camel component as an OSGi bundle, but instead > creating a kind of Uber jar to simplify deployment and have more > reliable behavior. > > Concretely, accepting camel-karaf as Karaf subproject would mean: > - maintain the existing code, and improving it, preparing kind of > roadmap for camel-karaf > - deal with Camel versions and components (and all difficulties that > it could cause in an OSGi context :) ) > - maintain camel-karaf specific documentation > - vote for the releases (the PMC members would be the Karaf ones, so > binding vote from Karaf PMC members) > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > subproject to your vote: > > Please vote to approve this release: > [ ] +1 Approve camel-karaf as new Karaf subproject > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > Regards, -- Zineb Bendhiba
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
+1 (binding) -- Andrea Cosentino -- Apache Camel PMC Chair Apache Karaf Committer Apache Servicemix PMC Member Email: ancosen1...@yahoo.com Twitter: @oscerd2 Github: oscerd On Wednesday, January 18, 2023 at 11:03:27 AM GMT+1, Jean-Baptiste Onofré wrote: Hi guys, The Apache Camel community proposed to move Camel Karaf to the Apache Karaf project (as a new subproject). As a reminder, Camel Karaf provides: - support Camel Contexts/Routes as OSGi services (camel-core-osgi) - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, ...) - wrapping of Camel components as Karaf features (providing a features repository XML) I think there are a bunch of users using camel-karaf, so, from a community perspective, it would be great to maintain it. Furthermore, I already have some ideas to improve karaf-camel, like avoiding to wrap each Camel component as an OSGi bundle, but instead creating a kind of Uber jar to simplify deployment and have more reliable behavior. Concretely, accepting camel-karaf as Karaf subproject would mean: - maintain the existing code, and improving it, preparing kind of roadmap for camel-karaf - deal with Camel versions and components (and all difficulties that it could cause in an OSGi context :) ) - maintain camel-karaf specific documentation - vote for the releases (the PMC members would be the Karaf ones, so binding vote from Karaf PMC members) I submit accepting camel-karaf (so karaf-camel :)) as new Karaf subproject to your vote: Please vote to approve this release: [ ] +1 Approve camel-karaf as new Karaf subproject [ ] -1 Don't approve camel-karaf as new Karaf subproject (please provide specific comments) This vote will be open for at least 72 hours. Thanks, Regards JB
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Any hope to evaluate the "bunch" of users which would move to this new project and not spring-boot/quarkus/anything-hype-cause-$$? Can be great to see if the community wants to focus on karaf or aggregation on the long run due to available/active resources. If we have proofs there is a need and community supporters I would be +1else it can be a good bad idea as we say soletimes. Just my 2cts Le mer. 18 janv. 2023 à 13:46, Jean-Baptiste Onofré a écrit : > Correct, I mentioned this in my previous email (camel-karaf to > karaf-camel). > > Regards > JB > > On Wed, Jan 18, 2023 at 1:26 PM Claus Ibsen wrote: > > > > Hi > > > > And the source code java package names needs to be migrated as well > > org.apache.camel.karaf -> org.apache.karaf.camel > > > > And documentation is moved over to Apache Karaf, where the karaf camel > > releases its own new set of documentation/website. > > > > The existing Camel Karaf 3.x will be maintained as-is until its EOL. > > > > > > > > > > > > On Wed, Jan 18, 2023 at 12:14 PM Claus Ibsen > wrote: > > > > > Hi > > > > > > This SHOULD also mean that the project should be known as karaf-camel > > > AND that the artifacts released for download and maven central should > have > > > changed GAVs > > > > > > groupId = org.apache.karaf.camel > > > artifactId = karaf-camel-xxx > > > version = x.y.z > > > > > > For version then it may want to follow the Camel version, eg 4.0.0 > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 11:03 AM Jean-Baptiste Onofré > > > > wrote: > > > > > >> Hi guys, > > >> > > >> The Apache Camel community proposed to move Camel Karaf to the Apache > > >> Karaf project (as a new subproject). > > >> > > >> As a reminder, Camel Karaf provides: > > >> - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > > >> - Camel components specific to OSGi and Karaf (camel-blueprint, > > >> camel-scr, ...) > > >> - wrapping of Camel components as Karaf features (providing a features > > >> repository XML) > > >> > > >> I think there are a bunch of users using camel-karaf, so, from a > > >> community perspective, it would be great to maintain it. > > >> Furthermore, I already have some ideas to improve karaf-camel, like > > >> avoiding to wrap each Camel component as an OSGi bundle, but instead > > >> creating a kind of Uber jar to simplify deployment and have more > > >> reliable behavior. > > >> > > >> Concretely, accepting camel-karaf as Karaf subproject would mean: > > >> - maintain the existing code, and improving it, preparing kind of > > >> roadmap for camel-karaf > > >> - deal with Camel versions and components (and all difficulties that > > >> it could cause in an OSGi context :) ) > > >> - maintain camel-karaf specific documentation > > >> - vote for the releases (the PMC members would be the Karaf ones, so > > >> binding vote from Karaf PMC members) > > >> > > >> I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > > >> subproject to your vote: > > >> > > >> Please vote to approve this release: > > >> [ ] +1 Approve camel-karaf as new Karaf subproject > > >> [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > > >> provide specific comments) > > >> > > >> This vote will be open for at least 72 hours. > > >> > > >> Thanks, > > >> Regards > > >> JB > > >> > > > > > > > > > -- > > > Claus Ibsen > > > - > > > @davsclaus > > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > > -- > > Claus Ibsen > > - > > @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Correct, I mentioned this in my previous email (camel-karaf to karaf-camel). Regards JB On Wed, Jan 18, 2023 at 1:26 PM Claus Ibsen wrote: > > Hi > > And the source code java package names needs to be migrated as well > org.apache.camel.karaf -> org.apache.karaf.camel > > And documentation is moved over to Apache Karaf, where the karaf camel > releases its own new set of documentation/website. > > The existing Camel Karaf 3.x will be maintained as-is until its EOL. > > > > > > On Wed, Jan 18, 2023 at 12:14 PM Claus Ibsen wrote: > > > Hi > > > > This SHOULD also mean that the project should be known as karaf-camel > > AND that the artifacts released for download and maven central should have > > changed GAVs > > > > groupId = org.apache.karaf.camel > > artifactId = karaf-camel-xxx > > version = x.y.z > > > > For version then it may want to follow the Camel version, eg 4.0.0 > > > > > > > > > > > > > > On Wed, Jan 18, 2023 at 11:03 AM Jean-Baptiste Onofré > > wrote: > > > >> Hi guys, > >> > >> The Apache Camel community proposed to move Camel Karaf to the Apache > >> Karaf project (as a new subproject). > >> > >> As a reminder, Camel Karaf provides: > >> - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > >> - Camel components specific to OSGi and Karaf (camel-blueprint, > >> camel-scr, ...) > >> - wrapping of Camel components as Karaf features (providing a features > >> repository XML) > >> > >> I think there are a bunch of users using camel-karaf, so, from a > >> community perspective, it would be great to maintain it. > >> Furthermore, I already have some ideas to improve karaf-camel, like > >> avoiding to wrap each Camel component as an OSGi bundle, but instead > >> creating a kind of Uber jar to simplify deployment and have more > >> reliable behavior. > >> > >> Concretely, accepting camel-karaf as Karaf subproject would mean: > >> - maintain the existing code, and improving it, preparing kind of > >> roadmap for camel-karaf > >> - deal with Camel versions and components (and all difficulties that > >> it could cause in an OSGi context :) ) > >> - maintain camel-karaf specific documentation > >> - vote for the releases (the PMC members would be the Karaf ones, so > >> binding vote from Karaf PMC members) > >> > >> I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > >> subproject to your vote: > >> > >> Please vote to approve this release: > >> [ ] +1 Approve camel-karaf as new Karaf subproject > >> [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > >> provide specific comments) > >> > >> This vote will be open for at least 72 hours. > >> > >> Thanks, > >> Regards > >> JB > >> > > > > > > -- > > Claus Ibsen > > - > > @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > -- > Claus Ibsen > - > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Hi This SHOULD also mean that the project should be known as karaf-camel AND that the artifacts released for download and maven central should have changed GAVs groupId = org.apache.karaf.camel artifactId = karaf-camel-xxx version = x.y.z For version then it may want to follow the Camel version, eg 4.0.0 On Wed, Jan 18, 2023 at 11:03 AM Jean-Baptiste Onofré wrote: > Hi guys, > > The Apache Camel community proposed to move Camel Karaf to the Apache > Karaf project (as a new subproject). > > As a reminder, Camel Karaf provides: > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > ...) > - wrapping of Camel components as Karaf features (providing a features > repository XML) > > I think there are a bunch of users using camel-karaf, so, from a > community perspective, it would be great to maintain it. > Furthermore, I already have some ideas to improve karaf-camel, like > avoiding to wrap each Camel component as an OSGi bundle, but instead > creating a kind of Uber jar to simplify deployment and have more > reliable behavior. > > Concretely, accepting camel-karaf as Karaf subproject would mean: > - maintain the existing code, and improving it, preparing kind of > roadmap for camel-karaf > - deal with Camel versions and components (and all difficulties that > it could cause in an OSGi context :) ) > - maintain camel-karaf specific documentation > - vote for the releases (the PMC members would be the Karaf ones, so > binding vote from Karaf PMC members) > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > subproject to your vote: > > Please vote to approve this release: > [ ] +1 Approve camel-karaf as new Karaf subproject > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
Hi Andrea, yes, thanks. I forgot to mention that the move if for Camel 4.x (not the existing branch/version). Regards JB On Wed, Jan 18, 2023 at 11:05 AM Andrea Cosentino wrote: > > As as side note to what JB just wrote: > > as Apache Camel community we'll still maintain the 3.x side of the > projects, for continuity, Karaf-camel will be the house for the Camel 4.x > OSGi support. > > Thanks. > > Il giorno mer 18 gen 2023 alle ore 11:03 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > > > Hi guys, > > > > The Apache Camel community proposed to move Camel Karaf to the Apache > > Karaf project (as a new subproject). > > > > As a reminder, Camel Karaf provides: > > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > > ...) > > - wrapping of Camel components as Karaf features (providing a features > > repository XML) > > > > I think there are a bunch of users using camel-karaf, so, from a > > community perspective, it would be great to maintain it. > > Furthermore, I already have some ideas to improve karaf-camel, like > > avoiding to wrap each Camel component as an OSGi bundle, but instead > > creating a kind of Uber jar to simplify deployment and have more > > reliable behavior. > > > > Concretely, accepting camel-karaf as Karaf subproject would mean: > > - maintain the existing code, and improving it, preparing kind of > > roadmap for camel-karaf > > - deal with Camel versions and components (and all difficulties that > > it could cause in an OSGi context :) ) > > - maintain camel-karaf specific documentation > > - vote for the releases (the PMC members would be the Karaf ones, so > > binding vote from Karaf PMC members) > > > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > > subproject to your vote: > > > > Please vote to approve this release: > > [ ] +1 Approve camel-karaf as new Karaf subproject > > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > > provide specific comments) > > > > This vote will be open for at least 72 hours. > > > > Thanks, > > Regards > > JB > >
Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject
As as side note to what JB just wrote: as Apache Camel community we'll still maintain the 3.x side of the projects, for continuity, Karaf-camel will be the house for the Camel 4.x OSGi support. Thanks. Il giorno mer 18 gen 2023 alle ore 11:03 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi guys, > > The Apache Camel community proposed to move Camel Karaf to the Apache > Karaf project (as a new subproject). > > As a reminder, Camel Karaf provides: > - support Camel Contexts/Routes as OSGi services (camel-core-osgi) > - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, > ...) > - wrapping of Camel components as Karaf features (providing a features > repository XML) > > I think there are a bunch of users using camel-karaf, so, from a > community perspective, it would be great to maintain it. > Furthermore, I already have some ideas to improve karaf-camel, like > avoiding to wrap each Camel component as an OSGi bundle, but instead > creating a kind of Uber jar to simplify deployment and have more > reliable behavior. > > Concretely, accepting camel-karaf as Karaf subproject would mean: > - maintain the existing code, and improving it, preparing kind of > roadmap for camel-karaf > - deal with Camel versions and components (and all difficulties that > it could cause in an OSGi context :) ) > - maintain camel-karaf specific documentation > - vote for the releases (the PMC members would be the Karaf ones, so > binding vote from Karaf PMC members) > > I submit accepting camel-karaf (so karaf-camel :)) as new Karaf > subproject to your vote: > > Please vote to approve this release: > [ ] +1 Approve camel-karaf as new Karaf subproject > [ ] -1 Don't approve camel-karaf as new Karaf subproject (please > provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB >
[VOTE] Accept karaf-camel as new Apache Karaf subproject
Hi guys, The Apache Camel community proposed to move Camel Karaf to the Apache Karaf project (as a new subproject). As a reminder, Camel Karaf provides: - support Camel Contexts/Routes as OSGi services (camel-core-osgi) - Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, ...) - wrapping of Camel components as Karaf features (providing a features repository XML) I think there are a bunch of users using camel-karaf, so, from a community perspective, it would be great to maintain it. Furthermore, I already have some ideas to improve karaf-camel, like avoiding to wrap each Camel component as an OSGi bundle, but instead creating a kind of Uber jar to simplify deployment and have more reliable behavior. Concretely, accepting camel-karaf as Karaf subproject would mean: - maintain the existing code, and improving it, preparing kind of roadmap for camel-karaf - deal with Camel versions and components (and all difficulties that it could cause in an OSGi context :) ) - maintain camel-karaf specific documentation - vote for the releases (the PMC members would be the Karaf ones, so binding vote from Karaf PMC members) I submit accepting camel-karaf (so karaf-camel :)) as new Karaf subproject to your vote: Please vote to approve this release: [ ] +1 Approve camel-karaf as new Karaf subproject [ ] -1 Don't approve camel-karaf as new Karaf subproject (please provide specific comments) This vote will be open for at least 72 hours. Thanks, Regards JB
