Re: Camel 4 roadmap and affect on Camel 3
Hi Any last minute feedback on the blog post before we post it? https://github.com/apache/camel-website/pull/943 On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen wrote: > 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. > > > > > > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Le jeu. 1 déc. 2022 à 09:15, Jean-Baptiste Onofré 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é > 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 > > 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 > > > > 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 > > > >> 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 > ha > > > >>> scritto: > > > >>> > > > >>>> Hi, > > > >>>> > > > >>>> For this point "Camel v4 core and component JARs will n
Re: Camel 4 roadmap and affect on Camel 3
Hi I created a draft post for a blog announcement for Camel v4 to make this more widespread known. The PR is in draft, so feedback, comments, and changes is welcome in the PR https://github.com/apache/camel-website/pull/943 -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
On Fri, Dec 9, 2022 at 2:06 PM Otavio Rodolfo Piske wrote: > Hi, > > I'm wondering if it wouldn't be better to position the 3.20 LTS release > along with JDK 17 as a better stopgap for them ... What do you think? > > The JDK 17 is such a great release with so many interesting features. I am > afraid that by still focusing on JDK 11 with Camel 4 we may limit ourselves > in how much we could push Camel forward. > > So, IMHO, I'd push for Camel 4 + JDK 17. > > Yeah that was my thoughts as well. We took a 2nd look and its harder to support JDK11 because Spring Framework 6 is Java 17+, and therefore all Camel components that uses Spring will not compile and work for Java 11. This makes it tricky to do a release for Java 11 support. And we need Spring 6 for all the Jakarta migrations. > Kind regards > > On Thu, Dec 8, 2022 at 3:32 PM Claus Ibsen wrote: > > > Hi > > > > We have received some feedback by Camel users that ask whether Camel v4 > > could initially also support JDK 11, and then at a later stage drop > JDK11. > > This will help migrate as otherwise its a "big jump" to both upgrade > JDKs, > > Camel, javax -> jakarta and what else. > > > > It would still mean JDK17 can be used by Camel end users. However there > are > > not so many compelling JDK functionality that we absolutely must use in > > Camel v4 from the start. > > So I can see the point of this. > > > > For Camel on Spring Boot, then that may mean we would need > > camel-spring-boot to be compiled as JDK17 as Spring Boot 3 must use JDK17 > > or higher. > > But I assume we can build and compile camel-core with JDK11 as we do > > currently for Camel v3. > > > > Then at some time in 2024 we could drop JDK11, after a recent LTS release > > that gives JDK11 some time for support. > > > > > > > > > > On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen > > wrote: > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > -- > > Claus Ibsen > > - > > @davsclaus > > Camel in Action 2:
Re: Camel 4 roadmap and affect on Camel 3
Hi, I'm wondering if it wouldn't be better to position the 3.20 LTS release along with JDK 17 as a better stopgap for them ... What do you think? The JDK 17 is such a great release with so many interesting features. I am afraid that by still focusing on JDK 11 with Camel 4 we may limit ourselves in how much we could push Camel forward. So, IMHO, I'd push for Camel 4 + JDK 17. Kind regards On Thu, Dec 8, 2022 at 3:32 PM Claus Ibsen wrote: > Hi > > We have received some feedback by Camel users that ask whether Camel v4 > could initially also support JDK 11, and then at a later stage drop JDK11. > This will help migrate as otherwise its a "big jump" to both upgrade JDKs, > Camel, javax -> jakarta and what else. > > It would still mean JDK17 can be used by Camel end users. However there are > not so many compelling JDK functionality that we absolutely must use in > Camel v4 from the start. > So I can see the point of this. > > For Camel on Spring Boot, then that may mean we would need > camel-spring-boot to be compiled as JDK17 as Spring Boot 3 must use JDK17 > or higher. > But I assume we can build and compile camel-core with JDK11 as we do > currently for Camel v3. > > Then at some time in 2024 we could drop JDK11, after a recent LTS release > that gives JDK11 some time for support. > > > > > On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen > wrote: > > > 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. > > > > > > > > > > > > > > -- > Claus Ibsen > - > @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Otavio R. Piske http://orpiske.net
Re: Camel 4 roadmap and affect on Camel 3
Hi We have received some feedback by Camel users that ask whether Camel v4 could initially also support JDK 11, and then at a later stage drop JDK11. This will help migrate as otherwise its a "big jump" to both upgrade JDKs, Camel, javax -> jakarta and what else. It would still mean JDK17 can be used by Camel end users. However there are not so many compelling JDK functionality that we absolutely must use in Camel v4 from the start. So I can see the point of this. For Camel on Spring Boot, then that may mean we would need camel-spring-boot to be compiled as JDK17 as Spring Boot 3 must use JDK17 or higher. But I assume we can build and compile camel-core with JDK11 as we do currently for Camel v3. Then at some time in 2024 we could drop JDK11, after a recent LTS release that gives JDK11 some time for support. On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen wrote: > 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. > > > > > > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Fully agree with "communities are the most important" On 01/12/2022 09:14, Jean-Baptiste Onofré wrote: communities are the most important -- -- François
Re: Camel 4 roadmap and affect on Camel 3
If something doesn't work with defaults then fine. Karaf feature descriptor hosted in camel-karaf can do on demand wrap and override of invalid manifest entries. Best, Łukasz On 1.12.2022 09:01, Jean-Baptiste Onofré 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 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 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 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 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é 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 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 a
Re: Camel 4 roadmap and affect on Camel 3
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é 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 > 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 > > > 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 > > >> 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 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é > > >>>>> > > >>>>> 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 > > >>>>>> proje
Re: Camel 4 roadmap and affect on Camel 3
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 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 > > 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 > >> 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 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é > >>>>> > >>>>> 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 > >&
Re: Camel 4 roadmap and affect on Camel 3
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 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 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 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é 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 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 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 i
Re: Camel 4 roadmap and affect on Camel 3
On 30.11.2022 18:15, Claus Ibsen wrote: For example if Camel Karaf support camel-ftp, then they can build and release org.apache.karaf.camel:camel-ftp-bundle:4.0.0 Sorry, but it this makes no point as class contents of that thing will be 1:1 with camel-ftp. The only one difference are manifest entries. In case of spring-boot you have configurers, in case of quarkus you have build steps and extension resources, which justify production of new artifacts. Here you have no extra contents so its really questionable if new jar needs to be produced. As I said earlier you do not need to validate metadata, you can rely on defaults. Actual checks can be done in camel-karaf. Best, Łukasz On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan 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 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 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é 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 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 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 rele
Re: Camel 4 roadmap and affect on Camel 3
On Wed, Nov 30, 2022 at 3:56 PM Matt Pavlovich wrote: > 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. > > No camel-jms has always been spring-jms based for 15 years. > Thanks, > Matt Pavlovich > > > On Nov 30, 2022, at 7:09 AM, Siano, Stephan > 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 > > 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 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é > >>>> > >>>> 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 &g
Re: Camel 4 roadmap and affect on Camel 3
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 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 > 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 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é > >>> > >>> 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 > >>>> > >>>> wrote: > >>>>> Hello > &
Re: Camel 4 roadmap and affect on Camel 3
Hey folks, On 26.11.2022 09:51, Andrea Cosentino wrote: 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. Focus from large organizations is now directed at their own runtimes which leaves OSGi behind. It was expected. I totally get your point about less maintainers, after all someone needs to pay for their work, however automated generation of metadata is almost free. What cost you time and money is validation of osgi metadata and that's something which can be deferred to camel-karaf which will construct feature files for most popular components used under osgi. I am thinking of FasterXML/Jackson which has bundle packaging in their poms, produces manifest entries, but does not verify them as a part of every day or even release build. Best, Łukasz Cheers Il ven 25 nov 2022, 15:06 Nicolas Filotto 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 Sent: Friday, November 25, 2022 11:42 To: dev 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
Re: Camel 4 roadmap and affect on Camel 3
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 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 > 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 > > 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 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é > >>>> > >>>> 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. > >>
Re: Camel 4 roadmap and affect on Camel 3
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 > 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 > 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 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é >>>> >>>> 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 &
Re: Camel 4 roadmap and affect on Camel 3
Agree On 30/11/2022 14:09, Siano, Stephan 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 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 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é 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 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 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 user
RE: Camel 4 roadmap and affect on Camel 3
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 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 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é >>> >>> 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 >>>> >>>> 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
Re: Camel 4 roadmap and affect on Camel 3
asing 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 Sent: Friday, November 25, 2022 11:42 To: dev 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://www.talend.com/privacy/> -- -- François -- -- François
Re: Camel 4 roadmap and affect on Camel 3
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 > >>>> Sent: Friday, November 25, 2022 11:42 > >>>> To: dev > >>>> 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://www.talend.com/privacy/> > >>>> > >>>> > >>>> > > > -- > -- > François > >
Re: Camel 4 roadmap and affect on Camel 3
ect: 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://www.talend.com/privacy/> -- -- François
Re: Camel 4 roadmap and affect on Camel 3
opose 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 > > > Sent: Friday, November 25, 2022 11:42 > > > To: dev > > > 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://www.talend.com/privacy/> > > > > > > > > > > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Hello Claus, +1 for this plan. As an active member of the camel-quarkus project, I'm excited to start working towards Quarkus 3. I think it's a good plan to maintain LTS releases of Camel 3 at least for 2023 and maybe a part of 2024, to give time for users to move from Java 11 and Spring 5. Regards, --- Zineb Bendhiba Le ven. 25 nov. 2022 à 11:42, Claus Ibsen a écrit : > 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. >
Re: Camel 4 roadmap and affect on Camel 3
;> 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 ? > > >>>> > > >>>> Regards > > >>>> JB > > >>>> > > >>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino > > > >>>> 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 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
Re: Camel 4 roadmap and affect on Camel 3
;> 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 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? > &
Re: Camel 4 roadmap and affect on Camel 3
ne 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 Sent: Friday, November 25, 2022 11:42 To: dev 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://www.talend.com/privacy/> -- -- François
Re: Camel 4 roadmap and affect on Camel 3
> > > 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 > > > > > Sent: Friday, November 25, 2022 11:42 > > > > > To: dev > > > > > 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://www.talend.com/privacy/> > > > > > > > > > > > > > > > > > > >
Re: Camel 4 roadmap and affect on Camel 3
ided 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 > > > > Sent: Friday, November 25, 2022 11:42 > > > > To: dev > > > > 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://www.talend.com/privacy/> > > > > > > > > > > > > > >
Re: Camel 4 roadmap and affect on Camel 3
Hello, I could be wrong, but it seems to me that even on the Karaf project side we're going to have exactly the same problem. - It will be hard to maintain - It will need to be aligned to the Camel core side - If possible on Karaf community there are far less active contributors than on the Camel community I don't really see any advantage in moving it in the Karaf realm. I just see more effort in doing so and in my opinion it won't work anyway. Il giorno lun 28 nov 2022 alle ore 10:40 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > 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 ? > > Regards > JB > > On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino > 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 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
Re: Camel 4 roadmap and affect on Camel 3
Hi Jean-Baptiste, Thank you very much for proposing to support camel-karaf directly in the Karaf project, it is a wonderful idea, I was really worried about the future of the components of camel-karaf, especially knowing that I plan to re-add some components. So it is definitely a +1 from my side. Thank you again, BR, Regards, Nicolas From: Jean-Baptiste Onofr? Sent: Monday, November 28, 2022 10:39 To: dev@camel.apache.org Subject: Re: Camel 4 roadmap and affect on Camel 3 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 ? Regards JB On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino 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 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 > > Sent: F
Re: Camel 4 roadmap and affect on Camel 3
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 ? Regards JB On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino 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 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 > > Sent: Friday, November 25, 2022 11:42 > > To: dev > > 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.
Re: Camel 4 roadmap and affect on Camel 3
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 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 > Sent: Friday, November 25, 2022 11:42 > To: dev > 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 >
Re: Camel 4 roadmap and affect on Camel 3
Hi Claus, I like the plan and I think we have something doable for Camel 4. IMHO, I think it's important for us to get ready for several upcoming releases of projects that are important to our community (Spring Boot 6, Quarkus 3, Jakarta 10). In my wish list I also have a few internal refactorings and code cleanups I would like to squeeze into the core of Camel 4, but they will definitely follow the patterns of the previous ones. They are not major things, and I still need to document them in our Jira, but I believe most of them should be doable in that timeframe. For me, the plan is a big +1. Kind regards On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen wrote: > 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. > -- Otavio R. Piske http://orpiske.net
Re: Camel 4 roadmap and affect on Camel 3
Hi There is an early start on Camel v4 work in this PR https://github.com/apache/camel/pull/8579 After the Camel 3.20 LTS release, then we should likely switch over the "main" branch to become the work branch for v4. And then have a camel-3.x branch for ongoing v3 work. When that time comes then send out [HEADS UP]. There is also a 4.0 version in JIRA with some tickets targeted https://issues.apache.org/jira/projects/CAMEL/versions/12352239 On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen wrote: > 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. > > > > > > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
On Fri, Nov 25, 2022 at 3:05 PM Nicolas Filotto wrote: > 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? > This will streetc the 3.20 too much and users will ask for any kind of stuff to creep into this release and risk things to break for other users. And Camel v4 and v3 are much more similar than what we have for v2 and v3, so backporting should be easier. > * What kind of features/improvements do you want to add to Camel 3 > after releasing 3.20? > No plan, but community may ask for a new component, or some improvements to camel-kafka, or to have a new release when there is a new release of X that requires a Camel minor release etc. The v3 LTS releases will be smaller than usual, but we have the opportunity to do these releases for a period of time so there is some overlap. > * If camel-karaf is released independently, when will it be released? > My fear is that it will be desynchronized with Camel very quickly. > There has to be an active community of users and maintainers that wants to keep it up to date all the time and do releases. OSGi is dying/dead. All the 3rd party JARs are stopping to release the OSGi manifest, and we rely on a dead ASF project (ServiceMix) to do OSGi bundle releases of 3rd party JARs. Which is really saying a lot. Users should plan to migrate to other runtimes. > * > > Yeah the camel 3 release may not go on for as long in the proposed timeline, it all depends on what we can do and need. However I really think we need Camel 3 LTS for 2023 for users on Java 11, and for users that have recently migrated to Camel 3 from 2. They may not be ready to jump quickly on Camel 4 and Java 17. Also because SB3 and Q3 and JEE10 are all so new that this will still take time to stabilize and we in Camel have other components that SB or Q may not have and this may take time for these other components to support JEE10/Java17 etc. > 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? > > Yeah we did however support 3-4 LTS per year in Camel 2. The promise is that we want to have a 6 months cycle between LTS releases so users can migrate accordingly. This is good practice that Spring Boot and other projects follow. We will only do 1 year LTS as that is also practice what others are doing. > 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. > > No, we should keep the current model with non LTS versions, that is also how Java does it. It has worked really well for Camel v3. We only use Milestone releases for big new versions like v2, v3 and v4, ... > What do you think of it? > > Thanks for the feedback > Regards, > Nicolas > ____ > From: Claus Ibsen > Sent: Friday, November 25, 2022 11:42 > To: dev > 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 ->
Re: Camel 4 roadmap and affect on Camel 3
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 Sent: Friday, November 25, 2022 11:42 To: dev 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://www.talend.com/privacy/>
Re: Camel 4 roadmap and affect on Camel 3
Hi I think after a period of review and feedback on this subject, then we should post an official blog post on the website about the roadmap and timelines. On Fri, Nov 25, 2022 at 11:42 AM Claus Ibsen wrote: > 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. > > > > > > -- Claus Ibsen - @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
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.