Hello, If we move camel-karaf under the Karaf project, there is no reason from the Camel point of view to provide OSGi manifests.
Karaf become a consumer of Camel releases like other projects. Il mer 30 nov 2022, 15:56 Matt Pavlovich <mattr...@gmail.com> ha scritto: > Hi All— > > What benefit comes from removing the OSGi manifest? Seems like repackaging > for Karaf could be an option, but leaving the auto-gen osgi headers in is a > good idea. A *ton* of large apps use OSGi runtimes b/c it is an effective > way to allow third parties to provide extensions and plugins. Seems odd > that Camel would prefer to opt out of that by default. > > Add’l thoughts on Camel v4— > > How about the Camel JMS component using Spring JMS be swapped out with the > Java-native one as the default for ‘jms’? This would obviously be a major > breaking change. > > Thanks, > Matt Pavlovich > > > On Nov 30, 2022, at 7:09 AM, 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 > > > >
