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