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 > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
