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