Just a light note about the discussion: we should definitely consider all voices in the community and also inputs from other communities. For instance, I'm a bit concerned about this one: https://issues.apache.org/jira/browse/CAMEL-18779 (it could be discussed within ActiveMQ community).
So, even if I share the technical challenges (I think we can likely always address technical issues ;)), communities are the most important. Just my €0.01 ;) Regards JB On Thu, Dec 1, 2022 at 9:01 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi guys, > > I think it won't be so painful to still include maven-bundle-plugin in > camel core, only to have OSGi headers in the MANIFEST. > However, my concern is that just maven-bundle-plugin doesn't guarantee > that the bundle is valid (we have a bunch of examples of camel > components with missing import or private, etc). > > So, it could be a best effort, but high chances that we will need to > rewrap/fix MANIFEST in camel-karaf. > > Regards > JB > > On Thu, Dec 1, 2022 at 8:46 AM Francois Papon > <francois.pa...@openobject.fr> wrote: > > > > OSGi metadata in manifest is different than Karaf feature for managing > > bundle dependencies in component integration. > > > > I think that there is no effort from Camel team to keep the > > maven-bundle-plugin from the main source modules. > > > > On 30/11/2022 18:15, Claus Ibsen wrote: > > > Camel Karaf project generates JARs for what Camel components they support > > > only - the same is what we do for Spring Boot / Quarkus / Camel Kafka > > > Connector etc. > > > JB talks about Karaf 5 with a new way of deploying that sounds like this > > > can be done smarter and easier. > > > > > > For example if Camel Karaf support camel-ftp, then they can build and > > > release > > > > > > org.apache.karaf.camel:camel-ftp-bundle:4.0.0 > > > > > > > > > > > > > > > On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan > > > <stephan.si...@sap.com.invalid> wrote: > > > > > >> 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 > > >> > > >>
