Hi JB, Where can I find more info on this ? And can it be used already ?
Best regards, Steven On Tue, Jan 10, 2023 at 1:52 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Greg, > > yes, I introduced a new smx: protocol handler that takes a json > descriptor. This json descriptor contains: > - source artifacts > - OSGi headers > - eventually transformers (for META-INF/services, MANIFEST, etc) > > Regards > JB > > On Mon, Jan 9, 2023 at 10:30 AM Grzegorz Grzybek <gr.grzy...@gmail.com> > wrote: > > > > Hello > > > > I'd like to ask about: > > > > For SMX bundles, the objective is not to move as it is. The > > > objective it's to use the new bundle descriptor I started in Pax URL. > > > Karaf "Bundles" will host just the descriptor to create the bundle on > > > the fly (and eventually cached). The other part of SMX (assembly + > > > spec) can be moved in Karaf subproject. > > > > > > > I know that providing OSGi metadata to external 3rd party libs which do > not > > care about OSGi is a bit PITA... (I remember back in theserverside.com > days > > I suggested using external metadata instead of one kept in > > META-INF/MANIFEST.MF...) > > How do you imagine this on the fly generation? kind of like wrap: > protocol? > > > > regards > > Grzegorz Grzybek > > > > pon., 9 sty 2023 o 10:20 fpapon <fpa...@apache.org> napisał(a): > > > > > Hi JB, > > > > > > Make sense for Cave and Winegrower. > > > > > > About Camel-Karaf, as it was announced by the Camel team in the roadmap > > > to Camel 4, I was thinking that it was already acted: > > > > > > https://camel.apache.org/blog/2023/01/camel4roadmap/ > > > > > > I asked the question about the OSGi bundle still provide or not by > Camel > > > team but no clear decision, Camel team don't want to provide OSGi > bundle > > > for Camel core anymore. > > > > > > regards, > > > > > > François > > > > > > On 09/01/2023 10:13, Jean-Baptiste Onofré wrote: > > > > Hi François, > > > > > > > > Thanks for bringing this discussion. > > > > > > > > Here's my personal standpoint: > > > > 1. Decanter: I started to work on Decanter 3.x (refactoring). I think > > > > we can do a release now with just updates on the collectors/appenders > > > > before moving forward on decanter 3.x. I propose to cut new Decanter > > > > release asap. > > > > 2. Cellar: quite the same as Decanter. I plan a refactoring, but it > is > > > > worth doing an updated version (new hazelcast, kubernetes client, > > > > karaf version). Same: I propose to cut new Cellar release asp. > > > > 3. Cave: I think we don't have many users on Cave, maybe it's worth > to > > > > move the project to "attic" ? > > > > 4. Winegrower: same as Cave, I don't think we have a lot of users, > > > > maybe it's worth to move the project to "attic" ? > > > > 5. Minho: > > > > 6. For SMX bundles, the objective is not to move as it is. The > > > > objective it's to use the new bundle descriptor I started in Pax URL. > > > > Karaf "Bundles" will host just the descriptor to create the bundle on > > > > the fly (and eventually cached). The other part of SMX (assembly + > > > > spec) can be moved in Karaf subproject. > > > > 7. For camel-karaf, I'm open to community proposals. If it's better > to > > > > have it in Karaf, I'm OK with it (same question about jclouds-karaf). > > > > > > > > Regards > > > > JB > > > > > > > > On Mon, Jan 9, 2023 at 10:07 AM fpapon <fpa...@apache.org> wrote: > > > >> Hi, > > > >> > > > >> I want to start a thread about Apache Karaf subprojects roadmap and > > > >> maintainability. > > > >> > > > >> Today we have: > > > >> > > > >> - Decanter: last release on Feb. 2022 > > > >> > > > >> - Cellar: last release on Aug. 2020 > > > >> > > > >> - Cave: last release on Nov. 2019 > > > >> > > > >> We also have: > > > >> > > > >> - Winegrower: last release on Nov. 2020 > > > >> > > > >> - Minho: last release on Jan. 2023 (but plan to move to dedicated > TLP > > > >> project) > > > >> > > > >> There is also some discussion about moving SMX bundle and > Camel-Karaf as > > > >> Karaf subprojects so I think it will be nice to see what we > would/could > > > >> maintain. > > > >> > > > >> regards, > > > >> > > > >> -- > > > >> -- > > > >> François > > > >> > > > -- > > > -- > > > François > > > > > > >
