Hi, Actually removing the OSGi manifests from the bundles coming from the general camel build would mean that we have to create an OSGi wrapper bundle for each and every jar coming out of the general build, which looks like a lot of maintenance effort to me.
Best regards Stephan -----Original Message----- From: fpapon <fpa...@apache.org> Sent: Wednesday, 30 November 2022 14:01 To: dev@camel.apache.org Subject: Re: Camel 4 roadmap and affect on Camel 3 Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar just with the manifest file add-in for each camel core jar. On 30/11/2022 13:53, Andrea Cosentino wrote: > This would become something karaf-camel is responsible for. > > > > Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fpa...@apache.org> ha > scritto: > >> Hi, >> >> For this point "Camel v4 core and component JARs will no longer >> generate OSGi MANIFEST.MF" I'm not sure that removing the generation >> from the core Camel is a good thing... >> >> regards, >> >> François >> >> On 30/11/2022 10:44, Claus Ibsen wrote: >>> Hi >>> >>> >>> >>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré >>> <j...@nanthrax.net> >>> wrote: >>> >>>> Hi guys, >>>> >>>> I understand that Karaf/OSGi is not in the Camel community target >>>> anymore, and it makes sense. >>>> I proposed a time ago to refactor the approach of Camel components >>>> for Karaf, using special packaging (embedded the deps as private to >>>> avoid to have bunch of SMX bundles deps), etc. >>>> >>>> Even at Karaf, there are discussions about the next step in the >>>> project decoupled from OSGi (see Minho). >>>> >>>> I would split the discussion in two parts: >>>> - In terms of the roadmap/Camel future, I don't think it's worth it >>>> for Camel community to maintain OSGi/Karaf support anymore. It's >>>> always possible to wrap Camel routes in an uber jar and deploy in >>>> Karaf. >>>> - In terms of community/maintenance, I think camel-karaf could be >>>> part of the Karaf community. We had a similar discussion about >>>> jclouds: the jclouds community didn't want to maintain >>>> jclouds-karaf anymore (for the same reasons as the Camel >>>> community). The jclouds community asked the karaf community if they >>>> were interested in maintaining and managing jclouds-karaf. So we >>>> can do the same for camel-karaf: the karaf community can take the lead >>>> there and maintain it. >>>> >>>> Thoughts ? >>>> >>>> >>> Yes i Agree on this JB. >>> >>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project, >>> and let the community and committers in that project take over >>> maintaining >> and >>> releasing this. >>> - For Camel v4 onwards then camel-karaf will no longer be part of >>> Apache Camel. >>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel, >>> and >> no >>> longer org.apache.camel.karaf. >>> - Camel v4 core and component JARs will no longer generate OSGi >> MANIFEST.MF >>> as Karaf Camel will be responsible for this (if even needed); such >>> as JB talks about a new way of packing and running things in Karaf. >>> - For Camel v3 we keep as-is and maintain and release camel-karaf >>> until Camel 3 is EOL >>> >>> >>> >>> >>>> Regards >>>> JB >>>> >>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino >>>> <anco...@gmail.com> >>>> wrote: >>>>> Hello >>>>> >>>>> I'll come back for other questions. Let me just say that >>>>> camel-karaf is >>>> too >>>>> hard to maintain today. If it won't be released because of >> misalignments, >>>>> it should be aligned by some volunteers or community member and >> released >>>>> later. Active contributors are not really focused on Karaf runtime >>>>> and >> we >>>>> cannot do everything. This doesn't mean we won't release camel >>>>> Karaf anymore. It only means it could be released later on. Even >>>>> after the >> core >>>>> camel and SB part have been released. >>>>> >>>>> In more than one situation aligning OSGi stuff have been really hard. >>>> Less >>>>> and less community members are helping on the Karaf side and >>>>> releasing sometimes have been slow down by these troubles. Also >>>>> OSGi have been >> drop >>>>> in a lot of 3rd party libraries. >>>>> >>>>> So I'm +1 with this approach. >>>>> >>>>> I'll continue the discussion in the next days for the other points. >>>>> >>>>> Cheers >>>>> >>>>> >>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nfilo...@talend.com> ha >>>> scritto: >>>>>> Hi Claus, >>>>>> >>>>>> That sounds like a good plan, here are the first questions that I >>>>>> have >>>> in >>>>>> mind: >>>>>> >>>>>> * Why do we need to keep on releasing new LTS versions of Camel >> 3? >>>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3 >>>> and >>>>>> only maintain it? >>>>>> * What kind of features/improvements do you want to add to Camel >> 3 >>>>>> after releasing 3.20? >>>>>> * If camel-karaf is released independently, when will it be >>>> released? >>>>>> My fear is that it will be desynchronized with Camel very quickly. >>>>>> * >>>>>> >>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would >>>>>> mean 4 >>>> LTS >>>>>> versions to support at the same time, don't you think that it is >>>>>> too >>>> many? >>>>>> I'm wondering if it is not a good opportunity to rethink our LTS >>>> version >>>>>> policy. Could you please remind me why we decided to have this >>>>>> policy >>>> (2 >>>>>> LTS versions per year supported for one year)? >>>>>> >>>>>> I would personally prefer to have: >>>>>> >>>>>> * only one LTS version per year (or 2 if we keep on releasing LTS >>>>>> versions of Camel 3) but supported for at least 2 years instead >>>>>> of one otherwise Camel users are less inclined to migrate to the >>>>>> latest LTS version because 1 year of support doesn't really worth >>>>>> the migration effort, especially for big projects where the >>>>>> migration takes several months. >>>>>> * only propose milestone versions or equivalent between 2 LTS >>>> versions >>>>>> for early adopters to add more clarity on which versions are LTS. >>>> Indeed, >>>>>> for example, the next LTS version will be 3.20 while we could >>>>>> expect >>>> 3.22 >>>>>> to be the next one after 3.14 and 3.18. With this logic, instead >>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and >>>>>> 3.19, it >>>> would >>>>>> then be obvious to the Camel users that only 3.19 is an LTS >>>>>> version as >>>> all >>>>>> final versions would then be LTS versions. >>>>>> >>>>>> What do you think of it? >>>>>> >>>>>> Regards, >>>>>> Nicolas >>>>>> ________________________________ >>>>>> From: Claus Ibsen <claus.ib...@gmail.com> >>>>>> Sent: Friday, November 25, 2022 11:42 >>>>>> To: dev <dev@camel.apache.org> >>>>>> Subject: Camel 4 roadmap and affect on Camel 3 >>>>>> >>>>>> Hi >>>>>> >>>>>> This is a proposal for a plan for Apache Camel 4 and how this can >>>> affect >>>>>> Camel 3. >>>>>> >>>>>> Summary >>>>>> >>>>>> ======= >>>>>> >>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot >>>>>> less >> than >>>>>> going from Camel 2 to 3. >>>>>> >>>>>> And that we have a timebox approach where we aim for a 6 month >>>>>> period >>>> of >>>>>> work. >>>>>> >>>>>> The need for Camel v4 is mainly driven by Java open source >>>>>> projects migrating to jakarta APIs, >>>>>> >>>>>> and to keep up with popular runtimes a la Spring Boot and >>>>>> Quarkus, and >>>> to >>>>>> jump to the next major Java version. >>>>>> >>>>>> Goals >>>>>> >>>>>> ===== >>>>>> >>>>>> a) Primary Goals >>>>>> >>>>>> 1) Migrate from javax -> jakarta (JEE 10) >>>>>> >>>>>> 2) Java 17 as base line >>>>>> >>>>>> 3) Spring Framework 6 >>>>>> >>>>>> 4) Spring Boot 3 >>>>>> >>>>>> 5) Quarkus 3 >>>>>> >>>>>> b) Release Goals >>>>>> >>>>>> 6) Release only what is ready (JEE10 / Java17 etc) >>>>>> >>>>>> This means that Camel components that are not ready (yet) >>>>>> will be dropped in a release until they are ready. >>>>>> >>>>>> 7) Release core + spring boot together >>>>>> >>>>>> 8) Release camel-karaf independently (like we do for other Camel >>>> projects) >>>>>> c) Major Goals >>>>>> >>>>>> 9) Support Java 17 features such as records, multiline strings, >>>>>> and >>>> what >>>>>> else >>>>>> >>>>>> 10) EIP model without JAXB dependency >>>>>> >>>>>> 11) Endpoint URI parsing (do not use java.net.URI) >>>>>> >>>>>> 12) Deprecate message.getIn() >>>>>> >>>>>> use getMessage() instead >>>>>> >>>>>> 13) Deprecate camel-cdi >>>>>> >>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not >>>>>> fit >>>> modern >>>>>> app development) >>>>>> >>>>>> d) Minor Goals >>>>>> >>>>>> 15) Remove MEP InOptionalOut (not in use) >>>>>> >>>>>> 16) Remove JUnit 4 support >>>>>> >>>>>> >>>>>> Timeline >>>>>> >>>>>> ======= >>>>>> >>>>>> The timelines are ESTIMATES and the number of releases can vary >>>> depending >>>>>> on need and how far we are in the process >>>>>> >>>>>> Feb 2023: Camel 4.0 milestone 1 >>>>>> >>>>>> Mar 2023: Camel 4.0 milestone 2 >>>>>> >>>>>> Apr 2023: Camel 4.0 RC1 >>>>>> >>>>>> May 2023: Camel 4.0 >>>>>> >>>>>> Aug 2023: Camel 4.1 LTS >>>>>> >>>>>> Oct 2023: Camel 4.2 >>>>>> >>>>>> Dec 2023: Camel 4.3 LTS >>>>>> >>>>>> The plan is to start working on Camel 4 after the next Camel 3 >>>>>> LTS >>>> release, >>>>>> e.g. 3.20 which is planned for next month (December 2022). >>>>>> >>>>>> For Camel 3 then we slow down in releases and provide 2 LTS >>>>>> releases >>>> per >>>>>> year. >>>>>> >>>>>> For example a scheduled could look as follows: >>>>>> >>>>>> Dec 2022: Camel 3.20 LTS >>>>>> >>>>>> Jun 2023: Camel 3.21 LTS >>>>>> >>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until >>>>>> Dec >>>> 2024) >>>>>> ??? >>>>>> >>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until >>>>>> Dec >>>> 2025) >>>>>> ???? >>>>>> >>>>>> Each Camel 3 LTS release will likely also contain less new >>>>>> features >> and >>>>>> improvements as previously, as our focus and work shifts to Camel >>>>>> v4 instead. >>>>>> >>>>>> As a recipient of an email from Talend, your contact personal >>>>>> data >>>> will be >>>>>> on our systems. Please see our privacy notice. < >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 >>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s >>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d >>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8 >>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa >>>>>> Cve%2FjzzKmXVk%3D&reserved=0> >>>>>> >>>>>> >>>>>> >> -- >> -- >> François >> >> -- -- François
