Le jeu. 1 déc. 2022 à 09:15, Jean-Baptiste Onofré <j...@nanthrax.net> a écrit :
> 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). > I've been working on the jakarta migration and a JMS 3.0 broker is needed in order to test the JMS components in Camel. The fact is very simple : activemq currently does not support JMS 3.0 and artemis does. The plan to upgrade ActiveMQ to JMS 2.0 has started more than 3 years ago and there is no outcome so far. I don't think it would be wise to wait another 3 years to be able to re-enable the JMS tests in Camel. Also, upgrading to the new API won't provide the new features as indicated in https://issues.apache.org/jira/browse/AMQ-7309. > > 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. > Well, that's the point. And with the big number of major upgrades in components, I know for sure that things will be broken and there are no tests to ensure that it works in the camel-core build. That's why I was thinking about removing those from camel-core and move them back into camel-karaf somehow. > > > > 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 > > > >> > > > >> > -- ------------------------ Guillaume Nodet
