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 <anco...@gmail.com> 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 <rmannibu...@gmail.com> ha > scritto: > > > Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino <anco...@gmail.com> a > > écrit : > > > > > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau <rmannibu...@gmail.com> ha > > > scritto: > > > > > > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino <anco...@gmail.com> 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 <mattr...@gmail.com> 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 > > > > > > > > > > > > > >
