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