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 > >> > >>
