You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2022/11/25 10:42:11 UTC
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.
Re: Camel 4 roadmap and affect on Camel 3
Posted by Claus Ibsen <cl...@gmail.com>.
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
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> 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
Posted by Zineb Bendhiba <be...@gmail.com>.
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 <cl...@gmail.com> 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
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> 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
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> 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
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Nov 25, 2022 at 3:05 PM Nicolas Filotto <nf...@talend.com> 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 <cl...@gmail.com>
> Sent: Friday, November 25, 2022 11:42
> To: dev <de...@camel.apache.org>
> Subject: Camel 4 roadmap and affect on Camel 3
>
> Hi
>
> This is a proposal for a plan for Apache Camel 4 and how this can affect
> Camel 3.
>
> Summary
>
> =======
>
> The overall scope is that the leap from Camel 3 to 4 is a lot less than
> going from Camel 2 to 3.
>
> And that we have a timebox approach where we aim for a 6 month period of
> work.
>
> The need for Camel v4 is mainly driven by Java open source projects
> migrating to jakarta APIs,
>
> and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
> jump to the next major Java version.
>
> Goals
>
> =====
>
> a) Primary Goals
>
> 1) Migrate from javax -> jakarta (JEE 10)
>
> 2) Java 17 as base line
>
> 3) Spring Framework 6
>
> 4) Spring Boot 3
>
> 5) Quarkus 3
>
> b) Release Goals
>
> 6) Release only what is ready (JEE10 / Java17 etc)
>
> This means that Camel components that are not ready (yet) will be
> dropped in a release until they are ready.
>
> 7) Release core + spring boot together
>
> 8) Release camel-karaf independently (like we do for other Camel projects)
>
> c) Major Goals
>
> 9) Support Java 17 features such as records, multiline strings, and what
> else
>
> 10) EIP model without JAXB dependency
>
> 11) Endpoint URI parsing (do not use java.net.URI)
>
> 12) Deprecate message.getIn()
>
> use getMessage() instead
>
> 13) Deprecate camel-cdi
>
> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
> app development)
>
> d) Minor Goals
>
> 15) Remove MEP InOptionalOut (not in use)
>
> 16) Remove JUnit 4 support
>
>
> Timeline
>
> =======
>
> The timelines are ESTIMATES and the number of releases can vary depending
> on need and how far we are in the process
>
> Feb 2023: Camel 4.0 milestone 1
>
> Mar 2023: Camel 4.0 milestone 2
>
> Apr 2023: Camel 4.0 RC1
>
> May 2023: Camel 4.0
>
> Aug 2023: Camel 4.1 LTS
>
> Oct 2023: Camel 4.2
>
> Dec 2023: Camel 4.3 LTS
>
> The plan is to start working on Camel 4 after the next Camel 3 LTS release,
> e.g. 3.20 which is planned for next month (December 2022).
>
> For Camel 3 then we slow down in releases and provide 2 LTS releases per
> year.
>
> For example a scheduled could look as follows:
>
> Dec 2022: Camel 3.20 LTS
>
> Jun 2023: Camel 3.21 LTS
>
> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
> ???
>
> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
> ????
>
> Each Camel 3 LTS release will likely also contain less new features and
> improvements as previously, as our focus and work shifts to Camel v4
> instead.
>
> As a recipient of an email from Talend, your contact personal data will be
> on our systems. Please see our privacy notice. <
> https://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
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <nf...@talend.com> ha scritto:
>
>> Hi Claus,
>>
>> That sounds like a good plan, here are the first questions that I have in
>> mind:
>>
>> * Why do we need to keep on releasing new LTS versions of Camel 3?
>> * Why not simply consider 3.20 as the last LTS version of Camel 3 and
>> only maintain it?
>> * What kind of features/improvements do you want to add to Camel 3
>> after releasing 3.20?
>> * If camel-karaf is released independently, when will it be released?
>> My fear is that it will be desynchronized with Camel very quickly.
>> *
>>
>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4 LTS
>> versions to support at the same time, don't you think that it is too many?
>>
>> I'm wondering if it is not a good opportunity to rethink our LTS version
>> policy. Could you please remind me why we decided to have this policy (2
>> LTS versions per year supported for one year)?
>>
>> I would personally prefer to have:
>>
>> * only one LTS version per year (or 2 if we keep on releasing LTS
>> versions of Camel 3) but supported for at least 2 years instead of one
>> otherwise Camel users are less inclined to migrate to the latest LTS
>> version because 1 year of support doesn't really worth the migration
>> effort, especially for big projects where the migration takes several
>> months.
>> * only propose milestone versions or equivalent between 2 LTS versions
>> for early adopters to add more clarity on which versions are LTS. Indeed,
>> for example, the next LTS version will be 3.20 while we could expect 3.22
>> to be the next one after 3.14 and 3.18. With this logic, instead of
>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it would
>> then be obvious to the Camel users that only 3.19 is an LTS version as all
>> final versions would then be LTS versions.
>>
>> What do you think of it?
>>
>> Regards,
>> Nicolas
>> ________________________________
>> From: Claus Ibsen <cl...@gmail.com>
>> Sent: Friday, November 25, 2022 11:42
>> To: dev <de...@camel.apache.org>
>> Subject: Camel 4 roadmap and affect on Camel 3
>>
>> Hi
>>
>> This is a proposal for a plan for Apache Camel 4 and how this can affect
>> Camel 3.
>>
>> Summary
>>
>> =======
>>
>> The overall scope is that the leap from Camel 3 to 4 is a lot less than
>> going from Camel 2 to 3.
>>
>> And that we have a timebox approach where we aim for a 6 month period of
>> work.
>>
>> The need for Camel v4 is mainly driven by Java open source projects
>> migrating to jakarta APIs,
>>
>> and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
>> jump to the next major Java version.
>>
>> Goals
>>
>> =====
>>
>> a) Primary Goals
>>
>> 1) Migrate from javax -> jakarta (JEE 10)
>>
>> 2) Java 17 as base line
>>
>> 3) Spring Framework 6
>>
>> 4) Spring Boot 3
>>
>> 5) Quarkus 3
>>
>> b) Release Goals
>>
>> 6) Release only what is ready (JEE10 / Java17 etc)
>>
>> This means that Camel components that are not ready (yet) will be
>> dropped in a release until they are ready.
>>
>> 7) Release core + spring boot together
>>
>> 8) Release camel-karaf independently (like we do for other Camel projects)
>>
>> c) Major Goals
>>
>> 9) Support Java 17 features such as records, multiline strings, and what
>> else
>>
>> 10) EIP model without JAXB dependency
>>
>> 11) Endpoint URI parsing (do not use java.net.URI)
>>
>> 12) Deprecate message.getIn()
>>
>> use getMessage() instead
>>
>> 13) Deprecate camel-cdi
>>
>> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
>> app development)
>>
>> d) Minor Goals
>>
>> 15) Remove MEP InOptionalOut (not in use)
>>
>> 16) Remove JUnit 4 support
>>
>>
>> Timeline
>>
>> =======
>>
>> The timelines are ESTIMATES and the number of releases can vary depending
>> on need and how far we are in the process
>>
>> Feb 2023: Camel 4.0 milestone 1
>>
>> Mar 2023: Camel 4.0 milestone 2
>>
>> Apr 2023: Camel 4.0 RC1
>>
>> May 2023: Camel 4.0
>>
>> Aug 2023: Camel 4.1 LTS
>>
>> Oct 2023: Camel 4.2
>>
>> Dec 2023: Camel 4.3 LTS
>>
>> The plan is to start working on Camel 4 after the next Camel 3 LTS release,
>> e.g. 3.20 which is planned for next month (December 2022).
>>
>> For Camel 3 then we slow down in releases and provide 2 LTS releases per
>> year.
>>
>> For example a scheduled could look as follows:
>>
>> Dec 2022: Camel 3.20 LTS
>>
>> Jun 2023: Camel 3.21 LTS
>>
>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
>> ???
>>
>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
>> ????
>>
>> Each Camel 3 LTS release will likely also contain less new features and
>> improvements as previously, as our focus and work shifts to Camel v4
>> instead.
>>
>> As a recipient of an email from Talend, your contact personal data will be
>> on our systems. Please see our privacy notice. <
>> https://www.talend.com/privacy/>
>>
>>
>>
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Łukasz Dywicki <lu...@code-house.org>.
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
> <st...@sap.com.invalid> wrote:
>
>> Hi,
>>
>> Actually removing the OSGi manifests from the bundles coming from the
>> general camel build would mean that we have to create an OSGi wrapper
>> bundle for each and every jar coming out of the general build, which looks
>> like a lot of maintenance effort to me.
>>
>> Best regards
>> Stephan
>>
>> -----Original Message-----
>> From: fpapon <fp...@apache.org>
>> Sent: Wednesday, 30 November 2022 14:01
>> To: dev@camel.apache.org
>> Subject: Re: Camel 4 roadmap and affect on Camel 3
>>
>> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
>> just with the manifest file add-in for each camel core jar.
>>
>> On 30/11/2022 13:53, Andrea Cosentino wrote:
>>> This would become something karaf-camel is responsible for.
>>>
>>>
>>>
>>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
>>> scritto:
>>>
>>>> Hi,
>>>>
>>>> For this point "Camel v4 core and component JARs will no longer
>>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>>>> from the core Camel is a good thing...
>>>>
>>>> regards,
>>>>
>>>> François
>>>>
>>>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>>>> <jb...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>>>> anymore, and it makes sense.
>>>>>> I proposed a time ago to refactor the approach of Camel components
>>>>>> for Karaf, using special packaging (embedded the deps as private to
>>>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>>>
>>>>>> Even at Karaf, there are discussions about the next step in the
>>>>>> project decoupled from OSGi (see Minho).
>>>>>>
>>>>>> I would split the discussion in two parts:
>>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>>>> Karaf.
>>>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>>>> part of the Karaf community. We had a similar discussion about
>>>>>> jclouds: the jclouds community didn't want to maintain
>>>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>>>> community). The jclouds community asked the karaf community if they
>>>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>>>> can do the same for camel-karaf: the karaf community can take the
>> lead there and maintain it.
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>>
>>>>> Yes i Agree on this JB.
>>>>>
>>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>>>> and let the community and committers in that project take over
>>>>> maintaining
>>>> and
>>>>> releasing this.
>>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>>>> Apache Camel.
>>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>>>> and
>>>> no
>>>>> longer org.apache.camel.karaf.
>>>>> - Camel v4 core and component JARs will no longer generate OSGi
>>>> MANIFEST.MF
>>>>> as Karaf Camel will be responsible for this (if even needed); such
>>>>> as JB talks about a new way of packing and running things in Karaf.
>>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>>>> until Camel 3 is EOL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>>>> <an...@gmail.com>
>>>>>> wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> I'll come back for other questions. Let me just say that
>>>>>>> camel-karaf is
>>>>>> too
>>>>>>> hard to maintain today. If it won't be released because of
>>>> misalignments,
>>>>>>> it should be aligned by some volunteers or community member and
>>>> released
>>>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>>>> and
>>>> we
>>>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>>>> after the
>>>> core
>>>>>>> camel and SB part have been released.
>>>>>>>
>>>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>>>> Less
>>>>>>> and less community members are helping on the Karaf side and
>>>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>>>> OSGi have been
>>>> drop
>>>>>>> in a lot of 3rd party libraries.
>>>>>>>
>>>>>>> So I'm +1 with this approach.
>>>>>>>
>>>>>>> I'll continue the discussion in the next days for the other points.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>>>> scritto:
>>>>>>>> Hi Claus,
>>>>>>>>
>>>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>>>> have
>>>>>> in
>>>>>>>> mind:
>>>>>>>>
>>>>>>>> * Why do we need to keep on releasing new LTS versions of
>> Camel
>>>> 3?
>>>>>>>> * Why not simply consider 3.20 as the last LTS version of
>> Camel 3
>>>>>> and
>>>>>>>> only maintain it?
>>>>>>>> * What kind of features/improvements do you want to add to
>> Camel
>>>> 3
>>>>>>>> after releasing 3.20?
>>>>>>>> * If camel-karaf is released independently, when will it be
>>>>>> released?
>>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>>>> *
>>>>>>>>
>>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>>>> mean 4
>>>>>> LTS
>>>>>>>> versions to support at the same time, don't you think that it is
>>>>>>>> too
>>>>>> many?
>>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>>>> version
>>>>>>>> policy. Could you please remind me why we decided to have this
>>>>>>>> policy
>>>>>> (2
>>>>>>>> LTS versions per year supported for one year)?
>>>>>>>>
>>>>>>>> I would personally prefer to have:
>>>>>>>>
>>>>>>>> * only one LTS version per year (or 2 if we keep on releasing
>> LTS
>>>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>>>> the migration effort, especially for big projects where the
>>>>>>>> migration takes several months.
>>>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>>>> versions
>>>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>>>> Indeed,
>>>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>>>> expect
>>>>>> 3.22
>>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>>>> 3.19, it
>>>>>> would
>>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>>>> version as
>>>>>> all
>>>>>>>> final versions would then be LTS versions.
>>>>>>>>
>>>>>>>> What do you think of it?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nicolas
>>>>>>>> ________________________________
>>>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>>>> To: dev <de...@camel.apache.org>
>>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>>>> affect
>>>>>>>> Camel 3.
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> =======
>>>>>>>>
>>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>>>> less
>>>> than
>>>>>>>> going from Camel 2 to 3.
>>>>>>>>
>>>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>>>> period
>>>>>> of
>>>>>>>> work.
>>>>>>>>
>>>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>>>> projects migrating to jakarta APIs,
>>>>>>>>
>>>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>>>> Quarkus, and
>>>>>> to
>>>>>>>> jump to the next major Java version.
>>>>>>>>
>>>>>>>> Goals
>>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> a) Primary Goals
>>>>>>>>
>>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>>>
>>>>>>>> 2) Java 17 as base line
>>>>>>>>
>>>>>>>> 3) Spring Framework 6
>>>>>>>>
>>>>>>>> 4) Spring Boot 3
>>>>>>>>
>>>>>>>> 5) Quarkus 3
>>>>>>>>
>>>>>>>> b) Release Goals
>>>>>>>>
>>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>>>
>>>>>>>> This means that Camel components that are not ready (yet)
>>>>>>>> will be dropped in a release until they are ready.
>>>>>>>>
>>>>>>>> 7) Release core + spring boot together
>>>>>>>>
>>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>>>> projects)
>>>>>>>> c) Major Goals
>>>>>>>>
>>>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>>>> and
>>>>>> what
>>>>>>>> else
>>>>>>>>
>>>>>>>> 10) EIP model without JAXB dependency
>>>>>>>>
>>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>>>
>>>>>>>> 12) Deprecate message.getIn()
>>>>>>>>
>>>>>>>> use getMessage() instead
>>>>>>>>
>>>>>>>> 13) Deprecate camel-cdi
>>>>>>>>
>>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>>>> fit
>>>>>> modern
>>>>>>>> app development)
>>>>>>>>
>>>>>>>> d) Minor Goals
>>>>>>>>
>>>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>>>
>>>>>>>> 16) Remove JUnit 4 support
>>>>>>>>
>>>>>>>>
>>>>>>>> Timeline
>>>>>>>>
>>>>>>>> =======
>>>>>>>>
>>>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>>>> depending
>>>>>>>> on need and how far we are in the process
>>>>>>>>
>>>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>>>
>>>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>>>
>>>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>>>
>>>>>>>> May 2023: Camel 4.0
>>>>>>>>
>>>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>>>
>>>>>>>> Oct 2023: Camel 4.2
>>>>>>>>
>>>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>>>
>>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>>>> LTS
>>>>>> release,
>>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>>>
>>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>>>> releases
>>>>>> per
>>>>>>>> year.
>>>>>>>>
>>>>>>>> For example a scheduled could look as follows:
>>>>>>>>
>>>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>>>
>>>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>>>
>>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>>>> Dec
>>>>>> 2024)
>>>>>>>> ???
>>>>>>>>
>>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>>>> Dec
>>>>>> 2025)
>>>>>>>> ????
>>>>>>>>
>>>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>>>> features
>>>> and
>>>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>>>> v4 instead.
>>>>>>>>
>>>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>>>> data
>>>>>> will be
>>>>>>>> on our systems. Please see our privacy notice. <
>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> --
>>>> --
>>>> François
>>>>
>>>>
>> --
>> --
>> François
>>
>>
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Łukasz Dywicki <lu...@code-house.org>.
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
> <fr...@openobject.fr> wrote:
>>
>> OSGi metadata in manifest is different than Karaf feature for managing
>> bundle dependencies in component integration.
>>
>> I think that there is no effort from Camel team to keep the
>> maven-bundle-plugin from the main source modules.
>>
>> On 30/11/2022 18:15, Claus Ibsen wrote:
>>> Camel Karaf project generates JARs for what Camel components they support
>>> only - the same is what we do for Spring Boot / Quarkus / Camel Kafka
>>> Connector etc.
>>> JB talks about Karaf 5 with a new way of deploying that sounds like this
>>> can be done smarter and easier.
>>>
>>> For example if Camel Karaf support camel-ftp, then they can build and
>>> release
>>>
>>> org.apache.karaf.camel:camel-ftp-bundle:4.0.0
>>>
>>>
>>>
>>>
>>> On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan
>>> <st...@sap.com.invalid> wrote:
>>>
>>>> Hi,
>>>>
>>>> Actually removing the OSGi manifests from the bundles coming from the
>>>> general camel build would mean that we have to create an OSGi wrapper
>>>> bundle for each and every jar coming out of the general build, which looks
>>>> like a lot of maintenance effort to me.
>>>>
>>>> Best regards
>>>> Stephan
>>>>
>>>> -----Original Message-----
>>>> From: fpapon <fp...@apache.org>
>>>> Sent: Wednesday, 30 November 2022 14:01
>>>> To: dev@camel.apache.org
>>>> Subject: Re: Camel 4 roadmap and affect on Camel 3
>>>>
>>>> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
>>>> just with the manifest file add-in for each camel core jar.
>>>>
>>>> On 30/11/2022 13:53, Andrea Cosentino wrote:
>>>>> This would become something karaf-camel is responsible for.
>>>>>
>>>>>
>>>>>
>>>>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
>>>>> scritto:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> For this point "Camel v4 core and component JARs will no longer
>>>>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>>>>>> from the core Camel is a good thing...
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> François
>>>>>>
>>>>>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>>>>>> <jb...@nanthrax.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>>>>>> anymore, and it makes sense.
>>>>>>>> I proposed a time ago to refactor the approach of Camel components
>>>>>>>> for Karaf, using special packaging (embedded the deps as private to
>>>>>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>>>>>
>>>>>>>> Even at Karaf, there are discussions about the next step in the
>>>>>>>> project decoupled from OSGi (see Minho).
>>>>>>>>
>>>>>>>> I would split the discussion in two parts:
>>>>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>>>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>>>>>> Karaf.
>>>>>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>>>>>> part of the Karaf community. We had a similar discussion about
>>>>>>>> jclouds: the jclouds community didn't want to maintain
>>>>>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>>>>>> community). The jclouds community asked the karaf community if they
>>>>>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>>>>>> can do the same for camel-karaf: the karaf community can take the
>>>> lead there and maintain it.
>>>>>>>> Thoughts ?
>>>>>>>>
>>>>>>>>
>>>>>>> Yes i Agree on this JB.
>>>>>>>
>>>>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>>>>>> and let the community and committers in that project take over
>>>>>>> maintaining
>>>>>> and
>>>>>>> releasing this.
>>>>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>>>>>> Apache Camel.
>>>>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>>>>>> and
>>>>>> no
>>>>>>> longer org.apache.camel.karaf.
>>>>>>> - Camel v4 core and component JARs will no longer generate OSGi
>>>>>> MANIFEST.MF
>>>>>>> as Karaf Camel will be responsible for this (if even needed); such
>>>>>>> as JB talks about a new way of packing and running things in Karaf.
>>>>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>>>>>> until Camel 3 is EOL
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>>>>>> <an...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> I'll come back for other questions. Let me just say that
>>>>>>>>> camel-karaf is
>>>>>>>> too
>>>>>>>>> hard to maintain today. If it won't be released because of
>>>>>> misalignments,
>>>>>>>>> it should be aligned by some volunteers or community member and
>>>>>> released
>>>>>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>>>>>> and
>>>>>> we
>>>>>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>>>>>> after the
>>>>>> core
>>>>>>>>> camel and SB part have been released.
>>>>>>>>>
>>>>>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>>>>>> Less
>>>>>>>>> and less community members are helping on the Karaf side and
>>>>>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>>>>>> OSGi have been
>>>>>> drop
>>>>>>>>> in a lot of 3rd party libraries.
>>>>>>>>>
>>>>>>>>> So I'm +1 with this approach.
>>>>>>>>>
>>>>>>>>> I'll continue the discussion in the next days for the other points.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>>>>>> scritto:
>>>>>>>>>> Hi Claus,
>>>>>>>>>>
>>>>>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>>>>>> have
>>>>>>>> in
>>>>>>>>>> mind:
>>>>>>>>>>
>>>>>>>>>> * Why do we need to keep on releasing new LTS versions of
>>>> Camel
>>>>>> 3?
>>>>>>>>>> * Why not simply consider 3.20 as the last LTS version of
>>>> Camel 3
>>>>>>>> and
>>>>>>>>>> only maintain it?
>>>>>>>>>> * What kind of features/improvements do you want to add to
>>>> Camel
>>>>>> 3
>>>>>>>>>> after releasing 3.20?
>>>>>>>>>> * If camel-karaf is released independently, when will it be
>>>>>>>> released?
>>>>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>>>>>> mean 4
>>>>>>>> LTS
>>>>>>>>>> versions to support at the same time, don't you think that it is
>>>>>>>>>> too
>>>>>>>> many?
>>>>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>>>>>> version
>>>>>>>>>> policy. Could you please remind me why we decided to have this
>>>>>>>>>> policy
>>>>>>>> (2
>>>>>>>>>> LTS versions per year supported for one year)?
>>>>>>>>>>
>>>>>>>>>> I would personally prefer to have:
>>>>>>>>>>
>>>>>>>>>> * only one LTS version per year (or 2 if we keep on releasing
>>>> LTS
>>>>>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>>>>>> the migration effort, especially for big projects where the
>>>>>>>>>> migration takes several months.
>>>>>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>>>>>> versions
>>>>>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>>>>>> Indeed,
>>>>>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>>>>>> expect
>>>>>>>> 3.22
>>>>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>>>>>> 3.19, it
>>>>>>>> would
>>>>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>>>>>> version as
>>>>>>>> all
>>>>>>>>>> final versions would then be LTS versions.
>>>>>>>>>>
>>>>>>>>>> What do you think of it?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Nicolas
>>>>>>>>>> ________________________________
>>>>>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>>>>>> To: dev <de...@camel.apache.org>
>>>>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>>>>>> affect
>>>>>>>>>> Camel 3.
>>>>>>>>>>
>>>>>>>>>> Summary
>>>>>>>>>>
>>>>>>>>>> =======
>>>>>>>>>>
>>>>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>>>>>> less
>>>>>> than
>>>>>>>>>> going from Camel 2 to 3.
>>>>>>>>>>
>>>>>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>>>>>> period
>>>>>>>> of
>>>>>>>>>> work.
>>>>>>>>>>
>>>>>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>>>>>> projects migrating to jakarta APIs,
>>>>>>>>>>
>>>>>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>>>>>> Quarkus, and
>>>>>>>> to
>>>>>>>>>> jump to the next major Java version.
>>>>>>>>>>
>>>>>>>>>> Goals
>>>>>>>>>>
>>>>>>>>>> =====
>>>>>>>>>>
>>>>>>>>>> a) Primary Goals
>>>>>>>>>>
>>>>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>>>>>
>>>>>>>>>> 2) Java 17 as base line
>>>>>>>>>>
>>>>>>>>>> 3) Spring Framework 6
>>>>>>>>>>
>>>>>>>>>> 4) Spring Boot 3
>>>>>>>>>>
>>>>>>>>>> 5) Quarkus 3
>>>>>>>>>>
>>>>>>>>>> b) Release Goals
>>>>>>>>>>
>>>>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>>>>>
>>>>>>>>>> This means that Camel components that are not ready (yet)
>>>>>>>>>> will be dropped in a release until they are ready.
>>>>>>>>>>
>>>>>>>>>> 7) Release core + spring boot together
>>>>>>>>>>
>>>>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>>>>>> projects)
>>>>>>>>>> c) Major Goals
>>>>>>>>>>
>>>>>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>>>>>> and
>>>>>>>> what
>>>>>>>>>> else
>>>>>>>>>>
>>>>>>>>>> 10) EIP model without JAXB dependency
>>>>>>>>>>
>>>>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>>>>>
>>>>>>>>>> 12) Deprecate message.getIn()
>>>>>>>>>>
>>>>>>>>>> use getMessage() instead
>>>>>>>>>>
>>>>>>>>>> 13) Deprecate camel-cdi
>>>>>>>>>>
>>>>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>>>>>> fit
>>>>>>>> modern
>>>>>>>>>> app development)
>>>>>>>>>>
>>>>>>>>>> d) Minor Goals
>>>>>>>>>>
>>>>>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>>>>>
>>>>>>>>>> 16) Remove JUnit 4 support
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Timeline
>>>>>>>>>>
>>>>>>>>>> =======
>>>>>>>>>>
>>>>>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>>>>>> depending
>>>>>>>>>> on need and how far we are in the process
>>>>>>>>>>
>>>>>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>>>>>
>>>>>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>>>>>
>>>>>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>>>>>
>>>>>>>>>> May 2023: Camel 4.0
>>>>>>>>>>
>>>>>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>>>>>
>>>>>>>>>> Oct 2023: Camel 4.2
>>>>>>>>>>
>>>>>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>>>>>
>>>>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>>>>>> LTS
>>>>>>>> release,
>>>>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>>>>>
>>>>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>>>>>> releases
>>>>>>>> per
>>>>>>>>>> year.
>>>>>>>>>>
>>>>>>>>>> For example a scheduled could look as follows:
>>>>>>>>>>
>>>>>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>>>>>
>>>>>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>>>>>
>>>>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>>>>>> Dec
>>>>>>>> 2024)
>>>>>>>>>> ???
>>>>>>>>>>
>>>>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>>>>>> Dec
>>>>>>>> 2025)
>>>>>>>>>> ????
>>>>>>>>>>
>>>>>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>>>>>> features
>>>>>> and
>>>>>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>>>>>> v4 instead.
>>>>>>>>>>
>>>>>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>>>>>> data
>>>>>>>> will be
>>>>>>>>>> on our systems. Please see our privacy notice. <
>>>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> --
>>>>>> --
>>>>>> François
>>>>>>
>>>>>>
>>>> --
>>>> --
>>>> François
>>>>
>>>>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Guillaume Nodet <gn...@apache.org>.
Le jeu. 1 déc. 2022 à 09:15, Jean-Baptiste Onofré <jb...@nanthrax.net> a
écrit :
> Just a light note about the discussion: we should definitely consider
> all voices in the community and also inputs from other communities.
> For instance, I'm a bit concerned about this one:
> https://issues.apache.org/jira/browse/CAMEL-18779 (it could be
> discussed within ActiveMQ community).
>
I've been working on the jakarta migration and a JMS 3.0 broker is needed
in order to test the JMS components in Camel. The fact is very simple :
activemq currently does not support JMS 3.0 and artemis does. The plan to
upgrade ActiveMQ to JMS 2.0 has started more than 3 years ago and there is
no outcome so far. I don't think it would be wise to wait another 3 years
to be able to re-enable the JMS tests in Camel. Also, upgrading to the new
API won't provide the new features as indicated in
https://issues.apache.org/jira/browse/AMQ-7309.
>
> So, even if I share the technical challenges (I think we can likely
> always address technical issues ;)), communities are the most
> important.
>
> Just my €0.01 ;)
>
> Regards
> JB
>
> On Thu, Dec 1, 2022 at 9:01 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > Hi guys,
> >
> > I think it won't be so painful to still include maven-bundle-plugin in
> > camel core, only to have OSGi headers in the MANIFEST.
> > However, my concern is that just maven-bundle-plugin doesn't guarantee
> > that the bundle is valid (we have a bunch of examples of camel
> > components with missing import or private, etc).
> >
> > So, it could be a best effort, but high chances that we will need to
> > rewrap/fix MANIFEST in camel-karaf.
>
Well, that's the point. And with the big number of major upgrades in
components, I know for sure that things will be broken and there are
no tests to ensure that it works in the camel-core build. That's why I was
thinking about removing those from camel-core and move them back into
camel-karaf somehow.
> >
> > Regards
> > JB
> >
> > On Thu, Dec 1, 2022 at 8:46 AM Francois Papon
> > <fr...@openobject.fr> wrote:
> > >
> > > OSGi metadata in manifest is different than Karaf feature for managing
> > > bundle dependencies in component integration.
> > >
> > > I think that there is no effort from Camel team to keep the
> > > maven-bundle-plugin from the main source modules.
> > >
> > > On 30/11/2022 18:15, Claus Ibsen wrote:
> > > > Camel Karaf project generates JARs for what Camel components they
> support
> > > > only - the same is what we do for Spring Boot / Quarkus / Camel Kafka
> > > > Connector etc.
> > > > JB talks about Karaf 5 with a new way of deploying that sounds like
> this
> > > > can be done smarter and easier.
> > > >
> > > > For example if Camel Karaf support camel-ftp, then they can build and
> > > > release
> > > >
> > > > org.apache.karaf.camel:camel-ftp-bundle:4.0.0
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan
> > > > <st...@sap.com.invalid> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Actually removing the OSGi manifests from the bundles coming from
> the
> > > >> general camel build would mean that we have to create an OSGi
> wrapper
> > > >> bundle for each and every jar coming out of the general build,
> which looks
> > > >> like a lot of maintenance effort to me.
> > > >>
> > > >> Best regards
> > > >> Stephan
> > > >>
> > > >> -----Original Message-----
> > > >> From: fpapon <fp...@apache.org>
> > > >> Sent: Wednesday, 30 November 2022 14:01
> > > >> To: dev@camel.apache.org
> > > >> Subject: Re: Camel 4 roadmap and affect on Camel 3
> > > >>
> > > >> Ok so we will have a camel-core.jar and
> camel-core-with-manifest-osgi.jar
> > > >> just with the manifest file add-in for each camel core jar.
> > > >>
> > > >> On 30/11/2022 13:53, Andrea Cosentino wrote:
> > > >>> This would become something karaf-camel is responsible for.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org>
> ha
> > > >>> scritto:
> > > >>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> For this point "Camel v4 core and component JARs will no longer
> > > >>>> generate OSGi MANIFEST.MF" I'm not sure that removing the
> generation
> > > >>>> from the core Camel is a good thing...
> > > >>>>
> > > >>>> regards,
> > > >>>>
> > > >>>> François
> > > >>>>
> > > >>>> On 30/11/2022 10:44, Claus Ibsen wrote:
> > > >>>>> Hi
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> > > >>>>> <jb...@nanthrax.net>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hi guys,
> > > >>>>>>
> > > >>>>>> I understand that Karaf/OSGi is not in the Camel community
> target
> > > >>>>>> anymore, and it makes sense.
> > > >>>>>> I proposed a time ago to refactor the approach of Camel
> components
> > > >>>>>> for Karaf, using special packaging (embedded the deps as
> private to
> > > >>>>>> avoid to have bunch of SMX bundles deps), etc.
> > > >>>>>>
> > > >>>>>> Even at Karaf, there are discussions about the next step in the
> > > >>>>>> project decoupled from OSGi (see Minho).
> > > >>>>>>
> > > >>>>>> I would split the discussion in two parts:
> > > >>>>>> - In terms of the roadmap/Camel future, I don't think it's
> worth it
> > > >>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> > > >>>>>> always possible to wrap Camel routes in an uber jar and deploy
> in
> > > >>>>>> Karaf.
> > > >>>>>> - In terms of community/maintenance, I think camel-karaf could
> be
> > > >>>>>> part of the Karaf community. We had a similar discussion about
> > > >>>>>> jclouds: the jclouds community didn't want to maintain
> > > >>>>>> jclouds-karaf anymore (for the same reasons as the Camel
> > > >>>>>> community). The jclouds community asked the karaf community if
> they
> > > >>>>>> were interested in maintaining and managing jclouds-karaf. So we
> > > >>>>>> can do the same for camel-karaf: the karaf community can take
> the
> > > >> lead there and maintain it.
> > > >>>>>> Thoughts ?
> > > >>>>>>
> > > >>>>>>
> > > >>>>> Yes i Agree on this JB.
> > > >>>>>
> > > >>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel
> sub-project,
> > > >>>>> and let the community and committers in that project take over
> > > >>>>> maintaining
> > > >>>> and
> > > >>>>> releasing this.
> > > >>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
> > > >>>>> Apache Camel.
> > > >>>>> - Karaf Camel is released under a new GAV -
> org.apache.karaf.camel,
> > > >>>>> and
> > > >>>> no
> > > >>>>> longer org.apache.camel.karaf.
> > > >>>>> - Camel v4 core and component JARs will no longer generate OSGi
> > > >>>> MANIFEST.MF
> > > >>>>> as Karaf Camel will be responsible for this (if even needed);
> such
> > > >>>>> as JB talks about a new way of packing and running things in
> Karaf.
> > > >>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> > > >>>>> until Camel 3 is EOL
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> Regards
> > > >>>>>> JB
> > > >>>>>>
> > > >>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> > > >>>>>> <an...@gmail.com>
> > > >>>>>> wrote:
> > > >>>>>>> Hello
> > > >>>>>>>
> > > >>>>>>> I'll come back for other questions. Let me just say that
> > > >>>>>>> camel-karaf is
> > > >>>>>> too
> > > >>>>>>> hard to maintain today. If it won't be released because of
> > > >>>> misalignments,
> > > >>>>>>> it should be aligned by some volunteers or community member and
> > > >>>> released
> > > >>>>>>> later. Active contributors are not really focused on Karaf
> runtime
> > > >>>>>>> and
> > > >>>> we
> > > >>>>>>> cannot do everything. This doesn't mean we won't release camel
> > > >>>>>>> Karaf anymore. It only means it could be released later on.
> Even
> > > >>>>>>> after the
> > > >>>> core
> > > >>>>>>> camel and SB part have been released.
> > > >>>>>>>
> > > >>>>>>> In more than one situation aligning OSGi stuff have been
> really hard.
> > > >>>>>> Less
> > > >>>>>>> and less community members are helping on the Karaf side and
> > > >>>>>>> releasing sometimes have been slow down by these troubles. Also
> > > >>>>>>> OSGi have been
> > > >>>> drop
> > > >>>>>>> in a lot of 3rd party libraries.
> > > >>>>>>>
> > > >>>>>>> So I'm +1 with this approach.
> > > >>>>>>>
> > > >>>>>>> I'll continue the discussion in the next days for the other
> points.
> > > >>>>>>>
> > > >>>>>>> Cheers
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com>
> ha
> > > >>>>>> scritto:
> > > >>>>>>>> Hi Claus,
> > > >>>>>>>>
> > > >>>>>>>> That sounds like a good plan, here are the first questions
> that I
> > > >>>>>>>> have
> > > >>>>>> in
> > > >>>>>>>> mind:
> > > >>>>>>>>
> > > >>>>>>>> * Why do we need to keep on releasing new LTS versions
> of
> > > >> Camel
> > > >>>> 3?
> > > >>>>>>>> * Why not simply consider 3.20 as the last LTS version
> of
> > > >> Camel 3
> > > >>>>>> and
> > > >>>>>>>> only maintain it?
> > > >>>>>>>> * What kind of features/improvements do you want to
> add to
> > > >> Camel
> > > >>>> 3
> > > >>>>>>>> after releasing 3.20?
> > > >>>>>>>> * If camel-karaf is released independently, when will
> it be
> > > >>>>>> released?
> > > >>>>>>>> My fear is that it will be desynchronized with Camel very
> quickly.
> > > >>>>>>>> *
> > > >>>>>>>>
> > > >>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> > > >>>>>>>> mean 4
> > > >>>>>> LTS
> > > >>>>>>>> versions to support at the same time, don't you think that it
> is
> > > >>>>>>>> too
> > > >>>>>> many?
> > > >>>>>>>> I'm wondering if it is not a good opportunity to rethink our
> LTS
> > > >>>>>> version
> > > >>>>>>>> policy. Could you please remind me why we decided to have this
> > > >>>>>>>> policy
> > > >>>>>> (2
> > > >>>>>>>> LTS versions per year supported for one year)?
> > > >>>>>>>>
> > > >>>>>>>> I would personally prefer to have:
> > > >>>>>>>>
> > > >>>>>>>> * only one LTS version per year (or 2 if we keep on
> releasing
> > > >> LTS
> > > >>>>>>>> versions of Camel 3) but supported for at least 2 years
> instead
> > > >>>>>>>> of one otherwise Camel users are less inclined to migrate to
> the
> > > >>>>>>>> latest LTS version because 1 year of support doesn't really
> worth
> > > >>>>>>>> the migration effort, especially for big projects where the
> > > >>>>>>>> migration takes several months.
> > > >>>>>>>> * only propose milestone versions or equivalent
> between 2 LTS
> > > >>>>>> versions
> > > >>>>>>>> for early adopters to add more clarity on which versions are
> LTS.
> > > >>>>>> Indeed,
> > > >>>>>>>> for example, the next LTS version will be 3.20 while we could
> > > >>>>>>>> expect
> > > >>>>>> 3.22
> > > >>>>>>>> to be the next one after 3.14 and 3.18. With this logic,
> instead
> > > >>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> > > >>>>>>>> 3.19, it
> > > >>>>>> would
> > > >>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> > > >>>>>>>> version as
> > > >>>>>> all
> > > >>>>>>>> final versions would then be LTS versions.
> > > >>>>>>>>
> > > >>>>>>>> What do you think of it?
> > > >>>>>>>>
> > > >>>>>>>> Regards,
> > > >>>>>>>> Nicolas
> > > >>>>>>>> ________________________________
> > > >>>>>>>> From: Claus Ibsen <cl...@gmail.com>
> > > >>>>>>>> Sent: Friday, November 25, 2022 11:42
> > > >>>>>>>> To: dev <de...@camel.apache.org>
> > > >>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> > > >>>>>>>>
> > > >>>>>>>> Hi
> > > >>>>>>>>
> > > >>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this
> can
> > > >>>>>> affect
> > > >>>>>>>> Camel 3.
> > > >>>>>>>>
> > > >>>>>>>> Summary
> > > >>>>>>>>
> > > >>>>>>>> =======
> > > >>>>>>>>
> > > >>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> > > >>>>>>>> less
> > > >>>> than
> > > >>>>>>>> going from Camel 2 to 3.
> > > >>>>>>>>
> > > >>>>>>>> And that we have a timebox approach where we aim for a 6 month
> > > >>>>>>>> period
> > > >>>>>> of
> > > >>>>>>>> work.
> > > >>>>>>>>
> > > >>>>>>>> The need for Camel v4 is mainly driven by Java open source
> > > >>>>>>>> projects migrating to jakarta APIs,
> > > >>>>>>>>
> > > >>>>>>>> and to keep up with popular runtimes a la Spring Boot and
> > > >>>>>>>> Quarkus, and
> > > >>>>>> to
> > > >>>>>>>> jump to the next major Java version.
> > > >>>>>>>>
> > > >>>>>>>> Goals
> > > >>>>>>>>
> > > >>>>>>>> =====
> > > >>>>>>>>
> > > >>>>>>>> a) Primary Goals
> > > >>>>>>>>
> > > >>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> > > >>>>>>>>
> > > >>>>>>>> 2) Java 17 as base line
> > > >>>>>>>>
> > > >>>>>>>> 3) Spring Framework 6
> > > >>>>>>>>
> > > >>>>>>>> 4) Spring Boot 3
> > > >>>>>>>>
> > > >>>>>>>> 5) Quarkus 3
> > > >>>>>>>>
> > > >>>>>>>> b) Release Goals
> > > >>>>>>>>
> > > >>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> > > >>>>>>>>
> > > >>>>>>>> This means that Camel components that are not ready
> (yet)
> > > >>>>>>>> will be dropped in a release until they are ready.
> > > >>>>>>>>
> > > >>>>>>>> 7) Release core + spring boot together
> > > >>>>>>>>
> > > >>>>>>>> 8) Release camel-karaf independently (like we do for other
> Camel
> > > >>>>>> projects)
> > > >>>>>>>> c) Major Goals
> > > >>>>>>>>
> > > >>>>>>>> 9) Support Java 17 features such as records, multiline
> strings,
> > > >>>>>>>> and
> > > >>>>>> what
> > > >>>>>>>> else
> > > >>>>>>>>
> > > >>>>>>>> 10) EIP model without JAXB dependency
> > > >>>>>>>>
> > > >>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> > > >>>>>>>>
> > > >>>>>>>> 12) Deprecate message.getIn()
> > > >>>>>>>>
> > > >>>>>>>> use getMessage() instead
> > > >>>>>>>>
> > > >>>>>>>> 13) Deprecate camel-cdi
> > > >>>>>>>>
> > > >>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does
> not
> > > >>>>>>>> fit
> > > >>>>>> modern
> > > >>>>>>>> app development)
> > > >>>>>>>>
> > > >>>>>>>> d) Minor Goals
> > > >>>>>>>>
> > > >>>>>>>> 15) Remove MEP InOptionalOut (not in use)
> > > >>>>>>>>
> > > >>>>>>>> 16) Remove JUnit 4 support
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Timeline
> > > >>>>>>>>
> > > >>>>>>>> =======
> > > >>>>>>>>
> > > >>>>>>>> The timelines are ESTIMATES and the number of releases can
> vary
> > > >>>>>> depending
> > > >>>>>>>> on need and how far we are in the process
> > > >>>>>>>>
> > > >>>>>>>> Feb 2023: Camel 4.0 milestone 1
> > > >>>>>>>>
> > > >>>>>>>> Mar 2023: Camel 4.0 milestone 2
> > > >>>>>>>>
> > > >>>>>>>> Apr 2023: Camel 4.0 RC1
> > > >>>>>>>>
> > > >>>>>>>> May 2023: Camel 4.0
> > > >>>>>>>>
> > > >>>>>>>> Aug 2023: Camel 4.1 LTS
> > > >>>>>>>>
> > > >>>>>>>> Oct 2023: Camel 4.2
> > > >>>>>>>>
> > > >>>>>>>> Dec 2023: Camel 4.3 LTS
> > > >>>>>>>>
> > > >>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
> > > >>>>>>>> LTS
> > > >>>>>> release,
> > > >>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
> > > >>>>>>>>
> > > >>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> > > >>>>>>>> releases
> > > >>>>>> per
> > > >>>>>>>> year.
> > > >>>>>>>>
> > > >>>>>>>> For example a scheduled could look as follows:
> > > >>>>>>>>
> > > >>>>>>>> Dec 2022: Camel 3.20 LTS
> > > >>>>>>>>
> > > >>>>>>>> Jun 2023: Camel 3.21 LTS
> > > >>>>>>>>
> > > >>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported
> until
> > > >>>>>>>> Dec
> > > >>>>>> 2024)
> > > >>>>>>>> ???
> > > >>>>>>>>
> > > >>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported
> until
> > > >>>>>>>> Dec
> > > >>>>>> 2025)
> > > >>>>>>>> ????
> > > >>>>>>>>
> > > >>>>>>>> Each Camel 3 LTS release will likely also contain less new
> > > >>>>>>>> features
> > > >>>> and
> > > >>>>>>>> improvements as previously, as our focus and work shifts to
> Camel
> > > >>>>>>>> v4 instead.
> > > >>>>>>>>
> > > >>>>>>>> As a recipient of an email from Talend, your contact personal
> > > >>>>>>>> data
> > > >>>>>> will be
> > > >>>>>>>> on our systems. Please see our privacy notice. <
> > > >>>>>>>>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > >>>>>>>> Fwww.talend.com
> %2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> > > >>>>>>>> ap.com
> %7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> > > >>>>>>>>
> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> > > >>>>>>>>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > >>>>>>>>
> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> > > >>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>> --
> > > >>>> --
> > > >>>> François
> > > >>>>
> > > >>>>
> > > >> --
> > > >> --
> > > >> François
> > > >>
> > > >>
>
--
------------------------
Guillaume Nodet
Re: Camel 4 roadmap and affect on Camel 3
Posted by fpapon <fp...@apache.org>.
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
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net> wrote:
>
> Hi guys,
>
> I think it won't be so painful to still include maven-bundle-plugin in
> camel core, only to have OSGi headers in the MANIFEST.
> However, my concern is that just maven-bundle-plugin doesn't guarantee
> that the bundle is valid (we have a bunch of examples of camel
> components with missing import or private, etc).
>
> So, it could be a best effort, but high chances that we will need to
> rewrap/fix MANIFEST in camel-karaf.
>
> Regards
> JB
>
> On Thu, Dec 1, 2022 at 8:46 AM Francois Papon
> <fr...@openobject.fr> wrote:
> >
> > OSGi metadata in manifest is different than Karaf feature for managing
> > bundle dependencies in component integration.
> >
> > I think that there is no effort from Camel team to keep the
> > maven-bundle-plugin from the main source modules.
> >
> > On 30/11/2022 18:15, Claus Ibsen wrote:
> > > Camel Karaf project generates JARs for what Camel components they support
> > > only - the same is what we do for Spring Boot / Quarkus / Camel Kafka
> > > Connector etc.
> > > JB talks about Karaf 5 with a new way of deploying that sounds like this
> > > can be done smarter and easier.
> > >
> > > For example if Camel Karaf support camel-ftp, then they can build and
> > > release
> > >
> > > org.apache.karaf.camel:camel-ftp-bundle:4.0.0
> > >
> > >
> > >
> > >
> > > On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan
> > > <st...@sap.com.invalid> wrote:
> > >
> > >> Hi,
> > >>
> > >> Actually removing the OSGi manifests from the bundles coming from the
> > >> general camel build would mean that we have to create an OSGi wrapper
> > >> bundle for each and every jar coming out of the general build, which looks
> > >> like a lot of maintenance effort to me.
> > >>
> > >> Best regards
> > >> Stephan
> > >>
> > >> -----Original Message-----
> > >> From: fpapon <fp...@apache.org>
> > >> Sent: Wednesday, 30 November 2022 14:01
> > >> To: dev@camel.apache.org
> > >> Subject: Re: Camel 4 roadmap and affect on Camel 3
> > >>
> > >> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
> > >> just with the manifest file add-in for each camel core jar.
> > >>
> > >> On 30/11/2022 13:53, Andrea Cosentino wrote:
> > >>> This would become something karaf-camel is responsible for.
> > >>>
> > >>>
> > >>>
> > >>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> > >>> scritto:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> For this point "Camel v4 core and component JARs will no longer
> > >>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
> > >>>> from the core Camel is a good thing...
> > >>>>
> > >>>> regards,
> > >>>>
> > >>>> François
> > >>>>
> > >>>> On 30/11/2022 10:44, Claus Ibsen wrote:
> > >>>>> Hi
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> > >>>>> <jb...@nanthrax.net>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hi guys,
> > >>>>>>
> > >>>>>> I understand that Karaf/OSGi is not in the Camel community target
> > >>>>>> anymore, and it makes sense.
> > >>>>>> I proposed a time ago to refactor the approach of Camel components
> > >>>>>> for Karaf, using special packaging (embedded the deps as private to
> > >>>>>> avoid to have bunch of SMX bundles deps), etc.
> > >>>>>>
> > >>>>>> Even at Karaf, there are discussions about the next step in the
> > >>>>>> project decoupled from OSGi (see Minho).
> > >>>>>>
> > >>>>>> I would split the discussion in two parts:
> > >>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
> > >>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> > >>>>>> always possible to wrap Camel routes in an uber jar and deploy in
> > >>>>>> Karaf.
> > >>>>>> - In terms of community/maintenance, I think camel-karaf could be
> > >>>>>> part of the Karaf community. We had a similar discussion about
> > >>>>>> jclouds: the jclouds community didn't want to maintain
> > >>>>>> jclouds-karaf anymore (for the same reasons as the Camel
> > >>>>>> community). The jclouds community asked the karaf community if they
> > >>>>>> were interested in maintaining and managing jclouds-karaf. So we
> > >>>>>> can do the same for camel-karaf: the karaf community can take the
> > >> lead there and maintain it.
> > >>>>>> Thoughts ?
> > >>>>>>
> > >>>>>>
> > >>>>> Yes i Agree on this JB.
> > >>>>>
> > >>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
> > >>>>> and let the community and committers in that project take over
> > >>>>> maintaining
> > >>>> and
> > >>>>> releasing this.
> > >>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
> > >>>>> Apache Camel.
> > >>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
> > >>>>> and
> > >>>> no
> > >>>>> longer org.apache.camel.karaf.
> > >>>>> - Camel v4 core and component JARs will no longer generate OSGi
> > >>>> MANIFEST.MF
> > >>>>> as Karaf Camel will be responsible for this (if even needed); such
> > >>>>> as JB talks about a new way of packing and running things in Karaf.
> > >>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> > >>>>> until Camel 3 is EOL
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Regards
> > >>>>>> JB
> > >>>>>>
> > >>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> > >>>>>> <an...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>> Hello
> > >>>>>>>
> > >>>>>>> I'll come back for other questions. Let me just say that
> > >>>>>>> camel-karaf is
> > >>>>>> too
> > >>>>>>> hard to maintain today. If it won't be released because of
> > >>>> misalignments,
> > >>>>>>> it should be aligned by some volunteers or community member and
> > >>>> released
> > >>>>>>> later. Active contributors are not really focused on Karaf runtime
> > >>>>>>> and
> > >>>> we
> > >>>>>>> cannot do everything. This doesn't mean we won't release camel
> > >>>>>>> Karaf anymore. It only means it could be released later on. Even
> > >>>>>>> after the
> > >>>> core
> > >>>>>>> camel and SB part have been released.
> > >>>>>>>
> > >>>>>>> In more than one situation aligning OSGi stuff have been really hard.
> > >>>>>> Less
> > >>>>>>> and less community members are helping on the Karaf side and
> > >>>>>>> releasing sometimes have been slow down by these troubles. Also
> > >>>>>>> OSGi have been
> > >>>> drop
> > >>>>>>> in a lot of 3rd party libraries.
> > >>>>>>>
> > >>>>>>> So I'm +1 with this approach.
> > >>>>>>>
> > >>>>>>> I'll continue the discussion in the next days for the other points.
> > >>>>>>>
> > >>>>>>> Cheers
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> > >>>>>> scritto:
> > >>>>>>>> Hi Claus,
> > >>>>>>>>
> > >>>>>>>> That sounds like a good plan, here are the first questions that I
> > >>>>>>>> have
> > >>>>>> in
> > >>>>>>>> mind:
> > >>>>>>>>
> > >>>>>>>> * Why do we need to keep on releasing new LTS versions of
> > >> Camel
> > >>>> 3?
> > >>>>>>>> * Why not simply consider 3.20 as the last LTS version of
> > >> Camel 3
> > >>>>>> and
> > >>>>>>>> only maintain it?
> > >>>>>>>> * What kind of features/improvements do you want to add to
> > >> Camel
> > >>>> 3
> > >>>>>>>> after releasing 3.20?
> > >>>>>>>> * If camel-karaf is released independently, when will it be
> > >>>>>> released?
> > >>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
> > >>>>>>>> *
> > >>>>>>>>
> > >>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> > >>>>>>>> mean 4
> > >>>>>> LTS
> > >>>>>>>> versions to support at the same time, don't you think that it is
> > >>>>>>>> too
> > >>>>>> many?
> > >>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> > >>>>>> version
> > >>>>>>>> policy. Could you please remind me why we decided to have this
> > >>>>>>>> policy
> > >>>>>> (2
> > >>>>>>>> LTS versions per year supported for one year)?
> > >>>>>>>>
> > >>>>>>>> I would personally prefer to have:
> > >>>>>>>>
> > >>>>>>>> * only one LTS version per year (or 2 if we keep on releasing
> > >> LTS
> > >>>>>>>> versions of Camel 3) but supported for at least 2 years instead
> > >>>>>>>> of one otherwise Camel users are less inclined to migrate to the
> > >>>>>>>> latest LTS version because 1 year of support doesn't really worth
> > >>>>>>>> the migration effort, especially for big projects where the
> > >>>>>>>> migration takes several months.
> > >>>>>>>> * only propose milestone versions or equivalent between 2 LTS
> > >>>>>> versions
> > >>>>>>>> for early adopters to add more clarity on which versions are LTS.
> > >>>>>> Indeed,
> > >>>>>>>> for example, the next LTS version will be 3.20 while we could
> > >>>>>>>> expect
> > >>>>>> 3.22
> > >>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> > >>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> > >>>>>>>> 3.19, it
> > >>>>>> would
> > >>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> > >>>>>>>> version as
> > >>>>>> all
> > >>>>>>>> final versions would then be LTS versions.
> > >>>>>>>>
> > >>>>>>>> What do you think of it?
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>> Nicolas
> > >>>>>>>> ________________________________
> > >>>>>>>> From: Claus Ibsen <cl...@gmail.com>
> > >>>>>>>> Sent: Friday, November 25, 2022 11:42
> > >>>>>>>> To: dev <de...@camel.apache.org>
> > >>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> > >>>>>>>>
> > >>>>>>>> Hi
> > >>>>>>>>
> > >>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> > >>>>>> affect
> > >>>>>>>> Camel 3.
> > >>>>>>>>
> > >>>>>>>> Summary
> > >>>>>>>>
> > >>>>>>>> =======
> > >>>>>>>>
> > >>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> > >>>>>>>> less
> > >>>> than
> > >>>>>>>> going from Camel 2 to 3.
> > >>>>>>>>
> > >>>>>>>> And that we have a timebox approach where we aim for a 6 month
> > >>>>>>>> period
> > >>>>>> of
> > >>>>>>>> work.
> > >>>>>>>>
> > >>>>>>>> The need for Camel v4 is mainly driven by Java open source
> > >>>>>>>> projects migrating to jakarta APIs,
> > >>>>>>>>
> > >>>>>>>> and to keep up with popular runtimes a la Spring Boot and
> > >>>>>>>> Quarkus, and
> > >>>>>> to
> > >>>>>>>> jump to the next major Java version.
> > >>>>>>>>
> > >>>>>>>> Goals
> > >>>>>>>>
> > >>>>>>>> =====
> > >>>>>>>>
> > >>>>>>>> a) Primary Goals
> > >>>>>>>>
> > >>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> > >>>>>>>>
> > >>>>>>>> 2) Java 17 as base line
> > >>>>>>>>
> > >>>>>>>> 3) Spring Framework 6
> > >>>>>>>>
> > >>>>>>>> 4) Spring Boot 3
> > >>>>>>>>
> > >>>>>>>> 5) Quarkus 3
> > >>>>>>>>
> > >>>>>>>> b) Release Goals
> > >>>>>>>>
> > >>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> > >>>>>>>>
> > >>>>>>>> This means that Camel components that are not ready (yet)
> > >>>>>>>> will be dropped in a release until they are ready.
> > >>>>>>>>
> > >>>>>>>> 7) Release core + spring boot together
> > >>>>>>>>
> > >>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
> > >>>>>> projects)
> > >>>>>>>> c) Major Goals
> > >>>>>>>>
> > >>>>>>>> 9) Support Java 17 features such as records, multiline strings,
> > >>>>>>>> and
> > >>>>>> what
> > >>>>>>>> else
> > >>>>>>>>
> > >>>>>>>> 10) EIP model without JAXB dependency
> > >>>>>>>>
> > >>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> > >>>>>>>>
> > >>>>>>>> 12) Deprecate message.getIn()
> > >>>>>>>>
> > >>>>>>>> use getMessage() instead
> > >>>>>>>>
> > >>>>>>>> 13) Deprecate camel-cdi
> > >>>>>>>>
> > >>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> > >>>>>>>> fit
> > >>>>>> modern
> > >>>>>>>> app development)
> > >>>>>>>>
> > >>>>>>>> d) Minor Goals
> > >>>>>>>>
> > >>>>>>>> 15) Remove MEP InOptionalOut (not in use)
> > >>>>>>>>
> > >>>>>>>> 16) Remove JUnit 4 support
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Timeline
> > >>>>>>>>
> > >>>>>>>> =======
> > >>>>>>>>
> > >>>>>>>> The timelines are ESTIMATES and the number of releases can vary
> > >>>>>> depending
> > >>>>>>>> on need and how far we are in the process
> > >>>>>>>>
> > >>>>>>>> Feb 2023: Camel 4.0 milestone 1
> > >>>>>>>>
> > >>>>>>>> Mar 2023: Camel 4.0 milestone 2
> > >>>>>>>>
> > >>>>>>>> Apr 2023: Camel 4.0 RC1
> > >>>>>>>>
> > >>>>>>>> May 2023: Camel 4.0
> > >>>>>>>>
> > >>>>>>>> Aug 2023: Camel 4.1 LTS
> > >>>>>>>>
> > >>>>>>>> Oct 2023: Camel 4.2
> > >>>>>>>>
> > >>>>>>>> Dec 2023: Camel 4.3 LTS
> > >>>>>>>>
> > >>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
> > >>>>>>>> LTS
> > >>>>>> release,
> > >>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
> > >>>>>>>>
> > >>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> > >>>>>>>> releases
> > >>>>>> per
> > >>>>>>>> year.
> > >>>>>>>>
> > >>>>>>>> For example a scheduled could look as follows:
> > >>>>>>>>
> > >>>>>>>> Dec 2022: Camel 3.20 LTS
> > >>>>>>>>
> > >>>>>>>> Jun 2023: Camel 3.21 LTS
> > >>>>>>>>
> > >>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> > >>>>>>>> Dec
> > >>>>>> 2024)
> > >>>>>>>> ???
> > >>>>>>>>
> > >>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> > >>>>>>>> Dec
> > >>>>>> 2025)
> > >>>>>>>> ????
> > >>>>>>>>
> > >>>>>>>> Each Camel 3 LTS release will likely also contain less new
> > >>>>>>>> features
> > >>>> and
> > >>>>>>>> improvements as previously, as our focus and work shifts to Camel
> > >>>>>>>> v4 instead.
> > >>>>>>>>
> > >>>>>>>> As a recipient of an email from Talend, your contact personal
> > >>>>>>>> data
> > >>>>>> will be
> > >>>>>>>> on our systems. Please see our privacy notice. <
> > >>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> > >>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> > >>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> > >>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > >>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> > >>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>> --
> > >>>> --
> > >>>> François
> > >>>>
> > >>>>
> > >> --
> > >> --
> > >> François
> > >>
> > >>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
<fr...@openobject.fr> wrote:
>
> OSGi metadata in manifest is different than Karaf feature for managing
> bundle dependencies in component integration.
>
> I think that there is no effort from Camel team to keep the
> maven-bundle-plugin from the main source modules.
>
> On 30/11/2022 18:15, Claus Ibsen wrote:
> > Camel Karaf project generates JARs for what Camel components they support
> > only - the same is what we do for Spring Boot / Quarkus / Camel Kafka
> > Connector etc.
> > JB talks about Karaf 5 with a new way of deploying that sounds like this
> > can be done smarter and easier.
> >
> > For example if Camel Karaf support camel-ftp, then they can build and
> > release
> >
> > org.apache.karaf.camel:camel-ftp-bundle:4.0.0
> >
> >
> >
> >
> > On Wed, Nov 30, 2022 at 2:09 PM Siano, Stephan
> > <st...@sap.com.invalid> wrote:
> >
> >> Hi,
> >>
> >> Actually removing the OSGi manifests from the bundles coming from the
> >> general camel build would mean that we have to create an OSGi wrapper
> >> bundle for each and every jar coming out of the general build, which looks
> >> like a lot of maintenance effort to me.
> >>
> >> Best regards
> >> Stephan
> >>
> >> -----Original Message-----
> >> From: fpapon <fp...@apache.org>
> >> Sent: Wednesday, 30 November 2022 14:01
> >> To: dev@camel.apache.org
> >> Subject: Re: Camel 4 roadmap and affect on Camel 3
> >>
> >> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
> >> just with the manifest file add-in for each camel core jar.
> >>
> >> On 30/11/2022 13:53, Andrea Cosentino wrote:
> >>> This would become something karaf-camel is responsible for.
> >>>
> >>>
> >>>
> >>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> >>> scritto:
> >>>
> >>>> Hi,
> >>>>
> >>>> For this point "Camel v4 core and component JARs will no longer
> >>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
> >>>> from the core Camel is a good thing...
> >>>>
> >>>> regards,
> >>>>
> >>>> François
> >>>>
> >>>> On 30/11/2022 10:44, Claus Ibsen wrote:
> >>>>> Hi
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> >>>>> <jb...@nanthrax.net>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi guys,
> >>>>>>
> >>>>>> I understand that Karaf/OSGi is not in the Camel community target
> >>>>>> anymore, and it makes sense.
> >>>>>> I proposed a time ago to refactor the approach of Camel components
> >>>>>> for Karaf, using special packaging (embedded the deps as private to
> >>>>>> avoid to have bunch of SMX bundles deps), etc.
> >>>>>>
> >>>>>> Even at Karaf, there are discussions about the next step in the
> >>>>>> project decoupled from OSGi (see Minho).
> >>>>>>
> >>>>>> I would split the discussion in two parts:
> >>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
> >>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> >>>>>> always possible to wrap Camel routes in an uber jar and deploy in
> >>>>>> Karaf.
> >>>>>> - In terms of community/maintenance, I think camel-karaf could be
> >>>>>> part of the Karaf community. We had a similar discussion about
> >>>>>> jclouds: the jclouds community didn't want to maintain
> >>>>>> jclouds-karaf anymore (for the same reasons as the Camel
> >>>>>> community). The jclouds community asked the karaf community if they
> >>>>>> were interested in maintaining and managing jclouds-karaf. So we
> >>>>>> can do the same for camel-karaf: the karaf community can take the
> >> lead there and maintain it.
> >>>>>> Thoughts ?
> >>>>>>
> >>>>>>
> >>>>> Yes i Agree on this JB.
> >>>>>
> >>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
> >>>>> and let the community and committers in that project take over
> >>>>> maintaining
> >>>> and
> >>>>> releasing this.
> >>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
> >>>>> Apache Camel.
> >>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
> >>>>> and
> >>>> no
> >>>>> longer org.apache.camel.karaf.
> >>>>> - Camel v4 core and component JARs will no longer generate OSGi
> >>>> MANIFEST.MF
> >>>>> as Karaf Camel will be responsible for this (if even needed); such
> >>>>> as JB talks about a new way of packing and running things in Karaf.
> >>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> >>>>> until Camel 3 is EOL
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Regards
> >>>>>> JB
> >>>>>>
> >>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> >>>>>> <an...@gmail.com>
> >>>>>> wrote:
> >>>>>>> Hello
> >>>>>>>
> >>>>>>> I'll come back for other questions. Let me just say that
> >>>>>>> camel-karaf is
> >>>>>> too
> >>>>>>> hard to maintain today. If it won't be released because of
> >>>> misalignments,
> >>>>>>> it should be aligned by some volunteers or community member and
> >>>> released
> >>>>>>> later. Active contributors are not really focused on Karaf runtime
> >>>>>>> and
> >>>> we
> >>>>>>> cannot do everything. This doesn't mean we won't release camel
> >>>>>>> Karaf anymore. It only means it could be released later on. Even
> >>>>>>> after the
> >>>> core
> >>>>>>> camel and SB part have been released.
> >>>>>>>
> >>>>>>> In more than one situation aligning OSGi stuff have been really hard.
> >>>>>> Less
> >>>>>>> and less community members are helping on the Karaf side and
> >>>>>>> releasing sometimes have been slow down by these troubles. Also
> >>>>>>> OSGi have been
> >>>> drop
> >>>>>>> in a lot of 3rd party libraries.
> >>>>>>>
> >>>>>>> So I'm +1 with this approach.
> >>>>>>>
> >>>>>>> I'll continue the discussion in the next days for the other points.
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>>
> >>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >>>>>> scritto:
> >>>>>>>> Hi Claus,
> >>>>>>>>
> >>>>>>>> That sounds like a good plan, here are the first questions that I
> >>>>>>>> have
> >>>>>> in
> >>>>>>>> mind:
> >>>>>>>>
> >>>>>>>> * Why do we need to keep on releasing new LTS versions of
> >> Camel
> >>>> 3?
> >>>>>>>> * Why not simply consider 3.20 as the last LTS version of
> >> Camel 3
> >>>>>> and
> >>>>>>>> only maintain it?
> >>>>>>>> * What kind of features/improvements do you want to add to
> >> Camel
> >>>> 3
> >>>>>>>> after releasing 3.20?
> >>>>>>>> * If camel-karaf is released independently, when will it be
> >>>>>> released?
> >>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>>>>>> *
> >>>>>>>>
> >>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> >>>>>>>> mean 4
> >>>>>> LTS
> >>>>>>>> versions to support at the same time, don't you think that it is
> >>>>>>>> too
> >>>>>> many?
> >>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >>>>>> version
> >>>>>>>> policy. Could you please remind me why we decided to have this
> >>>>>>>> policy
> >>>>>> (2
> >>>>>>>> LTS versions per year supported for one year)?
> >>>>>>>>
> >>>>>>>> I would personally prefer to have:
> >>>>>>>>
> >>>>>>>> * only one LTS version per year (or 2 if we keep on releasing
> >> LTS
> >>>>>>>> versions of Camel 3) but supported for at least 2 years instead
> >>>>>>>> of one otherwise Camel users are less inclined to migrate to the
> >>>>>>>> latest LTS version because 1 year of support doesn't really worth
> >>>>>>>> the migration effort, especially for big projects where the
> >>>>>>>> migration takes several months.
> >>>>>>>> * only propose milestone versions or equivalent between 2 LTS
> >>>>>> versions
> >>>>>>>> for early adopters to add more clarity on which versions are LTS.
> >>>>>> Indeed,
> >>>>>>>> for example, the next LTS version will be 3.20 while we could
> >>>>>>>> expect
> >>>>>> 3.22
> >>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> >>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> >>>>>>>> 3.19, it
> >>>>>> would
> >>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> >>>>>>>> version as
> >>>>>> all
> >>>>>>>> final versions would then be LTS versions.
> >>>>>>>>
> >>>>>>>> What do you think of it?
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Nicolas
> >>>>>>>> ________________________________
> >>>>>>>> From: Claus Ibsen <cl...@gmail.com>
> >>>>>>>> Sent: Friday, November 25, 2022 11:42
> >>>>>>>> To: dev <de...@camel.apache.org>
> >>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>>>>>
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >>>>>> affect
> >>>>>>>> Camel 3.
> >>>>>>>>
> >>>>>>>> Summary
> >>>>>>>>
> >>>>>>>> =======
> >>>>>>>>
> >>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> >>>>>>>> less
> >>>> than
> >>>>>>>> going from Camel 2 to 3.
> >>>>>>>>
> >>>>>>>> And that we have a timebox approach where we aim for a 6 month
> >>>>>>>> period
> >>>>>> of
> >>>>>>>> work.
> >>>>>>>>
> >>>>>>>> The need for Camel v4 is mainly driven by Java open source
> >>>>>>>> projects migrating to jakarta APIs,
> >>>>>>>>
> >>>>>>>> and to keep up with popular runtimes a la Spring Boot and
> >>>>>>>> Quarkus, and
> >>>>>> to
> >>>>>>>> jump to the next major Java version.
> >>>>>>>>
> >>>>>>>> Goals
> >>>>>>>>
> >>>>>>>> =====
> >>>>>>>>
> >>>>>>>> a) Primary Goals
> >>>>>>>>
> >>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>>>>>
> >>>>>>>> 2) Java 17 as base line
> >>>>>>>>
> >>>>>>>> 3) Spring Framework 6
> >>>>>>>>
> >>>>>>>> 4) Spring Boot 3
> >>>>>>>>
> >>>>>>>> 5) Quarkus 3
> >>>>>>>>
> >>>>>>>> b) Release Goals
> >>>>>>>>
> >>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>>>>>
> >>>>>>>> This means that Camel components that are not ready (yet)
> >>>>>>>> will be dropped in a release until they are ready.
> >>>>>>>>
> >>>>>>>> 7) Release core + spring boot together
> >>>>>>>>
> >>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
> >>>>>> projects)
> >>>>>>>> c) Major Goals
> >>>>>>>>
> >>>>>>>> 9) Support Java 17 features such as records, multiline strings,
> >>>>>>>> and
> >>>>>> what
> >>>>>>>> else
> >>>>>>>>
> >>>>>>>> 10) EIP model without JAXB dependency
> >>>>>>>>
> >>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>>>>>
> >>>>>>>> 12) Deprecate message.getIn()
> >>>>>>>>
> >>>>>>>> use getMessage() instead
> >>>>>>>>
> >>>>>>>> 13) Deprecate camel-cdi
> >>>>>>>>
> >>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> >>>>>>>> fit
> >>>>>> modern
> >>>>>>>> app development)
> >>>>>>>>
> >>>>>>>> d) Minor Goals
> >>>>>>>>
> >>>>>>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>>>>>
> >>>>>>>> 16) Remove JUnit 4 support
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Timeline
> >>>>>>>>
> >>>>>>>> =======
> >>>>>>>>
> >>>>>>>> The timelines are ESTIMATES and the number of releases can vary
> >>>>>> depending
> >>>>>>>> on need and how far we are in the process
> >>>>>>>>
> >>>>>>>> Feb 2023: Camel 4.0 milestone 1
> >>>>>>>>
> >>>>>>>> Mar 2023: Camel 4.0 milestone 2
> >>>>>>>>
> >>>>>>>> Apr 2023: Camel 4.0 RC1
> >>>>>>>>
> >>>>>>>> May 2023: Camel 4.0
> >>>>>>>>
> >>>>>>>> Aug 2023: Camel 4.1 LTS
> >>>>>>>>
> >>>>>>>> Oct 2023: Camel 4.2
> >>>>>>>>
> >>>>>>>> Dec 2023: Camel 4.3 LTS
> >>>>>>>>
> >>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
> >>>>>>>> LTS
> >>>>>> release,
> >>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>>>>>
> >>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> >>>>>>>> releases
> >>>>>> per
> >>>>>>>> year.
> >>>>>>>>
> >>>>>>>> For example a scheduled could look as follows:
> >>>>>>>>
> >>>>>>>> Dec 2022: Camel 3.20 LTS
> >>>>>>>>
> >>>>>>>> Jun 2023: Camel 3.21 LTS
> >>>>>>>>
> >>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> >>>>>>>> Dec
> >>>>>> 2024)
> >>>>>>>> ???
> >>>>>>>>
> >>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> >>>>>>>> Dec
> >>>>>> 2025)
> >>>>>>>> ????
> >>>>>>>>
> >>>>>>>> Each Camel 3 LTS release will likely also contain less new
> >>>>>>>> features
> >>>> and
> >>>>>>>> improvements as previously, as our focus and work shifts to Camel
> >>>>>>>> v4 instead.
> >>>>>>>>
> >>>>>>>> As a recipient of an email from Talend, your contact personal
> >>>>>>>> data
> >>>>>> will be
> >>>>>>>> on our systems. Please see our privacy notice. <
> >>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> >>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> >>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> >>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> >>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>> --
> >>>> --
> >>>> François
> >>>>
> >>>>
> >> --
> >> --
> >> François
> >>
> >>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Francois Papon <fr...@openobject.fr>.
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
> <st...@sap.com.invalid> wrote:
>
>> Hi,
>>
>> Actually removing the OSGi manifests from the bundles coming from the
>> general camel build would mean that we have to create an OSGi wrapper
>> bundle for each and every jar coming out of the general build, which looks
>> like a lot of maintenance effort to me.
>>
>> Best regards
>> Stephan
>>
>> -----Original Message-----
>> From: fpapon <fp...@apache.org>
>> Sent: Wednesday, 30 November 2022 14:01
>> To: dev@camel.apache.org
>> Subject: Re: Camel 4 roadmap and affect on Camel 3
>>
>> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
>> just with the manifest file add-in for each camel core jar.
>>
>> On 30/11/2022 13:53, Andrea Cosentino wrote:
>>> This would become something karaf-camel is responsible for.
>>>
>>>
>>>
>>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
>>> scritto:
>>>
>>>> Hi,
>>>>
>>>> For this point "Camel v4 core and component JARs will no longer
>>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>>>> from the core Camel is a good thing...
>>>>
>>>> regards,
>>>>
>>>> François
>>>>
>>>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>>>> <jb...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>>>> anymore, and it makes sense.
>>>>>> I proposed a time ago to refactor the approach of Camel components
>>>>>> for Karaf, using special packaging (embedded the deps as private to
>>>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>>>
>>>>>> Even at Karaf, there are discussions about the next step in the
>>>>>> project decoupled from OSGi (see Minho).
>>>>>>
>>>>>> I would split the discussion in two parts:
>>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>>>> Karaf.
>>>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>>>> part of the Karaf community. We had a similar discussion about
>>>>>> jclouds: the jclouds community didn't want to maintain
>>>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>>>> community). The jclouds community asked the karaf community if they
>>>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>>>> can do the same for camel-karaf: the karaf community can take the
>> lead there and maintain it.
>>>>>> Thoughts ?
>>>>>>
>>>>>>
>>>>> Yes i Agree on this JB.
>>>>>
>>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>>>> and let the community and committers in that project take over
>>>>> maintaining
>>>> and
>>>>> releasing this.
>>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>>>> Apache Camel.
>>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>>>> and
>>>> no
>>>>> longer org.apache.camel.karaf.
>>>>> - Camel v4 core and component JARs will no longer generate OSGi
>>>> MANIFEST.MF
>>>>> as Karaf Camel will be responsible for this (if even needed); such
>>>>> as JB talks about a new way of packing and running things in Karaf.
>>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>>>> until Camel 3 is EOL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>>>> <an...@gmail.com>
>>>>>> wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> I'll come back for other questions. Let me just say that
>>>>>>> camel-karaf is
>>>>>> too
>>>>>>> hard to maintain today. If it won't be released because of
>>>> misalignments,
>>>>>>> it should be aligned by some volunteers or community member and
>>>> released
>>>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>>>> and
>>>> we
>>>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>>>> after the
>>>> core
>>>>>>> camel and SB part have been released.
>>>>>>>
>>>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>>>> Less
>>>>>>> and less community members are helping on the Karaf side and
>>>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>>>> OSGi have been
>>>> drop
>>>>>>> in a lot of 3rd party libraries.
>>>>>>>
>>>>>>> So I'm +1 with this approach.
>>>>>>>
>>>>>>> I'll continue the discussion in the next days for the other points.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>>>> scritto:
>>>>>>>> Hi Claus,
>>>>>>>>
>>>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>>>> have
>>>>>> in
>>>>>>>> mind:
>>>>>>>>
>>>>>>>> * Why do we need to keep on releasing new LTS versions of
>> Camel
>>>> 3?
>>>>>>>> * Why not simply consider 3.20 as the last LTS version of
>> Camel 3
>>>>>> and
>>>>>>>> only maintain it?
>>>>>>>> * What kind of features/improvements do you want to add to
>> Camel
>>>> 3
>>>>>>>> after releasing 3.20?
>>>>>>>> * If camel-karaf is released independently, when will it be
>>>>>> released?
>>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>>>> *
>>>>>>>>
>>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>>>> mean 4
>>>>>> LTS
>>>>>>>> versions to support at the same time, don't you think that it is
>>>>>>>> too
>>>>>> many?
>>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>>>> version
>>>>>>>> policy. Could you please remind me why we decided to have this
>>>>>>>> policy
>>>>>> (2
>>>>>>>> LTS versions per year supported for one year)?
>>>>>>>>
>>>>>>>> I would personally prefer to have:
>>>>>>>>
>>>>>>>> * only one LTS version per year (or 2 if we keep on releasing
>> LTS
>>>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>>>> the migration effort, especially for big projects where the
>>>>>>>> migration takes several months.
>>>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>>>> versions
>>>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>>>> Indeed,
>>>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>>>> expect
>>>>>> 3.22
>>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>>>> 3.19, it
>>>>>> would
>>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>>>> version as
>>>>>> all
>>>>>>>> final versions would then be LTS versions.
>>>>>>>>
>>>>>>>> What do you think of it?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nicolas
>>>>>>>> ________________________________
>>>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>>>> To: dev <de...@camel.apache.org>
>>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>>>> affect
>>>>>>>> Camel 3.
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> =======
>>>>>>>>
>>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>>>> less
>>>> than
>>>>>>>> going from Camel 2 to 3.
>>>>>>>>
>>>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>>>> period
>>>>>> of
>>>>>>>> work.
>>>>>>>>
>>>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>>>> projects migrating to jakarta APIs,
>>>>>>>>
>>>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>>>> Quarkus, and
>>>>>> to
>>>>>>>> jump to the next major Java version.
>>>>>>>>
>>>>>>>> Goals
>>>>>>>>
>>>>>>>> =====
>>>>>>>>
>>>>>>>> a) Primary Goals
>>>>>>>>
>>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>>>
>>>>>>>> 2) Java 17 as base line
>>>>>>>>
>>>>>>>> 3) Spring Framework 6
>>>>>>>>
>>>>>>>> 4) Spring Boot 3
>>>>>>>>
>>>>>>>> 5) Quarkus 3
>>>>>>>>
>>>>>>>> b) Release Goals
>>>>>>>>
>>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>>>
>>>>>>>> This means that Camel components that are not ready (yet)
>>>>>>>> will be dropped in a release until they are ready.
>>>>>>>>
>>>>>>>> 7) Release core + spring boot together
>>>>>>>>
>>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>>>> projects)
>>>>>>>> c) Major Goals
>>>>>>>>
>>>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>>>> and
>>>>>> what
>>>>>>>> else
>>>>>>>>
>>>>>>>> 10) EIP model without JAXB dependency
>>>>>>>>
>>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>>>
>>>>>>>> 12) Deprecate message.getIn()
>>>>>>>>
>>>>>>>> use getMessage() instead
>>>>>>>>
>>>>>>>> 13) Deprecate camel-cdi
>>>>>>>>
>>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>>>> fit
>>>>>> modern
>>>>>>>> app development)
>>>>>>>>
>>>>>>>> d) Minor Goals
>>>>>>>>
>>>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>>>
>>>>>>>> 16) Remove JUnit 4 support
>>>>>>>>
>>>>>>>>
>>>>>>>> Timeline
>>>>>>>>
>>>>>>>> =======
>>>>>>>>
>>>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>>>> depending
>>>>>>>> on need and how far we are in the process
>>>>>>>>
>>>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>>>
>>>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>>>
>>>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>>>
>>>>>>>> May 2023: Camel 4.0
>>>>>>>>
>>>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>>>
>>>>>>>> Oct 2023: Camel 4.2
>>>>>>>>
>>>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>>>
>>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>>>> LTS
>>>>>> release,
>>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>>>
>>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>>>> releases
>>>>>> per
>>>>>>>> year.
>>>>>>>>
>>>>>>>> For example a scheduled could look as follows:
>>>>>>>>
>>>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>>>
>>>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>>>
>>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>>>> Dec
>>>>>> 2024)
>>>>>>>> ???
>>>>>>>>
>>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>>>> Dec
>>>>>> 2025)
>>>>>>>> ????
>>>>>>>>
>>>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>>>> features
>>>> and
>>>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>>>> v4 instead.
>>>>>>>>
>>>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>>>> data
>>>>>> will be
>>>>>>>> on our systems. Please see our privacy notice. <
>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> --
>>>> --
>>>> François
>>>>
>>>>
>> --
>> --
>> François
>>
>>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Claus Ibsen <cl...@gmail.com>.
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
<st...@sap.com.invalid> wrote:
> Hi,
>
> Actually removing the OSGi manifests from the bundles coming from the
> general camel build would mean that we have to create an OSGi wrapper
> bundle for each and every jar coming out of the general build, which looks
> like a lot of maintenance effort to me.
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: fpapon <fp...@apache.org>
> Sent: Wednesday, 30 November 2022 14:01
> To: dev@camel.apache.org
> Subject: Re: Camel 4 roadmap and affect on Camel 3
>
> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar
> just with the manifest file add-in for each camel core jar.
>
> On 30/11/2022 13:53, Andrea Cosentino wrote:
> > This would become something karaf-camel is responsible for.
> >
> >
> >
> > Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> > scritto:
> >
> >> Hi,
> >>
> >> For this point "Camel v4 core and component JARs will no longer
> >> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
> >> from the core Camel is a good thing...
> >>
> >> regards,
> >>
> >> François
> >>
> >> On 30/11/2022 10:44, Claus Ibsen wrote:
> >>> Hi
> >>>
> >>>
> >>>
> >>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> >>> <jb...@nanthrax.net>
> >>> wrote:
> >>>
> >>>> Hi guys,
> >>>>
> >>>> I understand that Karaf/OSGi is not in the Camel community target
> >>>> anymore, and it makes sense.
> >>>> I proposed a time ago to refactor the approach of Camel components
> >>>> for Karaf, using special packaging (embedded the deps as private to
> >>>> avoid to have bunch of SMX bundles deps), etc.
> >>>>
> >>>> Even at Karaf, there are discussions about the next step in the
> >>>> project decoupled from OSGi (see Minho).
> >>>>
> >>>> I would split the discussion in two parts:
> >>>> - In terms of the roadmap/Camel future, I don't think it's worth it
> >>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> >>>> always possible to wrap Camel routes in an uber jar and deploy in
> >>>> Karaf.
> >>>> - In terms of community/maintenance, I think camel-karaf could be
> >>>> part of the Karaf community. We had a similar discussion about
> >>>> jclouds: the jclouds community didn't want to maintain
> >>>> jclouds-karaf anymore (for the same reasons as the Camel
> >>>> community). The jclouds community asked the karaf community if they
> >>>> were interested in maintaining and managing jclouds-karaf. So we
> >>>> can do the same for camel-karaf: the karaf community can take the
> lead there and maintain it.
> >>>>
> >>>> Thoughts ?
> >>>>
> >>>>
> >>> Yes i Agree on this JB.
> >>>
> >>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
> >>> and let the community and committers in that project take over
> >>> maintaining
> >> and
> >>> releasing this.
> >>> - For Camel v4 onwards then camel-karaf will no longer be part of
> >>> Apache Camel.
> >>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
> >>> and
> >> no
> >>> longer org.apache.camel.karaf.
> >>> - Camel v4 core and component JARs will no longer generate OSGi
> >> MANIFEST.MF
> >>> as Karaf Camel will be responsible for this (if even needed); such
> >>> as JB talks about a new way of packing and running things in Karaf.
> >>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> >>> until Camel 3 is EOL
> >>>
> >>>
> >>>
> >>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> >>>> <an...@gmail.com>
> >>>> wrote:
> >>>>> Hello
> >>>>>
> >>>>> I'll come back for other questions. Let me just say that
> >>>>> camel-karaf is
> >>>> too
> >>>>> hard to maintain today. If it won't be released because of
> >> misalignments,
> >>>>> it should be aligned by some volunteers or community member and
> >> released
> >>>>> later. Active contributors are not really focused on Karaf runtime
> >>>>> and
> >> we
> >>>>> cannot do everything. This doesn't mean we won't release camel
> >>>>> Karaf anymore. It only means it could be released later on. Even
> >>>>> after the
> >> core
> >>>>> camel and SB part have been released.
> >>>>>
> >>>>> In more than one situation aligning OSGi stuff have been really hard.
> >>>> Less
> >>>>> and less community members are helping on the Karaf side and
> >>>>> releasing sometimes have been slow down by these troubles. Also
> >>>>> OSGi have been
> >> drop
> >>>>> in a lot of 3rd party libraries.
> >>>>>
> >>>>> So I'm +1 with this approach.
> >>>>>
> >>>>> I'll continue the discussion in the next days for the other points.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >>>> scritto:
> >>>>>> Hi Claus,
> >>>>>>
> >>>>>> That sounds like a good plan, here are the first questions that I
> >>>>>> have
> >>>> in
> >>>>>> mind:
> >>>>>>
> >>>>>> * Why do we need to keep on releasing new LTS versions of
> Camel
> >> 3?
> >>>>>> * Why not simply consider 3.20 as the last LTS version of
> Camel 3
> >>>> and
> >>>>>> only maintain it?
> >>>>>> * What kind of features/improvements do you want to add to
> Camel
> >> 3
> >>>>>> after releasing 3.20?
> >>>>>> * If camel-karaf is released independently, when will it be
> >>>> released?
> >>>>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>>>> *
> >>>>>>
> >>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> >>>>>> mean 4
> >>>> LTS
> >>>>>> versions to support at the same time, don't you think that it is
> >>>>>> too
> >>>> many?
> >>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >>>> version
> >>>>>> policy. Could you please remind me why we decided to have this
> >>>>>> policy
> >>>> (2
> >>>>>> LTS versions per year supported for one year)?
> >>>>>>
> >>>>>> I would personally prefer to have:
> >>>>>>
> >>>>>> * only one LTS version per year (or 2 if we keep on releasing
> LTS
> >>>>>> versions of Camel 3) but supported for at least 2 years instead
> >>>>>> of one otherwise Camel users are less inclined to migrate to the
> >>>>>> latest LTS version because 1 year of support doesn't really worth
> >>>>>> the migration effort, especially for big projects where the
> >>>>>> migration takes several months.
> >>>>>> * only propose milestone versions or equivalent between 2 LTS
> >>>> versions
> >>>>>> for early adopters to add more clarity on which versions are LTS.
> >>>> Indeed,
> >>>>>> for example, the next LTS version will be 3.20 while we could
> >>>>>> expect
> >>>> 3.22
> >>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> >>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> >>>>>> 3.19, it
> >>>> would
> >>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> >>>>>> version as
> >>>> all
> >>>>>> final versions would then be LTS versions.
> >>>>>>
> >>>>>> What do you think of it?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Nicolas
> >>>>>> ________________________________
> >>>>>> From: Claus Ibsen <cl...@gmail.com>
> >>>>>> Sent: Friday, November 25, 2022 11:42
> >>>>>> To: dev <de...@camel.apache.org>
> >>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >>>> affect
> >>>>>> Camel 3.
> >>>>>>
> >>>>>> Summary
> >>>>>>
> >>>>>> =======
> >>>>>>
> >>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> >>>>>> less
> >> than
> >>>>>> going from Camel 2 to 3.
> >>>>>>
> >>>>>> And that we have a timebox approach where we aim for a 6 month
> >>>>>> period
> >>>> of
> >>>>>> work.
> >>>>>>
> >>>>>> The need for Camel v4 is mainly driven by Java open source
> >>>>>> projects migrating to jakarta APIs,
> >>>>>>
> >>>>>> and to keep up with popular runtimes a la Spring Boot and
> >>>>>> Quarkus, and
> >>>> to
> >>>>>> jump to the next major Java version.
> >>>>>>
> >>>>>> Goals
> >>>>>>
> >>>>>> =====
> >>>>>>
> >>>>>> a) Primary Goals
> >>>>>>
> >>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>>>
> >>>>>> 2) Java 17 as base line
> >>>>>>
> >>>>>> 3) Spring Framework 6
> >>>>>>
> >>>>>> 4) Spring Boot 3
> >>>>>>
> >>>>>> 5) Quarkus 3
> >>>>>>
> >>>>>> b) Release Goals
> >>>>>>
> >>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>>>
> >>>>>> This means that Camel components that are not ready (yet)
> >>>>>> will be dropped in a release until they are ready.
> >>>>>>
> >>>>>> 7) Release core + spring boot together
> >>>>>>
> >>>>>> 8) Release camel-karaf independently (like we do for other Camel
> >>>> projects)
> >>>>>> c) Major Goals
> >>>>>>
> >>>>>> 9) Support Java 17 features such as records, multiline strings,
> >>>>>> and
> >>>> what
> >>>>>> else
> >>>>>>
> >>>>>> 10) EIP model without JAXB dependency
> >>>>>>
> >>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>>>
> >>>>>> 12) Deprecate message.getIn()
> >>>>>>
> >>>>>> use getMessage() instead
> >>>>>>
> >>>>>> 13) Deprecate camel-cdi
> >>>>>>
> >>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> >>>>>> fit
> >>>> modern
> >>>>>> app development)
> >>>>>>
> >>>>>> d) Minor Goals
> >>>>>>
> >>>>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>>>
> >>>>>> 16) Remove JUnit 4 support
> >>>>>>
> >>>>>>
> >>>>>> Timeline
> >>>>>>
> >>>>>> =======
> >>>>>>
> >>>>>> The timelines are ESTIMATES and the number of releases can vary
> >>>> depending
> >>>>>> on need and how far we are in the process
> >>>>>>
> >>>>>> Feb 2023: Camel 4.0 milestone 1
> >>>>>>
> >>>>>> Mar 2023: Camel 4.0 milestone 2
> >>>>>>
> >>>>>> Apr 2023: Camel 4.0 RC1
> >>>>>>
> >>>>>> May 2023: Camel 4.0
> >>>>>>
> >>>>>> Aug 2023: Camel 4.1 LTS
> >>>>>>
> >>>>>> Oct 2023: Camel 4.2
> >>>>>>
> >>>>>> Dec 2023: Camel 4.3 LTS
> >>>>>>
> >>>>>> The plan is to start working on Camel 4 after the next Camel 3
> >>>>>> LTS
> >>>> release,
> >>>>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>>>
> >>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> >>>>>> releases
> >>>> per
> >>>>>> year.
> >>>>>>
> >>>>>> For example a scheduled could look as follows:
> >>>>>>
> >>>>>> Dec 2022: Camel 3.20 LTS
> >>>>>>
> >>>>>> Jun 2023: Camel 3.21 LTS
> >>>>>>
> >>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> >>>>>> Dec
> >>>> 2024)
> >>>>>> ???
> >>>>>>
> >>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> >>>>>> Dec
> >>>> 2025)
> >>>>>> ????
> >>>>>>
> >>>>>> Each Camel 3 LTS release will likely also contain less new
> >>>>>> features
> >> and
> >>>>>> improvements as previously, as our focus and work shifts to Camel
> >>>>>> v4 instead.
> >>>>>>
> >>>>>> As a recipient of an email from Talend, your contact personal
> >>>>>> data
> >>>> will be
> >>>>>> on our systems. Please see our privacy notice. <
> >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> >>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> >>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> >>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> >>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> >>>>>>
> >>>>>>
> >>>>>>
> >> --
> >> --
> >> François
> >>
> >>
> --
> --
> François
>
>
--
Claus Ibsen
-----------------
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Posted by fpapon <fp...@apache.org>.
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 <fp...@apache.org>
> Sent: Wednesday, 30 November 2022 14:01
> To: dev@camel.apache.org
> Subject: Re: Camel 4 roadmap and affect on Camel 3
>
> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar just with the manifest file add-in for each camel core jar.
>
> On 30/11/2022 13:53, Andrea Cosentino wrote:
>> This would become something karaf-camel is responsible for.
>>
>>
>>
>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
>> scritto:
>>
>>> Hi,
>>>
>>> For this point "Camel v4 core and component JARs will no longer
>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>>> from the core Camel is a good thing...
>>>
>>> regards,
>>>
>>> François
>>>
>>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>>> Hi
>>>>
>>>>
>>>>
>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>>> <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>>> anymore, and it makes sense.
>>>>> I proposed a time ago to refactor the approach of Camel components
>>>>> for Karaf, using special packaging (embedded the deps as private to
>>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>>
>>>>> Even at Karaf, there are discussions about the next step in the
>>>>> project decoupled from OSGi (see Minho).
>>>>>
>>>>> I would split the discussion in two parts:
>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>>> Karaf.
>>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>>> part of the Karaf community. We had a similar discussion about
>>>>> jclouds: the jclouds community didn't want to maintain
>>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>>> community). The jclouds community asked the karaf community if they
>>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>>> can do the same for camel-karaf: the karaf community can take the lead there and maintain it.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>>
>>>> Yes i Agree on this JB.
>>>>
>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>>> and let the community and committers in that project take over
>>>> maintaining
>>> and
>>>> releasing this.
>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>>> Apache Camel.
>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>>> and
>>> no
>>>> longer org.apache.camel.karaf.
>>>> - Camel v4 core and component JARs will no longer generate OSGi
>>> MANIFEST.MF
>>>> as Karaf Camel will be responsible for this (if even needed); such
>>>> as JB talks about a new way of packing and running things in Karaf.
>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>>> until Camel 3 is EOL
>>>>
>>>>
>>>>
>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>>> <an...@gmail.com>
>>>>> wrote:
>>>>>> Hello
>>>>>>
>>>>>> I'll come back for other questions. Let me just say that
>>>>>> camel-karaf is
>>>>> too
>>>>>> hard to maintain today. If it won't be released because of
>>> misalignments,
>>>>>> it should be aligned by some volunteers or community member and
>>> released
>>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>>> and
>>> we
>>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>>> after the
>>> core
>>>>>> camel and SB part have been released.
>>>>>>
>>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>>> Less
>>>>>> and less community members are helping on the Karaf side and
>>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>>> OSGi have been
>>> drop
>>>>>> in a lot of 3rd party libraries.
>>>>>>
>>>>>> So I'm +1 with this approach.
>>>>>>
>>>>>> I'll continue the discussion in the next days for the other points.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>>> scritto:
>>>>>>> Hi Claus,
>>>>>>>
>>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>>> have
>>>>> in
>>>>>>> mind:
>>>>>>>
>>>>>>> * Why do we need to keep on releasing new LTS versions of Camel
>>> 3?
>>>>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
>>>>> and
>>>>>>> only maintain it?
>>>>>>> * What kind of features/improvements do you want to add to Camel
>>> 3
>>>>>>> after releasing 3.20?
>>>>>>> * If camel-karaf is released independently, when will it be
>>>>> released?
>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>>> *
>>>>>>>
>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>>> mean 4
>>>>> LTS
>>>>>>> versions to support at the same time, don't you think that it is
>>>>>>> too
>>>>> many?
>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>>> version
>>>>>>> policy. Could you please remind me why we decided to have this
>>>>>>> policy
>>>>> (2
>>>>>>> LTS versions per year supported for one year)?
>>>>>>>
>>>>>>> I would personally prefer to have:
>>>>>>>
>>>>>>> * only one LTS version per year (or 2 if we keep on releasing LTS
>>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>>> the migration effort, especially for big projects where the
>>>>>>> migration takes several months.
>>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>>> versions
>>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>>> Indeed,
>>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>>> expect
>>>>> 3.22
>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>>> 3.19, it
>>>>> would
>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>>> version as
>>>>> all
>>>>>>> final versions would then be LTS versions.
>>>>>>>
>>>>>>> What do you think of it?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nicolas
>>>>>>> ________________________________
>>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>>> To: dev <de...@camel.apache.org>
>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>>> affect
>>>>>>> Camel 3.
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> =======
>>>>>>>
>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>>> less
>>> than
>>>>>>> going from Camel 2 to 3.
>>>>>>>
>>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>>> period
>>>>> of
>>>>>>> work.
>>>>>>>
>>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>>> projects migrating to jakarta APIs,
>>>>>>>
>>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>>> Quarkus, and
>>>>> to
>>>>>>> jump to the next major Java version.
>>>>>>>
>>>>>>> Goals
>>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> a) Primary Goals
>>>>>>>
>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>>
>>>>>>> 2) Java 17 as base line
>>>>>>>
>>>>>>> 3) Spring Framework 6
>>>>>>>
>>>>>>> 4) Spring Boot 3
>>>>>>>
>>>>>>> 5) Quarkus 3
>>>>>>>
>>>>>>> b) Release Goals
>>>>>>>
>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>>
>>>>>>> This means that Camel components that are not ready (yet)
>>>>>>> will be dropped in a release until they are ready.
>>>>>>>
>>>>>>> 7) Release core + spring boot together
>>>>>>>
>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>>> projects)
>>>>>>> c) Major Goals
>>>>>>>
>>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>>> and
>>>>> what
>>>>>>> else
>>>>>>>
>>>>>>> 10) EIP model without JAXB dependency
>>>>>>>
>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>>
>>>>>>> 12) Deprecate message.getIn()
>>>>>>>
>>>>>>> use getMessage() instead
>>>>>>>
>>>>>>> 13) Deprecate camel-cdi
>>>>>>>
>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>>> fit
>>>>> modern
>>>>>>> app development)
>>>>>>>
>>>>>>> d) Minor Goals
>>>>>>>
>>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>>
>>>>>>> 16) Remove JUnit 4 support
>>>>>>>
>>>>>>>
>>>>>>> Timeline
>>>>>>>
>>>>>>> =======
>>>>>>>
>>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>>> depending
>>>>>>> on need and how far we are in the process
>>>>>>>
>>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>>
>>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>>
>>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>>
>>>>>>> May 2023: Camel 4.0
>>>>>>>
>>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>>
>>>>>>> Oct 2023: Camel 4.2
>>>>>>>
>>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>>
>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>>> LTS
>>>>> release,
>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>>
>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>>> releases
>>>>> per
>>>>>>> year.
>>>>>>>
>>>>>>> For example a scheduled could look as follows:
>>>>>>>
>>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>>
>>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>>
>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>>> Dec
>>>>> 2024)
>>>>>>> ???
>>>>>>>
>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>>> Dec
>>>>> 2025)
>>>>>>> ????
>>>>>>>
>>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>>> features
>>> and
>>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>>> v4 instead.
>>>>>>>
>>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>>> data
>>>>> will be
>>>>>>> on our systems. Please see our privacy notice. <
>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>>
>>>>>>>
>>>>>>>
>>> --
>>> --
>>> François
>>>
>>>
> --
> --
> François
>
--
--
François
Re: Camel 4 roadmap and affect on Camel 3
Posted by Andrea Cosentino <an...@gmail.com>.
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 <ma...@gmail.com> ha scritto:
> Hi All—
>
> What benefit comes from removing the OSGi manifest? Seems like repackaging
> for Karaf could be an option, but leaving the auto-gen osgi headers in is a
> good idea. A *ton* of large apps use OSGi runtimes b/c it is an effective
> way to allow third parties to provide extensions and plugins. Seems odd
> that Camel would prefer to opt out of that by default.
>
> Add’l thoughts on Camel v4—
>
> How about the Camel JMS component using Spring JMS be swapped out with the
> Java-native one as the default for ‘jms’? This would obviously be a major
> breaking change.
>
> Thanks,
> Matt Pavlovich
>
> > On Nov 30, 2022, at 7:09 AM, Siano, Stephan
> <st...@sap.com.INVALID> wrote:
> >
> > Hi,
> >
> > Actually removing the OSGi manifests from the bundles coming from the
> general camel build would mean that we have to create an OSGi wrapper
> bundle for each and every jar coming out of the general build, which looks
> like a lot of maintenance effort to me.
> >
> > Best regards
> > Stephan
> >
> > -----Original Message-----
> > From: fpapon <fp...@apache.org>
> > Sent: Wednesday, 30 November 2022 14:01
> > To: dev@camel.apache.org
> > Subject: Re: Camel 4 roadmap and affect on Camel 3
> >
> > Ok so we will have a camel-core.jar and
> camel-core-with-manifest-osgi.jar just with the manifest file add-in for
> each camel core jar.
> >
> > On 30/11/2022 13:53, Andrea Cosentino wrote:
> >> This would become something karaf-camel is responsible for.
> >>
> >>
> >>
> >> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> >> scritto:
> >>
> >>> Hi,
> >>>
> >>> For this point "Camel v4 core and component JARs will no longer
> >>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
> >>> from the core Camel is a good thing...
> >>>
> >>> regards,
> >>>
> >>> François
> >>>
> >>> On 30/11/2022 10:44, Claus Ibsen wrote:
> >>>> Hi
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> >>>> <jb...@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>>> Hi guys,
> >>>>>
> >>>>> I understand that Karaf/OSGi is not in the Camel community target
> >>>>> anymore, and it makes sense.
> >>>>> I proposed a time ago to refactor the approach of Camel components
> >>>>> for Karaf, using special packaging (embedded the deps as private to
> >>>>> avoid to have bunch of SMX bundles deps), etc.
> >>>>>
> >>>>> Even at Karaf, there are discussions about the next step in the
> >>>>> project decoupled from OSGi (see Minho).
> >>>>>
> >>>>> I would split the discussion in two parts:
> >>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
> >>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> >>>>> always possible to wrap Camel routes in an uber jar and deploy in
> >>>>> Karaf.
> >>>>> - In terms of community/maintenance, I think camel-karaf could be
> >>>>> part of the Karaf community. We had a similar discussion about
> >>>>> jclouds: the jclouds community didn't want to maintain
> >>>>> jclouds-karaf anymore (for the same reasons as the Camel
> >>>>> community). The jclouds community asked the karaf community if they
> >>>>> were interested in maintaining and managing jclouds-karaf. So we
> >>>>> can do the same for camel-karaf: the karaf community can take the
> lead there and maintain it.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>>
> >>>> Yes i Agree on this JB.
> >>>>
> >>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
> >>>> and let the community and committers in that project take over
> >>>> maintaining
> >>> and
> >>>> releasing this.
> >>>> - For Camel v4 onwards then camel-karaf will no longer be part of
> >>>> Apache Camel.
> >>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
> >>>> and
> >>> no
> >>>> longer org.apache.camel.karaf.
> >>>> - Camel v4 core and component JARs will no longer generate OSGi
> >>> MANIFEST.MF
> >>>> as Karaf Camel will be responsible for this (if even needed); such
> >>>> as JB talks about a new way of packing and running things in Karaf.
> >>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> >>>> until Camel 3 is EOL
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> >>>>> <an...@gmail.com>
> >>>>> wrote:
> >>>>>> Hello
> >>>>>>
> >>>>>> I'll come back for other questions. Let me just say that
> >>>>>> camel-karaf is
> >>>>> too
> >>>>>> hard to maintain today. If it won't be released because of
> >>> misalignments,
> >>>>>> it should be aligned by some volunteers or community member and
> >>> released
> >>>>>> later. Active contributors are not really focused on Karaf runtime
> >>>>>> and
> >>> we
> >>>>>> cannot do everything. This doesn't mean we won't release camel
> >>>>>> Karaf anymore. It only means it could be released later on. Even
> >>>>>> after the
> >>> core
> >>>>>> camel and SB part have been released.
> >>>>>>
> >>>>>> In more than one situation aligning OSGi stuff have been really
> hard.
> >>>>> Less
> >>>>>> and less community members are helping on the Karaf side and
> >>>>>> releasing sometimes have been slow down by these troubles. Also
> >>>>>> OSGi have been
> >>> drop
> >>>>>> in a lot of 3rd party libraries.
> >>>>>>
> >>>>>> So I'm +1 with this approach.
> >>>>>>
> >>>>>> I'll continue the discussion in the next days for the other points.
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>>
> >>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >>>>> scritto:
> >>>>>>> Hi Claus,
> >>>>>>>
> >>>>>>> That sounds like a good plan, here are the first questions that I
> >>>>>>> have
> >>>>> in
> >>>>>>> mind:
> >>>>>>>
> >>>>>>> * Why do we need to keep on releasing new LTS versions of
> Camel
> >>> 3?
> >>>>>>> * Why not simply consider 3.20 as the last LTS version of
> Camel 3
> >>>>> and
> >>>>>>> only maintain it?
> >>>>>>> * What kind of features/improvements do you want to add to
> Camel
> >>> 3
> >>>>>>> after releasing 3.20?
> >>>>>>> * If camel-karaf is released independently, when will it be
> >>>>> released?
> >>>>>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>>>>> *
> >>>>>>>
> >>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> >>>>>>> mean 4
> >>>>> LTS
> >>>>>>> versions to support at the same time, don't you think that it is
> >>>>>>> too
> >>>>> many?
> >>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >>>>> version
> >>>>>>> policy. Could you please remind me why we decided to have this
> >>>>>>> policy
> >>>>> (2
> >>>>>>> LTS versions per year supported for one year)?
> >>>>>>>
> >>>>>>> I would personally prefer to have:
> >>>>>>>
> >>>>>>> * only one LTS version per year (or 2 if we keep on releasing
> LTS
> >>>>>>> versions of Camel 3) but supported for at least 2 years instead
> >>>>>>> of one otherwise Camel users are less inclined to migrate to the
> >>>>>>> latest LTS version because 1 year of support doesn't really worth
> >>>>>>> the migration effort, especially for big projects where the
> >>>>>>> migration takes several months.
> >>>>>>> * only propose milestone versions or equivalent between 2 LTS
> >>>>> versions
> >>>>>>> for early adopters to add more clarity on which versions are LTS.
> >>>>> Indeed,
> >>>>>>> for example, the next LTS version will be 3.20 while we could
> >>>>>>> expect
> >>>>> 3.22
> >>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> >>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> >>>>>>> 3.19, it
> >>>>> would
> >>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> >>>>>>> version as
> >>>>> all
> >>>>>>> final versions would then be LTS versions.
> >>>>>>>
> >>>>>>> What do you think of it?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Nicolas
> >>>>>>> ________________________________
> >>>>>>> From: Claus Ibsen <cl...@gmail.com>
> >>>>>>> Sent: Friday, November 25, 2022 11:42
> >>>>>>> To: dev <de...@camel.apache.org>
> >>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >>>>> affect
> >>>>>>> Camel 3.
> >>>>>>>
> >>>>>>> Summary
> >>>>>>>
> >>>>>>> =======
> >>>>>>>
> >>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> >>>>>>> less
> >>> than
> >>>>>>> going from Camel 2 to 3.
> >>>>>>>
> >>>>>>> And that we have a timebox approach where we aim for a 6 month
> >>>>>>> period
> >>>>> of
> >>>>>>> work.
> >>>>>>>
> >>>>>>> The need for Camel v4 is mainly driven by Java open source
> >>>>>>> projects migrating to jakarta APIs,
> >>>>>>>
> >>>>>>> and to keep up with popular runtimes a la Spring Boot and
> >>>>>>> Quarkus, and
> >>>>> to
> >>>>>>> jump to the next major Java version.
> >>>>>>>
> >>>>>>> Goals
> >>>>>>>
> >>>>>>> =====
> >>>>>>>
> >>>>>>> a) Primary Goals
> >>>>>>>
> >>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>>>>
> >>>>>>> 2) Java 17 as base line
> >>>>>>>
> >>>>>>> 3) Spring Framework 6
> >>>>>>>
> >>>>>>> 4) Spring Boot 3
> >>>>>>>
> >>>>>>> 5) Quarkus 3
> >>>>>>>
> >>>>>>> b) Release Goals
> >>>>>>>
> >>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>>>>
> >>>>>>> This means that Camel components that are not ready (yet)
> >>>>>>> will be dropped in a release until they are ready.
> >>>>>>>
> >>>>>>> 7) Release core + spring boot together
> >>>>>>>
> >>>>>>> 8) Release camel-karaf independently (like we do for other Camel
> >>>>> projects)
> >>>>>>> c) Major Goals
> >>>>>>>
> >>>>>>> 9) Support Java 17 features such as records, multiline strings,
> >>>>>>> and
> >>>>> what
> >>>>>>> else
> >>>>>>>
> >>>>>>> 10) EIP model without JAXB dependency
> >>>>>>>
> >>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>>>>
> >>>>>>> 12) Deprecate message.getIn()
> >>>>>>>
> >>>>>>> use getMessage() instead
> >>>>>>>
> >>>>>>> 13) Deprecate camel-cdi
> >>>>>>>
> >>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> >>>>>>> fit
> >>>>> modern
> >>>>>>> app development)
> >>>>>>>
> >>>>>>> d) Minor Goals
> >>>>>>>
> >>>>>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>>>>
> >>>>>>> 16) Remove JUnit 4 support
> >>>>>>>
> >>>>>>>
> >>>>>>> Timeline
> >>>>>>>
> >>>>>>> =======
> >>>>>>>
> >>>>>>> The timelines are ESTIMATES and the number of releases can vary
> >>>>> depending
> >>>>>>> on need and how far we are in the process
> >>>>>>>
> >>>>>>> Feb 2023: Camel 4.0 milestone 1
> >>>>>>>
> >>>>>>> Mar 2023: Camel 4.0 milestone 2
> >>>>>>>
> >>>>>>> Apr 2023: Camel 4.0 RC1
> >>>>>>>
> >>>>>>> May 2023: Camel 4.0
> >>>>>>>
> >>>>>>> Aug 2023: Camel 4.1 LTS
> >>>>>>>
> >>>>>>> Oct 2023: Camel 4.2
> >>>>>>>
> >>>>>>> Dec 2023: Camel 4.3 LTS
> >>>>>>>
> >>>>>>> The plan is to start working on Camel 4 after the next Camel 3
> >>>>>>> LTS
> >>>>> release,
> >>>>>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>>>>
> >>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> >>>>>>> releases
> >>>>> per
> >>>>>>> year.
> >>>>>>>
> >>>>>>> For example a scheduled could look as follows:
> >>>>>>>
> >>>>>>> Dec 2022: Camel 3.20 LTS
> >>>>>>>
> >>>>>>> Jun 2023: Camel 3.21 LTS
> >>>>>>>
> >>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> >>>>>>> Dec
> >>>>> 2024)
> >>>>>>> ???
> >>>>>>>
> >>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> >>>>>>> Dec
> >>>>> 2025)
> >>>>>>> ????
> >>>>>>>
> >>>>>>> Each Camel 3 LTS release will likely also contain less new
> >>>>>>> features
> >>> and
> >>>>>>> improvements as previously, as our focus and work shifts to Camel
> >>>>>>> v4 instead.
> >>>>>>>
> >>>>>>> As a recipient of an email from Talend, your contact personal
> >>>>>>> data
> >>>>> will be
> >>>>>>> on our systems. Please see our privacy notice. <
> >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> >>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> >>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> >>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> >>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>> --
> >>> --
> >>> François
> >>>
> >>>
> > --
> > --
> > François
> >
>
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Nov 30, 2022 at 3:56 PM Matt Pavlovich <ma...@gmail.com> 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
> <st...@sap.com.INVALID> wrote:
> >
> > Hi,
> >
> > Actually removing the OSGi manifests from the bundles coming from the
> general camel build would mean that we have to create an OSGi wrapper
> bundle for each and every jar coming out of the general build, which looks
> like a lot of maintenance effort to me.
> >
> > Best regards
> > Stephan
> >
> > -----Original Message-----
> > From: fpapon <fp...@apache.org>
> > Sent: Wednesday, 30 November 2022 14:01
> > To: dev@camel.apache.org
> > Subject: Re: Camel 4 roadmap and affect on Camel 3
> >
> > Ok so we will have a camel-core.jar and
> camel-core-with-manifest-osgi.jar just with the manifest file add-in for
> each camel core jar.
> >
> > On 30/11/2022 13:53, Andrea Cosentino wrote:
> >> This would become something karaf-camel is responsible for.
> >>
> >>
> >>
> >> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> >> scritto:
> >>
> >>> Hi,
> >>>
> >>> For this point "Camel v4 core and component JARs will no longer
> >>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
> >>> from the core Camel is a good thing...
> >>>
> >>> regards,
> >>>
> >>> François
> >>>
> >>> On 30/11/2022 10:44, Claus Ibsen wrote:
> >>>> Hi
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
> >>>> <jb...@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>>> Hi guys,
> >>>>>
> >>>>> I understand that Karaf/OSGi is not in the Camel community target
> >>>>> anymore, and it makes sense.
> >>>>> I proposed a time ago to refactor the approach of Camel components
> >>>>> for Karaf, using special packaging (embedded the deps as private to
> >>>>> avoid to have bunch of SMX bundles deps), etc.
> >>>>>
> >>>>> Even at Karaf, there are discussions about the next step in the
> >>>>> project decoupled from OSGi (see Minho).
> >>>>>
> >>>>> I would split the discussion in two parts:
> >>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
> >>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
> >>>>> always possible to wrap Camel routes in an uber jar and deploy in
> >>>>> Karaf.
> >>>>> - In terms of community/maintenance, I think camel-karaf could be
> >>>>> part of the Karaf community. We had a similar discussion about
> >>>>> jclouds: the jclouds community didn't want to maintain
> >>>>> jclouds-karaf anymore (for the same reasons as the Camel
> >>>>> community). The jclouds community asked the karaf community if they
> >>>>> were interested in maintaining and managing jclouds-karaf. So we
> >>>>> can do the same for camel-karaf: the karaf community can take the
> lead there and maintain it.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>>
> >>>> Yes i Agree on this JB.
> >>>>
> >>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
> >>>> and let the community and committers in that project take over
> >>>> maintaining
> >>> and
> >>>> releasing this.
> >>>> - For Camel v4 onwards then camel-karaf will no longer be part of
> >>>> Apache Camel.
> >>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
> >>>> and
> >>> no
> >>>> longer org.apache.camel.karaf.
> >>>> - Camel v4 core and component JARs will no longer generate OSGi
> >>> MANIFEST.MF
> >>>> as Karaf Camel will be responsible for this (if even needed); such
> >>>> as JB talks about a new way of packing and running things in Karaf.
> >>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
> >>>> until Camel 3 is EOL
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
> >>>>> <an...@gmail.com>
> >>>>> wrote:
> >>>>>> Hello
> >>>>>>
> >>>>>> I'll come back for other questions. Let me just say that
> >>>>>> camel-karaf is
> >>>>> too
> >>>>>> hard to maintain today. If it won't be released because of
> >>> misalignments,
> >>>>>> it should be aligned by some volunteers or community member and
> >>> released
> >>>>>> later. Active contributors are not really focused on Karaf runtime
> >>>>>> and
> >>> we
> >>>>>> cannot do everything. This doesn't mean we won't release camel
> >>>>>> Karaf anymore. It only means it could be released later on. Even
> >>>>>> after the
> >>> core
> >>>>>> camel and SB part have been released.
> >>>>>>
> >>>>>> In more than one situation aligning OSGi stuff have been really
> hard.
> >>>>> Less
> >>>>>> and less community members are helping on the Karaf side and
> >>>>>> releasing sometimes have been slow down by these troubles. Also
> >>>>>> OSGi have been
> >>> drop
> >>>>>> in a lot of 3rd party libraries.
> >>>>>>
> >>>>>> So I'm +1 with this approach.
> >>>>>>
> >>>>>> I'll continue the discussion in the next days for the other points.
> >>>>>>
> >>>>>> Cheers
> >>>>>>
> >>>>>>
> >>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >>>>> scritto:
> >>>>>>> Hi Claus,
> >>>>>>>
> >>>>>>> That sounds like a good plan, here are the first questions that I
> >>>>>>> have
> >>>>> in
> >>>>>>> mind:
> >>>>>>>
> >>>>>>> * Why do we need to keep on releasing new LTS versions of
> Camel
> >>> 3?
> >>>>>>> * Why not simply consider 3.20 as the last LTS version of
> Camel 3
> >>>>> and
> >>>>>>> only maintain it?
> >>>>>>> * What kind of features/improvements do you want to add to
> Camel
> >>> 3
> >>>>>>> after releasing 3.20?
> >>>>>>> * If camel-karaf is released independently, when will it be
> >>>>> released?
> >>>>>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>>>>> *
> >>>>>>>
> >>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
> >>>>>>> mean 4
> >>>>> LTS
> >>>>>>> versions to support at the same time, don't you think that it is
> >>>>>>> too
> >>>>> many?
> >>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >>>>> version
> >>>>>>> policy. Could you please remind me why we decided to have this
> >>>>>>> policy
> >>>>> (2
> >>>>>>> LTS versions per year supported for one year)?
> >>>>>>>
> >>>>>>> I would personally prefer to have:
> >>>>>>>
> >>>>>>> * only one LTS version per year (or 2 if we keep on releasing
> LTS
> >>>>>>> versions of Camel 3) but supported for at least 2 years instead
> >>>>>>> of one otherwise Camel users are less inclined to migrate to the
> >>>>>>> latest LTS version because 1 year of support doesn't really worth
> >>>>>>> the migration effort, especially for big projects where the
> >>>>>>> migration takes several months.
> >>>>>>> * only propose milestone versions or equivalent between 2 LTS
> >>>>> versions
> >>>>>>> for early adopters to add more clarity on which versions are LTS.
> >>>>> Indeed,
> >>>>>>> for example, the next LTS version will be 3.20 while we could
> >>>>>>> expect
> >>>>> 3.22
> >>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> >>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
> >>>>>>> 3.19, it
> >>>>> would
> >>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> >>>>>>> version as
> >>>>> all
> >>>>>>> final versions would then be LTS versions.
> >>>>>>>
> >>>>>>> What do you think of it?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Nicolas
> >>>>>>> ________________________________
> >>>>>>> From: Claus Ibsen <cl...@gmail.com>
> >>>>>>> Sent: Friday, November 25, 2022 11:42
> >>>>>>> To: dev <de...@camel.apache.org>
> >>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >>>>> affect
> >>>>>>> Camel 3.
> >>>>>>>
> >>>>>>> Summary
> >>>>>>>
> >>>>>>> =======
> >>>>>>>
> >>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
> >>>>>>> less
> >>> than
> >>>>>>> going from Camel 2 to 3.
> >>>>>>>
> >>>>>>> And that we have a timebox approach where we aim for a 6 month
> >>>>>>> period
> >>>>> of
> >>>>>>> work.
> >>>>>>>
> >>>>>>> The need for Camel v4 is mainly driven by Java open source
> >>>>>>> projects migrating to jakarta APIs,
> >>>>>>>
> >>>>>>> and to keep up with popular runtimes a la Spring Boot and
> >>>>>>> Quarkus, and
> >>>>> to
> >>>>>>> jump to the next major Java version.
> >>>>>>>
> >>>>>>> Goals
> >>>>>>>
> >>>>>>> =====
> >>>>>>>
> >>>>>>> a) Primary Goals
> >>>>>>>
> >>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>>>>
> >>>>>>> 2) Java 17 as base line
> >>>>>>>
> >>>>>>> 3) Spring Framework 6
> >>>>>>>
> >>>>>>> 4) Spring Boot 3
> >>>>>>>
> >>>>>>> 5) Quarkus 3
> >>>>>>>
> >>>>>>> b) Release Goals
> >>>>>>>
> >>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>>>>
> >>>>>>> This means that Camel components that are not ready (yet)
> >>>>>>> will be dropped in a release until they are ready.
> >>>>>>>
> >>>>>>> 7) Release core + spring boot together
> >>>>>>>
> >>>>>>> 8) Release camel-karaf independently (like we do for other Camel
> >>>>> projects)
> >>>>>>> c) Major Goals
> >>>>>>>
> >>>>>>> 9) Support Java 17 features such as records, multiline strings,
> >>>>>>> and
> >>>>> what
> >>>>>>> else
> >>>>>>>
> >>>>>>> 10) EIP model without JAXB dependency
> >>>>>>>
> >>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>>>>
> >>>>>>> 12) Deprecate message.getIn()
> >>>>>>>
> >>>>>>> use getMessage() instead
> >>>>>>>
> >>>>>>> 13) Deprecate camel-cdi
> >>>>>>>
> >>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> >>>>>>> fit
> >>>>> modern
> >>>>>>> app development)
> >>>>>>>
> >>>>>>> d) Minor Goals
> >>>>>>>
> >>>>>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>>>>
> >>>>>>> 16) Remove JUnit 4 support
> >>>>>>>
> >>>>>>>
> >>>>>>> Timeline
> >>>>>>>
> >>>>>>> =======
> >>>>>>>
> >>>>>>> The timelines are ESTIMATES and the number of releases can vary
> >>>>> depending
> >>>>>>> on need and how far we are in the process
> >>>>>>>
> >>>>>>> Feb 2023: Camel 4.0 milestone 1
> >>>>>>>
> >>>>>>> Mar 2023: Camel 4.0 milestone 2
> >>>>>>>
> >>>>>>> Apr 2023: Camel 4.0 RC1
> >>>>>>>
> >>>>>>> May 2023: Camel 4.0
> >>>>>>>
> >>>>>>> Aug 2023: Camel 4.1 LTS
> >>>>>>>
> >>>>>>> Oct 2023: Camel 4.2
> >>>>>>>
> >>>>>>> Dec 2023: Camel 4.3 LTS
> >>>>>>>
> >>>>>>> The plan is to start working on Camel 4 after the next Camel 3
> >>>>>>> LTS
> >>>>> release,
> >>>>>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>>>>
> >>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> >>>>>>> releases
> >>>>> per
> >>>>>>> year.
> >>>>>>>
> >>>>>>> For example a scheduled could look as follows:
> >>>>>>>
> >>>>>>> Dec 2022: Camel 3.20 LTS
> >>>>>>>
> >>>>>>> Jun 2023: Camel 3.21 LTS
> >>>>>>>
> >>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> >>>>>>> Dec
> >>>>> 2024)
> >>>>>>> ???
> >>>>>>>
> >>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> >>>>>>> Dec
> >>>>> 2025)
> >>>>>>> ????
> >>>>>>>
> >>>>>>> Each Camel 3 LTS release will likely also contain less new
> >>>>>>> features
> >>> and
> >>>>>>> improvements as previously, as our focus and work shifts to Camel
> >>>>>>> v4 instead.
> >>>>>>>
> >>>>>>> As a recipient of an email from Talend, your contact personal
> >>>>>>> data
> >>>>> will be
> >>>>>>> on our systems. Please see our privacy notice. <
> >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
> >>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
> >>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
> >>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
> >>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>> --
> >>> --
> >>> François
> >>>
> >>>
> > --
> > --
> > François
> >
>
>
--
Claus Ibsen
-----------------
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Posted by Matt Pavlovich <ma...@gmail.com>.
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 <st...@sap.com.INVALID> wrote:
>
> Hi,
>
> Actually removing the OSGi manifests from the bundles coming from the general camel build would mean that we have to create an OSGi wrapper bundle for each and every jar coming out of the general build, which looks like a lot of maintenance effort to me.
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: fpapon <fp...@apache.org>
> Sent: Wednesday, 30 November 2022 14:01
> To: dev@camel.apache.org
> Subject: Re: Camel 4 roadmap and affect on Camel 3
>
> Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar just with the manifest file add-in for each camel core jar.
>
> On 30/11/2022 13:53, Andrea Cosentino wrote:
>> This would become something karaf-camel is responsible for.
>>
>>
>>
>> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
>> scritto:
>>
>>> Hi,
>>>
>>> For this point "Camel v4 core and component JARs will no longer
>>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>>> from the core Camel is a good thing...
>>>
>>> regards,
>>>
>>> François
>>>
>>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>>> Hi
>>>>
>>>>
>>>>
>>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>>> <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>>> anymore, and it makes sense.
>>>>> I proposed a time ago to refactor the approach of Camel components
>>>>> for Karaf, using special packaging (embedded the deps as private to
>>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>>
>>>>> Even at Karaf, there are discussions about the next step in the
>>>>> project decoupled from OSGi (see Minho).
>>>>>
>>>>> I would split the discussion in two parts:
>>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>>> Karaf.
>>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>>> part of the Karaf community. We had a similar discussion about
>>>>> jclouds: the jclouds community didn't want to maintain
>>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>>> community). The jclouds community asked the karaf community if they
>>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>>> can do the same for camel-karaf: the karaf community can take the lead there and maintain it.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>>
>>>> Yes i Agree on this JB.
>>>>
>>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>>> and let the community and committers in that project take over
>>>> maintaining
>>> and
>>>> releasing this.
>>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>>> Apache Camel.
>>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>>> and
>>> no
>>>> longer org.apache.camel.karaf.
>>>> - Camel v4 core and component JARs will no longer generate OSGi
>>> MANIFEST.MF
>>>> as Karaf Camel will be responsible for this (if even needed); such
>>>> as JB talks about a new way of packing and running things in Karaf.
>>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>>> until Camel 3 is EOL
>>>>
>>>>
>>>>
>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>>> <an...@gmail.com>
>>>>> wrote:
>>>>>> Hello
>>>>>>
>>>>>> I'll come back for other questions. Let me just say that
>>>>>> camel-karaf is
>>>>> too
>>>>>> hard to maintain today. If it won't be released because of
>>> misalignments,
>>>>>> it should be aligned by some volunteers or community member and
>>> released
>>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>>> and
>>> we
>>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>>> after the
>>> core
>>>>>> camel and SB part have been released.
>>>>>>
>>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>>> Less
>>>>>> and less community members are helping on the Karaf side and
>>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>>> OSGi have been
>>> drop
>>>>>> in a lot of 3rd party libraries.
>>>>>>
>>>>>> So I'm +1 with this approach.
>>>>>>
>>>>>> I'll continue the discussion in the next days for the other points.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>>> scritto:
>>>>>>> Hi Claus,
>>>>>>>
>>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>>> have
>>>>> in
>>>>>>> mind:
>>>>>>>
>>>>>>> * Why do we need to keep on releasing new LTS versions of Camel
>>> 3?
>>>>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
>>>>> and
>>>>>>> only maintain it?
>>>>>>> * What kind of features/improvements do you want to add to Camel
>>> 3
>>>>>>> after releasing 3.20?
>>>>>>> * If camel-karaf is released independently, when will it be
>>>>> released?
>>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>>> *
>>>>>>>
>>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>>> mean 4
>>>>> LTS
>>>>>>> versions to support at the same time, don't you think that it is
>>>>>>> too
>>>>> many?
>>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>>> version
>>>>>>> policy. Could you please remind me why we decided to have this
>>>>>>> policy
>>>>> (2
>>>>>>> LTS versions per year supported for one year)?
>>>>>>>
>>>>>>> I would personally prefer to have:
>>>>>>>
>>>>>>> * only one LTS version per year (or 2 if we keep on releasing LTS
>>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>>> the migration effort, especially for big projects where the
>>>>>>> migration takes several months.
>>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>>> versions
>>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>>> Indeed,
>>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>>> expect
>>>>> 3.22
>>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>>> 3.19, it
>>>>> would
>>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>>> version as
>>>>> all
>>>>>>> final versions would then be LTS versions.
>>>>>>>
>>>>>>> What do you think of it?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nicolas
>>>>>>> ________________________________
>>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>>> To: dev <de...@camel.apache.org>
>>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>>> affect
>>>>>>> Camel 3.
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> =======
>>>>>>>
>>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>>> less
>>> than
>>>>>>> going from Camel 2 to 3.
>>>>>>>
>>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>>> period
>>>>> of
>>>>>>> work.
>>>>>>>
>>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>>> projects migrating to jakarta APIs,
>>>>>>>
>>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>>> Quarkus, and
>>>>> to
>>>>>>> jump to the next major Java version.
>>>>>>>
>>>>>>> Goals
>>>>>>>
>>>>>>> =====
>>>>>>>
>>>>>>> a) Primary Goals
>>>>>>>
>>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>>
>>>>>>> 2) Java 17 as base line
>>>>>>>
>>>>>>> 3) Spring Framework 6
>>>>>>>
>>>>>>> 4) Spring Boot 3
>>>>>>>
>>>>>>> 5) Quarkus 3
>>>>>>>
>>>>>>> b) Release Goals
>>>>>>>
>>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>>
>>>>>>> This means that Camel components that are not ready (yet)
>>>>>>> will be dropped in a release until they are ready.
>>>>>>>
>>>>>>> 7) Release core + spring boot together
>>>>>>>
>>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>>> projects)
>>>>>>> c) Major Goals
>>>>>>>
>>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>>> and
>>>>> what
>>>>>>> else
>>>>>>>
>>>>>>> 10) EIP model without JAXB dependency
>>>>>>>
>>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>>
>>>>>>> 12) Deprecate message.getIn()
>>>>>>>
>>>>>>> use getMessage() instead
>>>>>>>
>>>>>>> 13) Deprecate camel-cdi
>>>>>>>
>>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>>> fit
>>>>> modern
>>>>>>> app development)
>>>>>>>
>>>>>>> d) Minor Goals
>>>>>>>
>>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>>
>>>>>>> 16) Remove JUnit 4 support
>>>>>>>
>>>>>>>
>>>>>>> Timeline
>>>>>>>
>>>>>>> =======
>>>>>>>
>>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>>> depending
>>>>>>> on need and how far we are in the process
>>>>>>>
>>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>>
>>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>>
>>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>>
>>>>>>> May 2023: Camel 4.0
>>>>>>>
>>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>>
>>>>>>> Oct 2023: Camel 4.2
>>>>>>>
>>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>>
>>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>>> LTS
>>>>> release,
>>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>>
>>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>>> releases
>>>>> per
>>>>>>> year.
>>>>>>>
>>>>>>> For example a scheduled could look as follows:
>>>>>>>
>>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>>
>>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>>
>>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>>> Dec
>>>>> 2024)
>>>>>>> ???
>>>>>>>
>>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>>> Dec
>>>>> 2025)
>>>>>>> ????
>>>>>>>
>>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>>> features
>>> and
>>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>>> v4 instead.
>>>>>>>
>>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>>> data
>>>>> will be
>>>>>>> on our systems. Please see our privacy notice. <
>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>>
>>>>>>>
>>>>>>>
>>> --
>>> --
>>> François
>>>
>>>
> --
> --
> François
>
RE: Camel 4 roadmap and affect on Camel 3
Posted by "Siano, Stephan" <st...@sap.com.INVALID>.
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 <fp...@apache.org>
Sent: Wednesday, 30 November 2022 14:01
To: dev@camel.apache.org
Subject: Re: Camel 4 roadmap and affect on Camel 3
Ok so we will have a camel-core.jar and camel-core-with-manifest-osgi.jar just with the manifest file add-in for each camel core jar.
On 30/11/2022 13:53, Andrea Cosentino wrote:
> This would become something karaf-camel is responsible for.
>
>
>
> Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
> scritto:
>
>> Hi,
>>
>> For this point "Camel v4 core and component JARs will no longer
>> generate OSGi MANIFEST.MF" I'm not sure that removing the generation
>> from the core Camel is a good thing...
>>
>> regards,
>>
>> François
>>
>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>> Hi
>>>
>>>
>>>
>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré
>>> <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>> anymore, and it makes sense.
>>>> I proposed a time ago to refactor the approach of Camel components
>>>> for Karaf, using special packaging (embedded the deps as private to
>>>> avoid to have bunch of SMX bundles deps), etc.
>>>>
>>>> Even at Karaf, there are discussions about the next step in the
>>>> project decoupled from OSGi (see Minho).
>>>>
>>>> I would split the discussion in two parts:
>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>> Karaf.
>>>> - In terms of community/maintenance, I think camel-karaf could be
>>>> part of the Karaf community. We had a similar discussion about
>>>> jclouds: the jclouds community didn't want to maintain
>>>> jclouds-karaf anymore (for the same reasons as the Camel
>>>> community). The jclouds community asked the karaf community if they
>>>> were interested in maintaining and managing jclouds-karaf. So we
>>>> can do the same for camel-karaf: the karaf community can take the lead there and maintain it.
>>>>
>>>> Thoughts ?
>>>>
>>>>
>>> Yes i Agree on this JB.
>>>
>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project,
>>> and let the community and committers in that project take over
>>> maintaining
>> and
>>> releasing this.
>>> - For Camel v4 onwards then camel-karaf will no longer be part of
>>> Apache Camel.
>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel,
>>> and
>> no
>>> longer org.apache.camel.karaf.
>>> - Camel v4 core and component JARs will no longer generate OSGi
>> MANIFEST.MF
>>> as Karaf Camel will be responsible for this (if even needed); such
>>> as JB talks about a new way of packing and running things in Karaf.
>>> - For Camel v3 we keep as-is and maintain and release camel-karaf
>>> until Camel 3 is EOL
>>>
>>>
>>>
>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino
>>>> <an...@gmail.com>
>>>> wrote:
>>>>> Hello
>>>>>
>>>>> I'll come back for other questions. Let me just say that
>>>>> camel-karaf is
>>>> too
>>>>> hard to maintain today. If it won't be released because of
>> misalignments,
>>>>> it should be aligned by some volunteers or community member and
>> released
>>>>> later. Active contributors are not really focused on Karaf runtime
>>>>> and
>> we
>>>>> cannot do everything. This doesn't mean we won't release camel
>>>>> Karaf anymore. It only means it could be released later on. Even
>>>>> after the
>> core
>>>>> camel and SB part have been released.
>>>>>
>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>> Less
>>>>> and less community members are helping on the Karaf side and
>>>>> releasing sometimes have been slow down by these troubles. Also
>>>>> OSGi have been
>> drop
>>>>> in a lot of 3rd party libraries.
>>>>>
>>>>> So I'm +1 with this approach.
>>>>>
>>>>> I'll continue the discussion in the next days for the other points.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>> scritto:
>>>>>> Hi Claus,
>>>>>>
>>>>>> That sounds like a good plan, here are the first questions that I
>>>>>> have
>>>> in
>>>>>> mind:
>>>>>>
>>>>>> * Why do we need to keep on releasing new LTS versions of Camel
>> 3?
>>>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
>>>> and
>>>>>> only maintain it?
>>>>>> * What kind of features/improvements do you want to add to Camel
>> 3
>>>>>> after releasing 3.20?
>>>>>> * If camel-karaf is released independently, when will it be
>>>> released?
>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>> *
>>>>>>
>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would
>>>>>> mean 4
>>>> LTS
>>>>>> versions to support at the same time, don't you think that it is
>>>>>> too
>>>> many?
>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>> version
>>>>>> policy. Could you please remind me why we decided to have this
>>>>>> policy
>>>> (2
>>>>>> LTS versions per year supported for one year)?
>>>>>>
>>>>>> I would personally prefer to have:
>>>>>>
>>>>>> * only one LTS version per year (or 2 if we keep on releasing LTS
>>>>>> versions of Camel 3) but supported for at least 2 years instead
>>>>>> of one otherwise Camel users are less inclined to migrate to the
>>>>>> latest LTS version because 1 year of support doesn't really worth
>>>>>> the migration effort, especially for big projects where the
>>>>>> migration takes several months.
>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>> versions
>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>> Indeed,
>>>>>> for example, the next LTS version will be 3.20 while we could
>>>>>> expect
>>>> 3.22
>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
>>>>>> of releasing 3.19 and 3.20, we could have released 3.19 M1 and
>>>>>> 3.19, it
>>>> would
>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>>>>>> version as
>>>> all
>>>>>> final versions would then be LTS versions.
>>>>>>
>>>>>> What do you think of it?
>>>>>>
>>>>>> Regards,
>>>>>> Nicolas
>>>>>> ________________________________
>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>> To: dev <de...@camel.apache.org>
>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>> affect
>>>>>> Camel 3.
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot
>>>>>> less
>> than
>>>>>> going from Camel 2 to 3.
>>>>>>
>>>>>> And that we have a timebox approach where we aim for a 6 month
>>>>>> period
>>>> of
>>>>>> work.
>>>>>>
>>>>>> The need for Camel v4 is mainly driven by Java open source
>>>>>> projects migrating to jakarta APIs,
>>>>>>
>>>>>> and to keep up with popular runtimes a la Spring Boot and
>>>>>> Quarkus, and
>>>> to
>>>>>> jump to the next major Java version.
>>>>>>
>>>>>> Goals
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> a) Primary Goals
>>>>>>
>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>
>>>>>> 2) Java 17 as base line
>>>>>>
>>>>>> 3) Spring Framework 6
>>>>>>
>>>>>> 4) Spring Boot 3
>>>>>>
>>>>>> 5) Quarkus 3
>>>>>>
>>>>>> b) Release Goals
>>>>>>
>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>
>>>>>> This means that Camel components that are not ready (yet)
>>>>>> will be dropped in a release until they are ready.
>>>>>>
>>>>>> 7) Release core + spring boot together
>>>>>>
>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>> projects)
>>>>>> c) Major Goals
>>>>>>
>>>>>> 9) Support Java 17 features such as records, multiline strings,
>>>>>> and
>>>> what
>>>>>> else
>>>>>>
>>>>>> 10) EIP model without JAXB dependency
>>>>>>
>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>
>>>>>> 12) Deprecate message.getIn()
>>>>>>
>>>>>> use getMessage() instead
>>>>>>
>>>>>> 13) Deprecate camel-cdi
>>>>>>
>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>>>>>> fit
>>>> modern
>>>>>> app development)
>>>>>>
>>>>>> d) Minor Goals
>>>>>>
>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>
>>>>>> 16) Remove JUnit 4 support
>>>>>>
>>>>>>
>>>>>> Timeline
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>> depending
>>>>>> on need and how far we are in the process
>>>>>>
>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>
>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>
>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>
>>>>>> May 2023: Camel 4.0
>>>>>>
>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>
>>>>>> Oct 2023: Camel 4.2
>>>>>>
>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>
>>>>>> The plan is to start working on Camel 4 after the next Camel 3
>>>>>> LTS
>>>> release,
>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>
>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>>>>>> releases
>>>> per
>>>>>> year.
>>>>>>
>>>>>> For example a scheduled could look as follows:
>>>>>>
>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>
>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>
>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>>>>>> Dec
>>>> 2024)
>>>>>> ???
>>>>>>
>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>>>>>> Dec
>>>> 2025)
>>>>>> ????
>>>>>>
>>>>>> Each Camel 3 LTS release will likely also contain less new
>>>>>> features
>> and
>>>>>> improvements as previously, as our focus and work shifts to Camel
>>>>>> v4 instead.
>>>>>>
>>>>>> As a recipient of an email from Talend, your contact personal
>>>>>> data
>>>> will be
>>>>>> on our systems. Please see our privacy notice. <
>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fwww.talend.com%2Fprivacy%2F&data=05%7C01%7Cstephan.siano%40s
>>>>>> ap.com%7C6302a2e9a38c4dc2423c08dad2d2f42f%7C42f7676cf455423c82f6d
>>>>>> c2d99791af7%7C0%7C0%7C638054100730523340%7CUnknown%7CTWFpbGZsb3d8
>>>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>>>> D%7C3000%7C%7C%7C&sdata=sGU2aYvZB2Ksr0%2B%2FZ%2BonGQnPPJl9Raa
>>>>>> Cve%2FjzzKmXVk%3D&reserved=0>
>>>>>>
>>>>>>
>>>>>>
>> --
>> --
>> François
>>
>>
--
--
François
Re: Camel 4 roadmap and affect on Camel 3
Posted by fpapon <fp...@apache.org>.
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 <fp...@apache.org> ha
> scritto:
>
>> Hi,
>>
>> For this point "Camel v4 core and component JARs will no longer generate
>> OSGi MANIFEST.MF" I'm not sure that removing the generation from the
>> core Camel is a good thing...
>>
>> regards,
>>
>> François
>>
>> On 30/11/2022 10:44, Claus Ibsen wrote:
>>> Hi
>>>
>>>
>>>
>>> On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I understand that Karaf/OSGi is not in the Camel community target
>>>> anymore, and it makes sense.
>>>> I proposed a time ago to refactor the approach of Camel components for
>>>> Karaf, using special packaging (embedded the deps as private to avoid
>>>> to have bunch of SMX bundles deps), etc.
>>>>
>>>> Even at Karaf, there are discussions about the next step in the
>>>> project decoupled from OSGi (see Minho).
>>>>
>>>> I would split the discussion in two parts:
>>>> - In terms of the roadmap/Camel future, I don't think it's worth it
>>>> for Camel community to maintain OSGi/Karaf support anymore. It's
>>>> always possible to wrap Camel routes in an uber jar and deploy in
>>>> Karaf.
>>>> - In terms of community/maintenance, I think camel-karaf could be part
>>>> of the Karaf community. We had a similar discussion about jclouds: the
>>>> jclouds community didn't want to maintain jclouds-karaf anymore (for
>>>> the same reasons as the Camel community). The jclouds community asked
>>>> the karaf community if they were interested in maintaining and
>>>> managing jclouds-karaf. So we can do the same for camel-karaf: the
>>>> karaf community can take the lead there and maintain it.
>>>>
>>>> Thoughts ?
>>>>
>>>>
>>> Yes i Agree on this JB.
>>>
>>> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project, and
>>> let the community and committers in that project take over maintaining
>> and
>>> releasing this.
>>> - For Camel v4 onwards then camel-karaf will no longer be part of Apache
>>> Camel.
>>> - Karaf Camel is released under a new GAV - org.apache.karaf.camel, and
>> no
>>> longer org.apache.camel.karaf.
>>> - Camel v4 core and component JARs will no longer generate OSGi
>> MANIFEST.MF
>>> as Karaf Camel will be responsible for this (if even needed); such as JB
>>> talks about a new way of packing and running things in Karaf.
>>> - For Camel v3 we keep as-is and maintain and release camel-karaf until
>>> Camel 3 is EOL
>>>
>>>
>>>
>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino <an...@gmail.com>
>>>> wrote:
>>>>> Hello
>>>>>
>>>>> I'll come back for other questions. Let me just say that camel-karaf is
>>>> too
>>>>> hard to maintain today. If it won't be released because of
>> misalignments,
>>>>> it should be aligned by some volunteers or community member and
>> released
>>>>> later. Active contributors are not really focused on Karaf runtime and
>> we
>>>>> cannot do everything. This doesn't mean we won't release camel Karaf
>>>>> anymore. It only means it could be released later on. Even after the
>> core
>>>>> camel and SB part have been released.
>>>>>
>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>> Less
>>>>> and less community members are helping on the Karaf side and releasing
>>>>> sometimes have been slow down by these troubles. Also OSGi have been
>> drop
>>>>> in a lot of 3rd party libraries.
>>>>>
>>>>> So I'm +1 with this approach.
>>>>>
>>>>> I'll continue the discussion in the next days for the other points.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>> scritto:
>>>>>> Hi Claus,
>>>>>>
>>>>>> That sounds like a good plan, here are the first questions that I have
>>>> in
>>>>>> mind:
>>>>>>
>>>>>> * Why do we need to keep on releasing new LTS versions of Camel
>> 3?
>>>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
>>>> and
>>>>>> only maintain it?
>>>>>> * What kind of features/improvements do you want to add to Camel
>> 3
>>>>>> after releasing 3.20?
>>>>>> * If camel-karaf is released independently, when will it be
>>>> released?
>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>> *
>>>>>>
>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
>>>> LTS
>>>>>> versions to support at the same time, don't you think that it is too
>>>> many?
>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>> version
>>>>>> policy. Could you please remind me why we decided to have this policy
>>>> (2
>>>>>> LTS versions per year supported for one year)?
>>>>>>
>>>>>> I would personally prefer to have:
>>>>>>
>>>>>> * only one LTS version per year (or 2 if we keep on releasing LTS
>>>>>> versions of Camel 3) but supported for at least 2 years instead of one
>>>>>> otherwise Camel users are less inclined to migrate to the latest LTS
>>>>>> version because 1 year of support doesn't really worth the migration
>>>>>> effort, especially for big projects where the migration takes several
>>>>>> months.
>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>> versions
>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>> Indeed,
>>>>>> for example, the next LTS version will be 3.20 while we could expect
>>>> 3.22
>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead of
>>>>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
>>>> would
>>>>>> then be obvious to the Camel users that only 3.19 is an LTS version as
>>>> all
>>>>>> final versions would then be LTS versions.
>>>>>>
>>>>>> What do you think of it?
>>>>>>
>>>>>> Regards,
>>>>>> Nicolas
>>>>>> ________________________________
>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>> To: dev <de...@camel.apache.org>
>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>> affect
>>>>>> Camel 3.
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot less
>> than
>>>>>> going from Camel 2 to 3.
>>>>>>
>>>>>> And that we have a timebox approach where we aim for a 6 month period
>>>> of
>>>>>> work.
>>>>>>
>>>>>> The need for Camel v4 is mainly driven by Java open source projects
>>>>>> migrating to jakarta APIs,
>>>>>>
>>>>>> and to keep up with popular runtimes a la Spring Boot and Quarkus, and
>>>> to
>>>>>> jump to the next major Java version.
>>>>>>
>>>>>> Goals
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> a) Primary Goals
>>>>>>
>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>
>>>>>> 2) Java 17 as base line
>>>>>>
>>>>>> 3) Spring Framework 6
>>>>>>
>>>>>> 4) Spring Boot 3
>>>>>>
>>>>>> 5) Quarkus 3
>>>>>>
>>>>>> b) Release Goals
>>>>>>
>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>
>>>>>> This means that Camel components that are not ready (yet) will be
>>>>>> dropped in a release until they are ready.
>>>>>>
>>>>>> 7) Release core + spring boot together
>>>>>>
>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>> projects)
>>>>>> c) Major Goals
>>>>>>
>>>>>> 9) Support Java 17 features such as records, multiline strings, and
>>>> what
>>>>>> else
>>>>>>
>>>>>> 10) EIP model without JAXB dependency
>>>>>>
>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>
>>>>>> 12) Deprecate message.getIn()
>>>>>>
>>>>>> use getMessage() instead
>>>>>>
>>>>>> 13) Deprecate camel-cdi
>>>>>>
>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
>>>> modern
>>>>>> app development)
>>>>>>
>>>>>> d) Minor Goals
>>>>>>
>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>
>>>>>> 16) Remove JUnit 4 support
>>>>>>
>>>>>>
>>>>>> Timeline
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>> depending
>>>>>> on need and how far we are in the process
>>>>>>
>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>
>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>
>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>
>>>>>> May 2023: Camel 4.0
>>>>>>
>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>
>>>>>> Oct 2023: Camel 4.2
>>>>>>
>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>
>>>>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
>>>> release,
>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>
>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS releases
>>>> per
>>>>>> year.
>>>>>>
>>>>>> For example a scheduled could look as follows:
>>>>>>
>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>
>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>
>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
>>>> 2024)
>>>>>> ???
>>>>>>
>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
>>>> 2025)
>>>>>> ????
>>>>>>
>>>>>> Each Camel 3 LTS release will likely also contain less new features
>> and
>>>>>> improvements as previously, as our focus and work shifts to Camel v4
>>>>>> instead.
>>>>>>
>>>>>> As a recipient of an email from Talend, your contact personal data
>>>> will be
>>>>>> on our systems. Please see our privacy notice. <
>>>>>> https://www.talend.com/privacy/>
>>>>>>
>>>>>>
>>>>>>
>> --
>> --
>> François
>>
>>
--
--
François
Re: Camel 4 roadmap and affect on Camel 3
Posted by Andrea Cosentino <an...@gmail.com>.
This would become something karaf-camel is responsible for.
Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fp...@apache.org> ha
scritto:
> Hi,
>
> For this point "Camel v4 core and component JARs will no longer generate
> OSGi MANIFEST.MF" I'm not sure that removing the generation from the
> core Camel is a good thing...
>
> regards,
>
> François
>
> On 30/11/2022 10:44, Claus Ibsen wrote:
> > Hi
> >
> >
> >
> > On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> >> Hi guys,
> >>
> >> I understand that Karaf/OSGi is not in the Camel community target
> >> anymore, and it makes sense.
> >> I proposed a time ago to refactor the approach of Camel components for
> >> Karaf, using special packaging (embedded the deps as private to avoid
> >> to have bunch of SMX bundles deps), etc.
> >>
> >> Even at Karaf, there are discussions about the next step in the
> >> project decoupled from OSGi (see Minho).
> >>
> >> I would split the discussion in two parts:
> >> - In terms of the roadmap/Camel future, I don't think it's worth it
> >> for Camel community to maintain OSGi/Karaf support anymore. It's
> >> always possible to wrap Camel routes in an uber jar and deploy in
> >> Karaf.
> >> - In terms of community/maintenance, I think camel-karaf could be part
> >> of the Karaf community. We had a similar discussion about jclouds: the
> >> jclouds community didn't want to maintain jclouds-karaf anymore (for
> >> the same reasons as the Camel community). The jclouds community asked
> >> the karaf community if they were interested in maintaining and
> >> managing jclouds-karaf. So we can do the same for camel-karaf: the
> >> karaf community can take the lead there and maintain it.
> >>
> >> Thoughts ?
> >>
> >>
> > Yes i Agree on this JB.
> >
> > - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project, and
> > let the community and committers in that project take over maintaining
> and
> > releasing this.
> > - For Camel v4 onwards then camel-karaf will no longer be part of Apache
> > Camel.
> > - Karaf Camel is released under a new GAV - org.apache.karaf.camel, and
> no
> > longer org.apache.camel.karaf.
> > - Camel v4 core and component JARs will no longer generate OSGi
> MANIFEST.MF
> > as Karaf Camel will be responsible for this (if even needed); such as JB
> > talks about a new way of packing and running things in Karaf.
> > - For Camel v3 we keep as-is and maintain and release camel-karaf until
> > Camel 3 is EOL
> >
> >
> >
> >
> >> Regards
> >> JB
> >>
> >> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino <an...@gmail.com>
> >> wrote:
> >>> Hello
> >>>
> >>> I'll come back for other questions. Let me just say that camel-karaf is
> >> too
> >>> hard to maintain today. If it won't be released because of
> misalignments,
> >>> it should be aligned by some volunteers or community member and
> released
> >>> later. Active contributors are not really focused on Karaf runtime and
> we
> >>> cannot do everything. This doesn't mean we won't release camel Karaf
> >>> anymore. It only means it could be released later on. Even after the
> core
> >>> camel and SB part have been released.
> >>>
> >>> In more than one situation aligning OSGi stuff have been really hard.
> >> Less
> >>> and less community members are helping on the Karaf side and releasing
> >>> sometimes have been slow down by these troubles. Also OSGi have been
> drop
> >>> in a lot of 3rd party libraries.
> >>>
> >>> So I'm +1 with this approach.
> >>>
> >>> I'll continue the discussion in the next days for the other points.
> >>>
> >>> Cheers
> >>>
> >>>
> >>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >> scritto:
> >>>> Hi Claus,
> >>>>
> >>>> That sounds like a good plan, here are the first questions that I have
> >> in
> >>>> mind:
> >>>>
> >>>> * Why do we need to keep on releasing new LTS versions of Camel
> 3?
> >>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
> >> and
> >>>> only maintain it?
> >>>> * What kind of features/improvements do you want to add to Camel
> 3
> >>>> after releasing 3.20?
> >>>> * If camel-karaf is released independently, when will it be
> >> released?
> >>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>> *
> >>>>
> >>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
> >> LTS
> >>>> versions to support at the same time, don't you think that it is too
> >> many?
> >>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >> version
> >>>> policy. Could you please remind me why we decided to have this policy
> >> (2
> >>>> LTS versions per year supported for one year)?
> >>>>
> >>>> I would personally prefer to have:
> >>>>
> >>>> * only one LTS version per year (or 2 if we keep on releasing LTS
> >>>> versions of Camel 3) but supported for at least 2 years instead of one
> >>>> otherwise Camel users are less inclined to migrate to the latest LTS
> >>>> version because 1 year of support doesn't really worth the migration
> >>>> effort, especially for big projects where the migration takes several
> >>>> months.
> >>>> * only propose milestone versions or equivalent between 2 LTS
> >> versions
> >>>> for early adopters to add more clarity on which versions are LTS.
> >> Indeed,
> >>>> for example, the next LTS version will be 3.20 while we could expect
> >> 3.22
> >>>> to be the next one after 3.14 and 3.18. With this logic, instead of
> >>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
> >> would
> >>>> then be obvious to the Camel users that only 3.19 is an LTS version as
> >> all
> >>>> final versions would then be LTS versions.
> >>>>
> >>>> What do you think of it?
> >>>>
> >>>> Regards,
> >>>> Nicolas
> >>>> ________________________________
> >>>> From: Claus Ibsen <cl...@gmail.com>
> >>>> Sent: Friday, November 25, 2022 11:42
> >>>> To: dev <de...@camel.apache.org>
> >>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>
> >>>> Hi
> >>>>
> >>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >> affect
> >>>> Camel 3.
> >>>>
> >>>> Summary
> >>>>
> >>>> =======
> >>>>
> >>>> The overall scope is that the leap from Camel 3 to 4 is a lot less
> than
> >>>> going from Camel 2 to 3.
> >>>>
> >>>> And that we have a timebox approach where we aim for a 6 month period
> >> of
> >>>> work.
> >>>>
> >>>> The need for Camel v4 is mainly driven by Java open source projects
> >>>> migrating to jakarta APIs,
> >>>>
> >>>> and to keep up with popular runtimes a la Spring Boot and Quarkus, and
> >> to
> >>>> jump to the next major Java version.
> >>>>
> >>>> Goals
> >>>>
> >>>> =====
> >>>>
> >>>> a) Primary Goals
> >>>>
> >>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>
> >>>> 2) Java 17 as base line
> >>>>
> >>>> 3) Spring Framework 6
> >>>>
> >>>> 4) Spring Boot 3
> >>>>
> >>>> 5) Quarkus 3
> >>>>
> >>>> b) Release Goals
> >>>>
> >>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>
> >>>> This means that Camel components that are not ready (yet) will be
> >>>> dropped in a release until they are ready.
> >>>>
> >>>> 7) Release core + spring boot together
> >>>>
> >>>> 8) Release camel-karaf independently (like we do for other Camel
> >> projects)
> >>>> c) Major Goals
> >>>>
> >>>> 9) Support Java 17 features such as records, multiline strings, and
> >> what
> >>>> else
> >>>>
> >>>> 10) EIP model without JAXB dependency
> >>>>
> >>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>
> >>>> 12) Deprecate message.getIn()
> >>>>
> >>>> use getMessage() instead
> >>>>
> >>>> 13) Deprecate camel-cdi
> >>>>
> >>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
> >> modern
> >>>> app development)
> >>>>
> >>>> d) Minor Goals
> >>>>
> >>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>
> >>>> 16) Remove JUnit 4 support
> >>>>
> >>>>
> >>>> Timeline
> >>>>
> >>>> =======
> >>>>
> >>>> The timelines are ESTIMATES and the number of releases can vary
> >> depending
> >>>> on need and how far we are in the process
> >>>>
> >>>> Feb 2023: Camel 4.0 milestone 1
> >>>>
> >>>> Mar 2023: Camel 4.0 milestone 2
> >>>>
> >>>> Apr 2023: Camel 4.0 RC1
> >>>>
> >>>> May 2023: Camel 4.0
> >>>>
> >>>> Aug 2023: Camel 4.1 LTS
> >>>>
> >>>> Oct 2023: Camel 4.2
> >>>>
> >>>> Dec 2023: Camel 4.3 LTS
> >>>>
> >>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
> >> release,
> >>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>
> >>>> For Camel 3 then we slow down in releases and provide 2 LTS releases
> >> per
> >>>> year.
> >>>>
> >>>> For example a scheduled could look as follows:
> >>>>
> >>>> Dec 2022: Camel 3.20 LTS
> >>>>
> >>>> Jun 2023: Camel 3.21 LTS
> >>>>
> >>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
> >> 2024)
> >>>> ???
> >>>>
> >>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
> >> 2025)
> >>>> ????
> >>>>
> >>>> Each Camel 3 LTS release will likely also contain less new features
> and
> >>>> improvements as previously, as our focus and work shifts to Camel v4
> >>>> instead.
> >>>>
> >>>> As a recipient of an email from Talend, your contact personal data
> >> will be
> >>>> on our systems. Please see our privacy notice. <
> >>>> https://www.talend.com/privacy/>
> >>>>
> >>>>
> >>>>
> >
> --
> --
> François
>
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by fpapon <fp...@apache.org>.
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é <jb...@nanthrax.net>
> wrote:
>
>> Hi guys,
>>
>> I understand that Karaf/OSGi is not in the Camel community target
>> anymore, and it makes sense.
>> I proposed a time ago to refactor the approach of Camel components for
>> Karaf, using special packaging (embedded the deps as private to avoid
>> to have bunch of SMX bundles deps), etc.
>>
>> Even at Karaf, there are discussions about the next step in the
>> project decoupled from OSGi (see Minho).
>>
>> I would split the discussion in two parts:
>> - In terms of the roadmap/Camel future, I don't think it's worth it
>> for Camel community to maintain OSGi/Karaf support anymore. It's
>> always possible to wrap Camel routes in an uber jar and deploy in
>> Karaf.
>> - In terms of community/maintenance, I think camel-karaf could be part
>> of the Karaf community. We had a similar discussion about jclouds: the
>> jclouds community didn't want to maintain jclouds-karaf anymore (for
>> the same reasons as the Camel community). The jclouds community asked
>> the karaf community if they were interested in maintaining and
>> managing jclouds-karaf. So we can do the same for camel-karaf: the
>> karaf community can take the lead there and maintain it.
>>
>> Thoughts ?
>>
>>
> Yes i Agree on this JB.
>
> - Move camel-karaf to Apache Karaf as a new karaf-camel sub-project, and
> let the community and committers in that project take over maintaining and
> releasing this.
> - For Camel v4 onwards then camel-karaf will no longer be part of Apache
> Camel.
> - Karaf Camel is released under a new GAV - org.apache.karaf.camel, and no
> longer org.apache.camel.karaf.
> - Camel v4 core and component JARs will no longer generate OSGi MANIFEST.MF
> as Karaf Camel will be responsible for this (if even needed); such as JB
> talks about a new way of packing and running things in Karaf.
> - For Camel v3 we keep as-is and maintain and release camel-karaf until
> Camel 3 is EOL
>
>
>
>
>> Regards
>> JB
>>
>> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino <an...@gmail.com>
>> wrote:
>>> Hello
>>>
>>> I'll come back for other questions. Let me just say that camel-karaf is
>> too
>>> hard to maintain today. If it won't be released because of misalignments,
>>> it should be aligned by some volunteers or community member and released
>>> later. Active contributors are not really focused on Karaf runtime and we
>>> cannot do everything. This doesn't mean we won't release camel Karaf
>>> anymore. It only means it could be released later on. Even after the core
>>> camel and SB part have been released.
>>>
>>> In more than one situation aligning OSGi stuff have been really hard.
>> Less
>>> and less community members are helping on the Karaf side and releasing
>>> sometimes have been slow down by these troubles. Also OSGi have been drop
>>> in a lot of 3rd party libraries.
>>>
>>> So I'm +1 with this approach.
>>>
>>> I'll continue the discussion in the next days for the other points.
>>>
>>> Cheers
>>>
>>>
>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>> scritto:
>>>> Hi Claus,
>>>>
>>>> That sounds like a good plan, here are the first questions that I have
>> in
>>>> mind:
>>>>
>>>> * Why do we need to keep on releasing new LTS versions of Camel 3?
>>>> * Why not simply consider 3.20 as the last LTS version of Camel 3
>> and
>>>> only maintain it?
>>>> * What kind of features/improvements do you want to add to Camel 3
>>>> after releasing 3.20?
>>>> * If camel-karaf is released independently, when will it be
>> released?
>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>> *
>>>>
>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
>> LTS
>>>> versions to support at the same time, don't you think that it is too
>> many?
>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>> version
>>>> policy. Could you please remind me why we decided to have this policy
>> (2
>>>> LTS versions per year supported for one year)?
>>>>
>>>> I would personally prefer to have:
>>>>
>>>> * only one LTS version per year (or 2 if we keep on releasing LTS
>>>> versions of Camel 3) but supported for at least 2 years instead of one
>>>> otherwise Camel users are less inclined to migrate to the latest LTS
>>>> version because 1 year of support doesn't really worth the migration
>>>> effort, especially for big projects where the migration takes several
>>>> months.
>>>> * only propose milestone versions or equivalent between 2 LTS
>> versions
>>>> for early adopters to add more clarity on which versions are LTS.
>> Indeed,
>>>> for example, the next LTS version will be 3.20 while we could expect
>> 3.22
>>>> to be the next one after 3.14 and 3.18. With this logic, instead of
>>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
>> would
>>>> then be obvious to the Camel users that only 3.19 is an LTS version as
>> all
>>>> final versions would then be LTS versions.
>>>>
>>>> What do you think of it?
>>>>
>>>> Regards,
>>>> Nicolas
>>>> ________________________________
>>>> From: Claus Ibsen <cl...@gmail.com>
>>>> Sent: Friday, November 25, 2022 11:42
>>>> To: dev <de...@camel.apache.org>
>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>
>>>> Hi
>>>>
>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>> affect
>>>> Camel 3.
>>>>
>>>> Summary
>>>>
>>>> =======
>>>>
>>>> The overall scope is that the leap from Camel 3 to 4 is a lot less than
>>>> going from Camel 2 to 3.
>>>>
>>>> And that we have a timebox approach where we aim for a 6 month period
>> of
>>>> work.
>>>>
>>>> The need for Camel v4 is mainly driven by Java open source projects
>>>> migrating to jakarta APIs,
>>>>
>>>> and to keep up with popular runtimes a la Spring Boot and Quarkus, and
>> to
>>>> jump to the next major Java version.
>>>>
>>>> Goals
>>>>
>>>> =====
>>>>
>>>> a) Primary Goals
>>>>
>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>
>>>> 2) Java 17 as base line
>>>>
>>>> 3) Spring Framework 6
>>>>
>>>> 4) Spring Boot 3
>>>>
>>>> 5) Quarkus 3
>>>>
>>>> b) Release Goals
>>>>
>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>
>>>> This means that Camel components that are not ready (yet) will be
>>>> dropped in a release until they are ready.
>>>>
>>>> 7) Release core + spring boot together
>>>>
>>>> 8) Release camel-karaf independently (like we do for other Camel
>> projects)
>>>> c) Major Goals
>>>>
>>>> 9) Support Java 17 features such as records, multiline strings, and
>> what
>>>> else
>>>>
>>>> 10) EIP model without JAXB dependency
>>>>
>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>
>>>> 12) Deprecate message.getIn()
>>>>
>>>> use getMessage() instead
>>>>
>>>> 13) Deprecate camel-cdi
>>>>
>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
>> modern
>>>> app development)
>>>>
>>>> d) Minor Goals
>>>>
>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>
>>>> 16) Remove JUnit 4 support
>>>>
>>>>
>>>> Timeline
>>>>
>>>> =======
>>>>
>>>> The timelines are ESTIMATES and the number of releases can vary
>> depending
>>>> on need and how far we are in the process
>>>>
>>>> Feb 2023: Camel 4.0 milestone 1
>>>>
>>>> Mar 2023: Camel 4.0 milestone 2
>>>>
>>>> Apr 2023: Camel 4.0 RC1
>>>>
>>>> May 2023: Camel 4.0
>>>>
>>>> Aug 2023: Camel 4.1 LTS
>>>>
>>>> Oct 2023: Camel 4.2
>>>>
>>>> Dec 2023: Camel 4.3 LTS
>>>>
>>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
>> release,
>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>
>>>> For Camel 3 then we slow down in releases and provide 2 LTS releases
>> per
>>>> year.
>>>>
>>>> For example a scheduled could look as follows:
>>>>
>>>> Dec 2022: Camel 3.20 LTS
>>>>
>>>> Jun 2023: Camel 3.21 LTS
>>>>
>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
>> 2024)
>>>> ???
>>>>
>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
>> 2025)
>>>> ????
>>>>
>>>> Each Camel 3 LTS release will likely also contain less new features and
>>>> improvements as previously, as our focus and work shifts to Camel v4
>>>> instead.
>>>>
>>>> As a recipient of an email from Talend, your contact personal data
>> will be
>>>> on our systems. Please see our privacy notice. <
>>>> https://www.talend.com/privacy/>
>>>>
>>>>
>>>>
>
--
--
François
Re: Camel 4 roadmap and affect on Camel 3
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi guys,
>
> I understand that Karaf/OSGi is not in the Camel community target
> anymore, and it makes sense.
> I proposed a time ago to refactor the approach of Camel components for
> Karaf, using special packaging (embedded the deps as private to avoid
> to have bunch of SMX bundles deps), etc.
>
> Even at Karaf, there are discussions about the next step in the
> project decoupled from OSGi (see Minho).
>
> I would split the discussion in two parts:
> - In terms of the roadmap/Camel future, I don't think it's worth it
> for Camel community to maintain OSGi/Karaf support anymore. It's
> always possible to wrap Camel routes in an uber jar and deploy in
> Karaf.
> - In terms of community/maintenance, I think camel-karaf could be part
> of the Karaf community. We had a similar discussion about jclouds: the
> jclouds community didn't want to maintain jclouds-karaf anymore (for
> the same reasons as the Camel community). The jclouds community asked
> the karaf community if they were interested in maintaining and
> managing jclouds-karaf. So we can do the same for camel-karaf: the
> karaf community can take the lead there and maintain it.
>
> Thoughts ?
>
>
Yes i Agree on this JB.
- Move camel-karaf to Apache Karaf as a new karaf-camel sub-project, and
let the community and committers in that project take over maintaining and
releasing this.
- For Camel v4 onwards then camel-karaf will no longer be part of Apache
Camel.
- Karaf Camel is released under a new GAV - org.apache.karaf.camel, and no
longer org.apache.camel.karaf.
- Camel v4 core and component JARs will no longer generate OSGi MANIFEST.MF
as Karaf Camel will be responsible for this (if even needed); such as JB
talks about a new way of packing and running things in Karaf.
- For Camel v3 we keep as-is and maintain and release camel-karaf until
Camel 3 is EOL
> Regards
> JB
>
> On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino <an...@gmail.com>
> wrote:
> >
> > Hello
> >
> > I'll come back for other questions. Let me just say that camel-karaf is
> too
> > hard to maintain today. If it won't be released because of misalignments,
> > it should be aligned by some volunteers or community member and released
> > later. Active contributors are not really focused on Karaf runtime and we
> > cannot do everything. This doesn't mean we won't release camel Karaf
> > anymore. It only means it could be released later on. Even after the core
> > camel and SB part have been released.
> >
> > In more than one situation aligning OSGi stuff have been really hard.
> Less
> > and less community members are helping on the Karaf side and releasing
> > sometimes have been slow down by these troubles. Also OSGi have been drop
> > in a lot of 3rd party libraries.
> >
> > So I'm +1 with this approach.
> >
> > I'll continue the discussion in the next days for the other points.
> >
> > Cheers
> >
> >
> > Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> scritto:
> >
> > > Hi Claus,
> > >
> > > That sounds like a good plan, here are the first questions that I have
> in
> > > mind:
> > >
> > > * Why do we need to keep on releasing new LTS versions of Camel 3?
> > > * Why not simply consider 3.20 as the last LTS version of Camel 3
> and
> > > only maintain it?
> > > * What kind of features/improvements do you want to add to Camel 3
> > > after releasing 3.20?
> > > * If camel-karaf is released independently, when will it be
> released?
> > > My fear is that it will be desynchronized with Camel very quickly.
> > > *
> > >
> > > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
> LTS
> > > versions to support at the same time, don't you think that it is too
> many?
> > >
> > > I'm wondering if it is not a good opportunity to rethink our LTS
> version
> > > policy. Could you please remind me why we decided to have this policy
> (2
> > > LTS versions per year supported for one year)?
> > >
> > > I would personally prefer to have:
> > >
> > > * only one LTS version per year (or 2 if we keep on releasing LTS
> > > versions of Camel 3) but supported for at least 2 years instead of one
> > > otherwise Camel users are less inclined to migrate to the latest LTS
> > > version because 1 year of support doesn't really worth the migration
> > > effort, especially for big projects where the migration takes several
> > > months.
> > > * only propose milestone versions or equivalent between 2 LTS
> versions
> > > for early adopters to add more clarity on which versions are LTS.
> Indeed,
> > > for example, the next LTS version will be 3.20 while we could expect
> 3.22
> > > to be the next one after 3.14 and 3.18. With this logic, instead of
> > > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
> would
> > > then be obvious to the Camel users that only 3.19 is an LTS version as
> all
> > > final versions would then be LTS versions.
> > >
> > > What do you think of it?
> > >
> > > Regards,
> > > Nicolas
> > > ________________________________
> > > From: Claus Ibsen <cl...@gmail.com>
> > > Sent: Friday, November 25, 2022 11:42
> > > To: dev <de...@camel.apache.org>
> > > Subject: Camel 4 roadmap and affect on Camel 3
> > >
> > > Hi
> > >
> > > This is a proposal for a plan for Apache Camel 4 and how this can
> affect
> > > Camel 3.
> > >
> > > Summary
> > >
> > > =======
> > >
> > > The overall scope is that the leap from Camel 3 to 4 is a lot less than
> > > going from Camel 2 to 3.
> > >
> > > And that we have a timebox approach where we aim for a 6 month period
> of
> > > work.
> > >
> > > The need for Camel v4 is mainly driven by Java open source projects
> > > migrating to jakarta APIs,
> > >
> > > and to keep up with popular runtimes a la Spring Boot and Quarkus, and
> to
> > > jump to the next major Java version.
> > >
> > > Goals
> > >
> > > =====
> > >
> > > a) Primary Goals
> > >
> > > 1) Migrate from javax -> jakarta (JEE 10)
> > >
> > > 2) Java 17 as base line
> > >
> > > 3) Spring Framework 6
> > >
> > > 4) Spring Boot 3
> > >
> > > 5) Quarkus 3
> > >
> > > b) Release Goals
> > >
> > > 6) Release only what is ready (JEE10 / Java17 etc)
> > >
> > > This means that Camel components that are not ready (yet) will be
> > > dropped in a release until they are ready.
> > >
> > > 7) Release core + spring boot together
> > >
> > > 8) Release camel-karaf independently (like we do for other Camel
> projects)
> > >
> > > c) Major Goals
> > >
> > > 9) Support Java 17 features such as records, multiline strings, and
> what
> > > else
> > >
> > > 10) EIP model without JAXB dependency
> > >
> > > 11) Endpoint URI parsing (do not use java.net.URI)
> > >
> > > 12) Deprecate message.getIn()
> > >
> > > use getMessage() instead
> > >
> > > 13) Deprecate camel-cdi
> > >
> > > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
> modern
> > > app development)
> > >
> > > d) Minor Goals
> > >
> > > 15) Remove MEP InOptionalOut (not in use)
> > >
> > > 16) Remove JUnit 4 support
> > >
> > >
> > > Timeline
> > >
> > > =======
> > >
> > > The timelines are ESTIMATES and the number of releases can vary
> depending
> > > on need and how far we are in the process
> > >
> > > Feb 2023: Camel 4.0 milestone 1
> > >
> > > Mar 2023: Camel 4.0 milestone 2
> > >
> > > Apr 2023: Camel 4.0 RC1
> > >
> > > May 2023: Camel 4.0
> > >
> > > Aug 2023: Camel 4.1 LTS
> > >
> > > Oct 2023: Camel 4.2
> > >
> > > Dec 2023: Camel 4.3 LTS
> > >
> > > The plan is to start working on Camel 4 after the next Camel 3 LTS
> release,
> > > e.g. 3.20 which is planned for next month (December 2022).
> > >
> > > For Camel 3 then we slow down in releases and provide 2 LTS releases
> per
> > > year.
> > >
> > > For example a scheduled could look as follows:
> > >
> > > Dec 2022: Camel 3.20 LTS
> > >
> > > Jun 2023: Camel 3.21 LTS
> > >
> > > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
> 2024)
> > > ???
> > >
> > > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
> 2025)
> > > ????
> > >
> > > Each Camel 3 LTS release will likely also contain less new features and
> > > improvements as previously, as our focus and work shifts to Camel v4
> > > instead.
> > >
> > > As a recipient of an email from Talend, your contact personal data
> will be
> > > on our systems. Please see our privacy notice. <
> > > https://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
Posted by Nicolas Filotto <nf...@talend.com>.
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? <jb...@nanthrax.net>
Sent: Monday, November 28, 2022 10:39
To: dev@camel.apache.org <de...@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 <an...@gmail.com> wrote:
>
> Hello
>
> I'll come back for other questions. Let me just say that camel-karaf is too
> hard to maintain today. If it won't be released because of misalignments,
> it should be aligned by some volunteers or community member and released
> later. Active contributors are not really focused on Karaf runtime and we
> cannot do everything. This doesn't mean we won't release camel Karaf
> anymore. It only means it could be released later on. Even after the core
> camel and SB part have been released.
>
> In more than one situation aligning OSGi stuff have been really hard. Less
> and less community members are helping on the Karaf side and releasing
> sometimes have been slow down by these troubles. Also OSGi have been drop
> in a lot of 3rd party libraries.
>
> So I'm +1 with this approach.
>
> I'll continue the discussion in the next days for the other points.
>
> Cheers
>
>
> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha scritto:
>
> > Hi Claus,
> >
> > That sounds like a good plan, here are the first questions that I have in
> > mind:
> >
> > * Why do we need to keep on releasing new LTS versions of Camel 3?
> > * Why not simply consider 3.20 as the last LTS version of Camel 3 and
> > only maintain it?
> > * What kind of features/improvements do you want to add to Camel 3
> > after releasing 3.20?
> > * If camel-karaf is released independently, when will it be released?
> > My fear is that it will be desynchronized with Camel very quickly.
> > *
> >
> > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4 LTS
> > versions to support at the same time, don't you think that it is too many?
> >
> > I'm wondering if it is not a good opportunity to rethink our LTS version
> > policy. Could you please remind me why we decided to have this policy (2
> > LTS versions per year supported for one year)?
> >
> > I would personally prefer to have:
> >
> > * only one LTS version per year (or 2 if we keep on releasing LTS
> > versions of Camel 3) but supported for at least 2 years instead of one
> > otherwise Camel users are less inclined to migrate to the latest LTS
> > version because 1 year of support doesn't really worth the migration
> > effort, especially for big projects where the migration takes several
> > months.
> > * only propose milestone versions or equivalent between 2 LTS versions
> > for early adopters to add more clarity on which versions are LTS. Indeed,
> > for example, the next LTS version will be 3.20 while we could expect 3.22
> > to be the next one after 3.14 and 3.18. With this logic, instead of
> > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it would
> > then be obvious to the Camel users that only 3.19 is an LTS version as all
> > final versions would then be LTS versions.
> >
> > What do you think of it?
> >
> > Regards,
> > Nicolas
> > ________________________________
> > From: Claus Ibsen <cl...@gmail.com>
> > Sent: Friday, November 25, 2022 11:42
> > To: dev <de...@camel.apache.org>
> > Subject: Camel 4 roadmap and affect on Camel 3
> >
> > Hi
> >
> > This is a proposal for a plan for Apache Camel 4 and how this can affect
> > Camel 3.
> >
> > Summary
> >
> > =======
> >
> > The overall scope is that the leap from Camel 3 to 4 is a lot less than
> > going from Camel 2 to 3.
> >
> > And that we have a timebox approach where we aim for a 6 month period of
> > work.
> >
> > The need for Camel v4 is mainly driven by Java open source projects
> > migrating to jakarta APIs,
> >
> > and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
> > jump to the next major Java version.
> >
> > Goals
> >
> > =====
> >
> > a) Primary Goals
> >
> > 1) Migrate from javax -> jakarta (JEE 10)
> >
> > 2) Java 17 as base line
> >
> > 3) Spring Framework 6
> >
> > 4) Spring Boot 3
> >
> > 5) Quarkus 3
> >
> > b) Release Goals
> >
> > 6) Release only what is ready (JEE10 / Java17 etc)
> >
> > This means that Camel components that are not ready (yet) will be
> > dropped in a release until they are ready.
> >
> > 7) Release core + spring boot together
> >
> > 8) Release camel-karaf independently (like we do for other Camel projects)
> >
> > c) Major Goals
> >
> > 9) Support Java 17 features such as records, multiline strings, and what
> > else
> >
> > 10) EIP model without JAXB dependency
> >
> > 11) Endpoint URI parsing (do not use java.net.URI)
> >
> > 12) Deprecate message.getIn()
> >
> > use getMessage() instead
> >
> > 13) Deprecate camel-cdi
> >
> > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
> > app development)
> >
> > d) Minor Goals
> >
> > 15) Remove MEP InOptionalOut (not in use)
> >
> > 16) Remove JUnit 4 support
> >
> >
> > Timeline
> >
> > =======
> >
> > The timelines are ESTIMATES and the number of releases can vary depending
> > on need and how far we are in the process
> >
> > Feb 2023: Camel 4.0 milestone 1
> >
> > Mar 2023: Camel 4.0 milestone 2
> >
> > Apr 2023: Camel 4.0 RC1
> >
> > May 2023: Camel 4.0
> >
> > Aug 2023: Camel 4.1 LTS
> >
> > Oct 2023: Camel 4.2
> >
> > Dec 2023: Camel 4.3 LTS
> >
> > The plan is to start working on Camel 4 after the next Camel 3 LTS release,
> > e.g. 3.20 which is planned for next month (December 2022).
> >
> > For Camel 3 then we slow down in releases and provide 2 LTS releases per
> > year.
> >
> > For example a scheduled could look as follows:
> >
> > Dec 2022: Camel 3.20 LTS
> >
> > Jun 2023: Camel 3.21 LTS
> >
> > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
> > ???
> >
> > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
> > ????
> >
> > Each Camel 3 LTS release will likely also contain less new features and
> > improvements as previously, as our focus and work shifts to Camel v4
> > instead.
> >
> > As a recipient of an email from Talend, your contact personal data will be
> > on our systems. Please see our privacy notice. <
> > https://www.talend.com/privacy/>
> >
> >
> >
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
Posted by Andrea Cosentino <an...@gmail.com>.
I'm fine with reworking PR 173, we could merge after 3.20.0 release.
Thanks for this.
Il giorno lun 28 nov 2022 alle ore 15:05 Jean-Baptiste Onofré <
jb@nanthrax.net> ha scritto:
> Hi,
>
> I agree with François. I'm still volunteering to help there, but we
> need at least some "help" from the other members of the Camel
> community.
>
> I think that reworking camel-karaf would give us more flexibility and
> easier to maintain.
>
> I can rework on PR #173 (rebasing and improving), including the
> proposal on components.
>
> Thoughts ?
>
> Regards
> JB
>
> On Mon, Nov 28, 2022 at 2:18 PM fpapon <fp...@apache.org> wrote:
> >
> > Hi,
> >
> > I think camel-karaf make sense to continue to exist and it could be nice
> > to be more simple to manage.
> >
> > There is a PR thanks to JB (
> https://github.com/apache/camel-karaf/pull/173)
> >
> > May be it could be nice if camel-karaf has it's own version and release
> > flow.
> >
> > Mainly we have :
> >
> > - camel-core-osgi: for the osgi integration of camel
> >
> > - camel-karaf-command: karaf custom command for camel integration
> >
> > - camel-karaf-features: big part of lib dependencies deployment in osgi
> env
> >
> > - camel-components-osgi: list of camel osgi component
> >
> > If there is no breaker between 2 versions of Camel we don't need to
> > update these modules and can be manage with version range so user can
> > choose which version of Camel he want to use with the same camel-karaf
> > version.
> >
> > I certainly forgot some points :)
> >
> > regards,
> >
> > François
> >
> >
> > On 28/11/2022 11:21, Andrea Cosentino wrote:
> > > It's just my point of view. There are a lot of active contributors on
> Camel
> > > and we need to gather more opinions as possible.
> > >
> > > Let's see.
> > >
> > > Il giorno lun 28 nov 2022 alle ore 11:18 Jean-Baptiste Onofré <
> > > jb@nanthrax.net> ha scritto:
> > >
> > >> Hi Andrea,
> > >>
> > >> Fair comment. Then, if your proposal is just to retire camel-karaf, go
> > >> for it and start a vote. I agree with you and I will support this.
> > >> Maybe, we can just propose to maintain as best effort, but without
> > >> strong commitment in terms of releases, etc (like we do on
> > >> camel-extra).
> > >>
> > >> Regards
> > >> JB
> > >>
> > >> On Mon, Nov 28, 2022 at 11:04 AM Andrea Cosentino <an...@gmail.com>
> > >> wrote:
> > >>> 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é <
> > >>> jb@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 <ancosen@gmail.com
> >
> > >>>> wrote:
> > >>>>> Hello
> > >>>>>
> > >>>>> I'll come back for other questions. Let me just say that
> camel-karaf
> > >> is
> > >>>> too
> > >>>>> hard to maintain today. If it won't be released because of
> > >> misalignments,
> > >>>>> it should be aligned by some volunteers or community member and
> > >> released
> > >>>>> later. Active contributors are not really focused on Karaf runtime
> > >> and we
> > >>>>> cannot do everything. This doesn't mean we won't release camel
> Karaf
> > >>>>> anymore. It only means it could be released later on. Even after
> the
> > >> core
> > >>>>> camel and SB part have been released.
> > >>>>>
> > >>>>> In more than one situation aligning OSGi stuff have been really
> hard.
> > >>>> Less
> > >>>>> and less community members are helping on the Karaf side and
> > >> releasing
> > >>>>> sometimes have been slow down by these troubles. Also OSGi have
> been
> > >> drop
> > >>>>> in a lot of 3rd party libraries.
> > >>>>>
> > >>>>> So I'm +1 with this approach.
> > >>>>>
> > >>>>> I'll continue the discussion in the next days for the other points.
> > >>>>>
> > >>>>> Cheers
> > >>>>>
> > >>>>>
> > >>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> > >>>> scritto:
> > >>>>>> Hi Claus,
> > >>>>>>
> > >>>>>> That sounds like a good plan, here are the first questions that I
> > >> have
> > >>>> in
> > >>>>>> mind:
> > >>>>>>
> > >>>>>> * Why do we need to keep on releasing new LTS versions of
> > >> Camel 3?
> > >>>>>> * Why not simply consider 3.20 as the last LTS version of
> > >> Camel 3
> > >>>> and
> > >>>>>> only maintain it?
> > >>>>>> * What kind of features/improvements do you want to add to
> > >> Camel 3
> > >>>>>> after releasing 3.20?
> > >>>>>> * If camel-karaf is released independently, when will it be
> > >>>> released?
> > >>>>>> My fear is that it will be desynchronized with Camel very quickly.
> > >>>>>> *
> > >>>>>>
> > >>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean
> > >> 4
> > >>>> LTS
> > >>>>>> versions to support at the same time, don't you think that it is
> > >> too
> > >>>> many?
> > >>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> > >>>> version
> > >>>>>> policy. Could you please remind me why we decided to have this
> > >> policy
> > >>>> (2
> > >>>>>> LTS versions per year supported for one year)?
> > >>>>>>
> > >>>>>> I would personally prefer to have:
> > >>>>>>
> > >>>>>> * only one LTS version per year (or 2 if we keep on releasing
> > >> LTS
> > >>>>>> versions of Camel 3) but supported for at least 2 years instead of
> > >> one
> > >>>>>> otherwise Camel users are less inclined to migrate to the latest
> > >> LTS
> > >>>>>> version because 1 year of support doesn't really worth the
> > >> migration
> > >>>>>> effort, especially for big projects where the migration takes
> > >> several
> > >>>>>> months.
> > >>>>>> * only propose milestone versions or equivalent between 2 LTS
> > >>>> versions
> > >>>>>> for early adopters to add more clarity on which versions are LTS.
> > >>>> Indeed,
> > >>>>>> for example, the next LTS version will be 3.20 while we could
> > >> expect
> > >>>> 3.22
> > >>>>>> to be the next one after 3.14 and 3.18. With this logic, instead
> of
> > >>>>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19,
> > >> it
> > >>>> would
> > >>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> > >> version as
> > >>>> all
> > >>>>>> final versions would then be LTS versions.
> > >>>>>>
> > >>>>>> What do you think of it?
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> Nicolas
> > >>>>>> ________________________________
> > >>>>>> From: Claus Ibsen <cl...@gmail.com>
> > >>>>>> Sent: Friday, November 25, 2022 11:42
> > >>>>>> To: dev <de...@camel.apache.org>
> > >>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> > >>>>>>
> > >>>>>> Hi
> > >>>>>>
> > >>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> > >>>> affect
> > >>>>>> Camel 3.
> > >>>>>>
> > >>>>>> Summary
> > >>>>>>
> > >>>>>> =======
> > >>>>>>
> > >>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot less
> > >> than
> > >>>>>> going from Camel 2 to 3.
> > >>>>>>
> > >>>>>> And that we have a timebox approach where we aim for a 6 month
> > >> period
> > >>>> of
> > >>>>>> work.
> > >>>>>>
> > >>>>>> The need for Camel v4 is mainly driven by Java open source
> projects
> > >>>>>> migrating to jakarta APIs,
> > >>>>>>
> > >>>>>> and to keep up with popular runtimes a la Spring Boot and Quarkus,
> > >> and
> > >>>> to
> > >>>>>> jump to the next major Java version.
> > >>>>>>
> > >>>>>> Goals
> > >>>>>>
> > >>>>>> =====
> > >>>>>>
> > >>>>>> a) Primary Goals
> > >>>>>>
> > >>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> > >>>>>>
> > >>>>>> 2) Java 17 as base line
> > >>>>>>
> > >>>>>> 3) Spring Framework 6
> > >>>>>>
> > >>>>>> 4) Spring Boot 3
> > >>>>>>
> > >>>>>> 5) Quarkus 3
> > >>>>>>
> > >>>>>> b) Release Goals
> > >>>>>>
> > >>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> > >>>>>>
> > >>>>>> This means that Camel components that are not ready (yet)
> will
> > >> be
> > >>>>>> dropped in a release until they are ready.
> > >>>>>>
> > >>>>>> 7) Release core + spring boot together
> > >>>>>>
> > >>>>>> 8) Release camel-karaf independently (like we do for other Camel
> > >>>> projects)
> > >>>>>> c) Major Goals
> > >>>>>>
> > >>>>>> 9) Support Java 17 features such as records, multiline strings,
> and
> > >>>> what
> > >>>>>> else
> > >>>>>>
> > >>>>>> 10) EIP model without JAXB dependency
> > >>>>>>
> > >>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> > >>>>>>
> > >>>>>> 12) Deprecate message.getIn()
> > >>>>>>
> > >>>>>> use getMessage() instead
> > >>>>>>
> > >>>>>> 13) Deprecate camel-cdi
> > >>>>>>
> > >>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> > >> fit
> > >>>> modern
> > >>>>>> app development)
> > >>>>>>
> > >>>>>> d) Minor Goals
> > >>>>>>
> > >>>>>> 15) Remove MEP InOptionalOut (not in use)
> > >>>>>>
> > >>>>>> 16) Remove JUnit 4 support
> > >>>>>>
> > >>>>>>
> > >>>>>> Timeline
> > >>>>>>
> > >>>>>> =======
> > >>>>>>
> > >>>>>> The timelines are ESTIMATES and the number of releases can vary
> > >>>> depending
> > >>>>>> on need and how far we are in the process
> > >>>>>>
> > >>>>>> Feb 2023: Camel 4.0 milestone 1
> > >>>>>>
> > >>>>>> Mar 2023: Camel 4.0 milestone 2
> > >>>>>>
> > >>>>>> Apr 2023: Camel 4.0 RC1
> > >>>>>>
> > >>>>>> May 2023: Camel 4.0
> > >>>>>>
> > >>>>>> Aug 2023: Camel 4.1 LTS
> > >>>>>>
> > >>>>>> Oct 2023: Camel 4.2
> > >>>>>>
> > >>>>>> Dec 2023: Camel 4.3 LTS
> > >>>>>>
> > >>>>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
> > >>>> release,
> > >>>>>> e.g. 3.20 which is planned for next month (December 2022).
> > >>>>>>
> > >>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> > >> releases
> > >>>> per
> > >>>>>> year.
> > >>>>>>
> > >>>>>> For example a scheduled could look as follows:
> > >>>>>>
> > >>>>>> Dec 2022: Camel 3.20 LTS
> > >>>>>>
> > >>>>>> Jun 2023: Camel 3.21 LTS
> > >>>>>>
> > >>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> > >> Dec
> > >>>> 2024)
> > >>>>>> ???
> > >>>>>>
> > >>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> > >> Dec
> > >>>> 2025)
> > >>>>>> ????
> > >>>>>>
> > >>>>>> Each Camel 3 LTS release will likely also contain less new
> > >> features and
> > >>>>>> improvements as previously, as our focus and work shifts to Camel
> > >> v4
> > >>>>>> instead.
> > >>>>>>
> > >>>>>> As a recipient of an email from Talend, your contact personal data
> > >>>> will be
> > >>>>>> on our systems. Please see our privacy notice. <
> > >>>>>> https://www.talend.com/privacy/>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > --
> > --
> > François
> >
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I agree with François. I'm still volunteering to help there, but we
need at least some "help" from the other members of the Camel
community.
I think that reworking camel-karaf would give us more flexibility and
easier to maintain.
I can rework on PR #173 (rebasing and improving), including the
proposal on components.
Thoughts ?
Regards
JB
On Mon, Nov 28, 2022 at 2:18 PM fpapon <fp...@apache.org> wrote:
>
> Hi,
>
> I think camel-karaf make sense to continue to exist and it could be nice
> to be more simple to manage.
>
> There is a PR thanks to JB (https://github.com/apache/camel-karaf/pull/173)
>
> May be it could be nice if camel-karaf has it's own version and release
> flow.
>
> Mainly we have :
>
> - camel-core-osgi: for the osgi integration of camel
>
> - camel-karaf-command: karaf custom command for camel integration
>
> - camel-karaf-features: big part of lib dependencies deployment in osgi env
>
> - camel-components-osgi: list of camel osgi component
>
> If there is no breaker between 2 versions of Camel we don't need to
> update these modules and can be manage with version range so user can
> choose which version of Camel he want to use with the same camel-karaf
> version.
>
> I certainly forgot some points :)
>
> regards,
>
> François
>
>
> On 28/11/2022 11:21, Andrea Cosentino wrote:
> > It's just my point of view. There are a lot of active contributors on Camel
> > and we need to gather more opinions as possible.
> >
> > Let's see.
> >
> > Il giorno lun 28 nov 2022 alle ore 11:18 Jean-Baptiste Onofré <
> > jb@nanthrax.net> ha scritto:
> >
> >> Hi Andrea,
> >>
> >> Fair comment. Then, if your proposal is just to retire camel-karaf, go
> >> for it and start a vote. I agree with you and I will support this.
> >> Maybe, we can just propose to maintain as best effort, but without
> >> strong commitment in terms of releases, etc (like we do on
> >> camel-extra).
> >>
> >> Regards
> >> JB
> >>
> >> On Mon, Nov 28, 2022 at 11:04 AM Andrea Cosentino <an...@gmail.com>
> >> wrote:
> >>> 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é <
> >>> jb@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 <an...@gmail.com>
> >>>> wrote:
> >>>>> Hello
> >>>>>
> >>>>> I'll come back for other questions. Let me just say that camel-karaf
> >> is
> >>>> too
> >>>>> hard to maintain today. If it won't be released because of
> >> misalignments,
> >>>>> it should be aligned by some volunteers or community member and
> >> released
> >>>>> later. Active contributors are not really focused on Karaf runtime
> >> and we
> >>>>> cannot do everything. This doesn't mean we won't release camel Karaf
> >>>>> anymore. It only means it could be released later on. Even after the
> >> core
> >>>>> camel and SB part have been released.
> >>>>>
> >>>>> In more than one situation aligning OSGi stuff have been really hard.
> >>>> Less
> >>>>> and less community members are helping on the Karaf side and
> >> releasing
> >>>>> sometimes have been slow down by these troubles. Also OSGi have been
> >> drop
> >>>>> in a lot of 3rd party libraries.
> >>>>>
> >>>>> So I'm +1 with this approach.
> >>>>>
> >>>>> I'll continue the discussion in the next days for the other points.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> >>>> scritto:
> >>>>>> Hi Claus,
> >>>>>>
> >>>>>> That sounds like a good plan, here are the first questions that I
> >> have
> >>>> in
> >>>>>> mind:
> >>>>>>
> >>>>>> * Why do we need to keep on releasing new LTS versions of
> >> Camel 3?
> >>>>>> * Why not simply consider 3.20 as the last LTS version of
> >> Camel 3
> >>>> and
> >>>>>> only maintain it?
> >>>>>> * What kind of features/improvements do you want to add to
> >> Camel 3
> >>>>>> after releasing 3.20?
> >>>>>> * If camel-karaf is released independently, when will it be
> >>>> released?
> >>>>>> My fear is that it will be desynchronized with Camel very quickly.
> >>>>>> *
> >>>>>>
> >>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean
> >> 4
> >>>> LTS
> >>>>>> versions to support at the same time, don't you think that it is
> >> too
> >>>> many?
> >>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
> >>>> version
> >>>>>> policy. Could you please remind me why we decided to have this
> >> policy
> >>>> (2
> >>>>>> LTS versions per year supported for one year)?
> >>>>>>
> >>>>>> I would personally prefer to have:
> >>>>>>
> >>>>>> * only one LTS version per year (or 2 if we keep on releasing
> >> LTS
> >>>>>> versions of Camel 3) but supported for at least 2 years instead of
> >> one
> >>>>>> otherwise Camel users are less inclined to migrate to the latest
> >> LTS
> >>>>>> version because 1 year of support doesn't really worth the
> >> migration
> >>>>>> effort, especially for big projects where the migration takes
> >> several
> >>>>>> months.
> >>>>>> * only propose milestone versions or equivalent between 2 LTS
> >>>> versions
> >>>>>> for early adopters to add more clarity on which versions are LTS.
> >>>> Indeed,
> >>>>>> for example, the next LTS version will be 3.20 while we could
> >> expect
> >>>> 3.22
> >>>>>> to be the next one after 3.14 and 3.18. With this logic, instead of
> >>>>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19,
> >> it
> >>>> would
> >>>>>> then be obvious to the Camel users that only 3.19 is an LTS
> >> version as
> >>>> all
> >>>>>> final versions would then be LTS versions.
> >>>>>>
> >>>>>> What do you think of it?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Nicolas
> >>>>>> ________________________________
> >>>>>> From: Claus Ibsen <cl...@gmail.com>
> >>>>>> Sent: Friday, November 25, 2022 11:42
> >>>>>> To: dev <de...@camel.apache.org>
> >>>>>> Subject: Camel 4 roadmap and affect on Camel 3
> >>>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
> >>>> affect
> >>>>>> Camel 3.
> >>>>>>
> >>>>>> Summary
> >>>>>>
> >>>>>> =======
> >>>>>>
> >>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot less
> >> than
> >>>>>> going from Camel 2 to 3.
> >>>>>>
> >>>>>> And that we have a timebox approach where we aim for a 6 month
> >> period
> >>>> of
> >>>>>> work.
> >>>>>>
> >>>>>> The need for Camel v4 is mainly driven by Java open source projects
> >>>>>> migrating to jakarta APIs,
> >>>>>>
> >>>>>> and to keep up with popular runtimes a la Spring Boot and Quarkus,
> >> and
> >>>> to
> >>>>>> jump to the next major Java version.
> >>>>>>
> >>>>>> Goals
> >>>>>>
> >>>>>> =====
> >>>>>>
> >>>>>> a) Primary Goals
> >>>>>>
> >>>>>> 1) Migrate from javax -> jakarta (JEE 10)
> >>>>>>
> >>>>>> 2) Java 17 as base line
> >>>>>>
> >>>>>> 3) Spring Framework 6
> >>>>>>
> >>>>>> 4) Spring Boot 3
> >>>>>>
> >>>>>> 5) Quarkus 3
> >>>>>>
> >>>>>> b) Release Goals
> >>>>>>
> >>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
> >>>>>>
> >>>>>> This means that Camel components that are not ready (yet) will
> >> be
> >>>>>> dropped in a release until they are ready.
> >>>>>>
> >>>>>> 7) Release core + spring boot together
> >>>>>>
> >>>>>> 8) Release camel-karaf independently (like we do for other Camel
> >>>> projects)
> >>>>>> c) Major Goals
> >>>>>>
> >>>>>> 9) Support Java 17 features such as records, multiline strings, and
> >>>> what
> >>>>>> else
> >>>>>>
> >>>>>> 10) EIP model without JAXB dependency
> >>>>>>
> >>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
> >>>>>>
> >>>>>> 12) Deprecate message.getIn()
> >>>>>>
> >>>>>> use getMessage() instead
> >>>>>>
> >>>>>> 13) Deprecate camel-cdi
> >>>>>>
> >>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
> >> fit
> >>>> modern
> >>>>>> app development)
> >>>>>>
> >>>>>> d) Minor Goals
> >>>>>>
> >>>>>> 15) Remove MEP InOptionalOut (not in use)
> >>>>>>
> >>>>>> 16) Remove JUnit 4 support
> >>>>>>
> >>>>>>
> >>>>>> Timeline
> >>>>>>
> >>>>>> =======
> >>>>>>
> >>>>>> The timelines are ESTIMATES and the number of releases can vary
> >>>> depending
> >>>>>> on need and how far we are in the process
> >>>>>>
> >>>>>> Feb 2023: Camel 4.0 milestone 1
> >>>>>>
> >>>>>> Mar 2023: Camel 4.0 milestone 2
> >>>>>>
> >>>>>> Apr 2023: Camel 4.0 RC1
> >>>>>>
> >>>>>> May 2023: Camel 4.0
> >>>>>>
> >>>>>> Aug 2023: Camel 4.1 LTS
> >>>>>>
> >>>>>> Oct 2023: Camel 4.2
> >>>>>>
> >>>>>> Dec 2023: Camel 4.3 LTS
> >>>>>>
> >>>>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
> >>>> release,
> >>>>>> e.g. 3.20 which is planned for next month (December 2022).
> >>>>>>
> >>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
> >> releases
> >>>> per
> >>>>>> year.
> >>>>>>
> >>>>>> For example a scheduled could look as follows:
> >>>>>>
> >>>>>> Dec 2022: Camel 3.20 LTS
> >>>>>>
> >>>>>> Jun 2023: Camel 3.21 LTS
> >>>>>>
> >>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> >> Dec
> >>>> 2024)
> >>>>>> ???
> >>>>>>
> >>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> >> Dec
> >>>> 2025)
> >>>>>> ????
> >>>>>>
> >>>>>> Each Camel 3 LTS release will likely also contain less new
> >> features and
> >>>>>> improvements as previously, as our focus and work shifts to Camel
> >> v4
> >>>>>> instead.
> >>>>>>
> >>>>>> As a recipient of an email from Talend, your contact personal data
> >>>> will be
> >>>>>> on our systems. Please see our privacy notice. <
> >>>>>> https://www.talend.com/privacy/>
> >>>>>>
> >>>>>>
> >>>>>>
> --
> --
> François
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by fpapon <fp...@apache.org>.
Hi,
I think camel-karaf make sense to continue to exist and it could be nice
to be more simple to manage.
There is a PR thanks to JB (https://github.com/apache/camel-karaf/pull/173)
May be it could be nice if camel-karaf has it's own version and release
flow.
Mainly we have :
- camel-core-osgi: for the osgi integration of camel
- camel-karaf-command: karaf custom command for camel integration
- camel-karaf-features: big part of lib dependencies deployment in osgi env
- camel-components-osgi: list of camel osgi component
If there is no breaker between 2 versions of Camel we don't need to
update these modules and can be manage with version range so user can
choose which version of Camel he want to use with the same camel-karaf
version.
I certainly forgot some points :)
regards,
François
On 28/11/2022 11:21, Andrea Cosentino wrote:
> It's just my point of view. There are a lot of active contributors on Camel
> and we need to gather more opinions as possible.
>
> Let's see.
>
> Il giorno lun 28 nov 2022 alle ore 11:18 Jean-Baptiste Onofré <
> jb@nanthrax.net> ha scritto:
>
>> Hi Andrea,
>>
>> Fair comment. Then, if your proposal is just to retire camel-karaf, go
>> for it and start a vote. I agree with you and I will support this.
>> Maybe, we can just propose to maintain as best effort, but without
>> strong commitment in terms of releases, etc (like we do on
>> camel-extra).
>>
>> Regards
>> JB
>>
>> On Mon, Nov 28, 2022 at 11:04 AM Andrea Cosentino <an...@gmail.com>
>> wrote:
>>> 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é <
>>> jb@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 <an...@gmail.com>
>>>> wrote:
>>>>> Hello
>>>>>
>>>>> I'll come back for other questions. Let me just say that camel-karaf
>> is
>>>> too
>>>>> hard to maintain today. If it won't be released because of
>> misalignments,
>>>>> it should be aligned by some volunteers or community member and
>> released
>>>>> later. Active contributors are not really focused on Karaf runtime
>> and we
>>>>> cannot do everything. This doesn't mean we won't release camel Karaf
>>>>> anymore. It only means it could be released later on. Even after the
>> core
>>>>> camel and SB part have been released.
>>>>>
>>>>> In more than one situation aligning OSGi stuff have been really hard.
>>>> Less
>>>>> and less community members are helping on the Karaf side and
>> releasing
>>>>> sometimes have been slow down by these troubles. Also OSGi have been
>> drop
>>>>> in a lot of 3rd party libraries.
>>>>>
>>>>> So I'm +1 with this approach.
>>>>>
>>>>> I'll continue the discussion in the next days for the other points.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
>>>> scritto:
>>>>>> Hi Claus,
>>>>>>
>>>>>> That sounds like a good plan, here are the first questions that I
>> have
>>>> in
>>>>>> mind:
>>>>>>
>>>>>> * Why do we need to keep on releasing new LTS versions of
>> Camel 3?
>>>>>> * Why not simply consider 3.20 as the last LTS version of
>> Camel 3
>>>> and
>>>>>> only maintain it?
>>>>>> * What kind of features/improvements do you want to add to
>> Camel 3
>>>>>> after releasing 3.20?
>>>>>> * If camel-karaf is released independently, when will it be
>>>> released?
>>>>>> My fear is that it will be desynchronized with Camel very quickly.
>>>>>> *
>>>>>>
>>>>>> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean
>> 4
>>>> LTS
>>>>>> versions to support at the same time, don't you think that it is
>> too
>>>> many?
>>>>>> I'm wondering if it is not a good opportunity to rethink our LTS
>>>> version
>>>>>> policy. Could you please remind me why we decided to have this
>> policy
>>>> (2
>>>>>> LTS versions per year supported for one year)?
>>>>>>
>>>>>> I would personally prefer to have:
>>>>>>
>>>>>> * only one LTS version per year (or 2 if we keep on releasing
>> LTS
>>>>>> versions of Camel 3) but supported for at least 2 years instead of
>> one
>>>>>> otherwise Camel users are less inclined to migrate to the latest
>> LTS
>>>>>> version because 1 year of support doesn't really worth the
>> migration
>>>>>> effort, especially for big projects where the migration takes
>> several
>>>>>> months.
>>>>>> * only propose milestone versions or equivalent between 2 LTS
>>>> versions
>>>>>> for early adopters to add more clarity on which versions are LTS.
>>>> Indeed,
>>>>>> for example, the next LTS version will be 3.20 while we could
>> expect
>>>> 3.22
>>>>>> to be the next one after 3.14 and 3.18. With this logic, instead of
>>>>>> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19,
>> it
>>>> would
>>>>>> then be obvious to the Camel users that only 3.19 is an LTS
>> version as
>>>> all
>>>>>> final versions would then be LTS versions.
>>>>>>
>>>>>> What do you think of it?
>>>>>>
>>>>>> Regards,
>>>>>> Nicolas
>>>>>> ________________________________
>>>>>> From: Claus Ibsen <cl...@gmail.com>
>>>>>> Sent: Friday, November 25, 2022 11:42
>>>>>> To: dev <de...@camel.apache.org>
>>>>>> Subject: Camel 4 roadmap and affect on Camel 3
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> This is a proposal for a plan for Apache Camel 4 and how this can
>>>> affect
>>>>>> Camel 3.
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The overall scope is that the leap from Camel 3 to 4 is a lot less
>> than
>>>>>> going from Camel 2 to 3.
>>>>>>
>>>>>> And that we have a timebox approach where we aim for a 6 month
>> period
>>>> of
>>>>>> work.
>>>>>>
>>>>>> The need for Camel v4 is mainly driven by Java open source projects
>>>>>> migrating to jakarta APIs,
>>>>>>
>>>>>> and to keep up with popular runtimes a la Spring Boot and Quarkus,
>> and
>>>> to
>>>>>> jump to the next major Java version.
>>>>>>
>>>>>> Goals
>>>>>>
>>>>>> =====
>>>>>>
>>>>>> a) Primary Goals
>>>>>>
>>>>>> 1) Migrate from javax -> jakarta (JEE 10)
>>>>>>
>>>>>> 2) Java 17 as base line
>>>>>>
>>>>>> 3) Spring Framework 6
>>>>>>
>>>>>> 4) Spring Boot 3
>>>>>>
>>>>>> 5) Quarkus 3
>>>>>>
>>>>>> b) Release Goals
>>>>>>
>>>>>> 6) Release only what is ready (JEE10 / Java17 etc)
>>>>>>
>>>>>> This means that Camel components that are not ready (yet) will
>> be
>>>>>> dropped in a release until they are ready.
>>>>>>
>>>>>> 7) Release core + spring boot together
>>>>>>
>>>>>> 8) Release camel-karaf independently (like we do for other Camel
>>>> projects)
>>>>>> c) Major Goals
>>>>>>
>>>>>> 9) Support Java 17 features such as records, multiline strings, and
>>>> what
>>>>>> else
>>>>>>
>>>>>> 10) EIP model without JAXB dependency
>>>>>>
>>>>>> 11) Endpoint URI parsing (do not use java.net.URI)
>>>>>>
>>>>>> 12) Deprecate message.getIn()
>>>>>>
>>>>>> use getMessage() instead
>>>>>>
>>>>>> 13) Deprecate camel-cdi
>>>>>>
>>>>>> 14) Deprecate/Remove MDC logging (complex and buggy and does not
>> fit
>>>> modern
>>>>>> app development)
>>>>>>
>>>>>> d) Minor Goals
>>>>>>
>>>>>> 15) Remove MEP InOptionalOut (not in use)
>>>>>>
>>>>>> 16) Remove JUnit 4 support
>>>>>>
>>>>>>
>>>>>> Timeline
>>>>>>
>>>>>> =======
>>>>>>
>>>>>> The timelines are ESTIMATES and the number of releases can vary
>>>> depending
>>>>>> on need and how far we are in the process
>>>>>>
>>>>>> Feb 2023: Camel 4.0 milestone 1
>>>>>>
>>>>>> Mar 2023: Camel 4.0 milestone 2
>>>>>>
>>>>>> Apr 2023: Camel 4.0 RC1
>>>>>>
>>>>>> May 2023: Camel 4.0
>>>>>>
>>>>>> Aug 2023: Camel 4.1 LTS
>>>>>>
>>>>>> Oct 2023: Camel 4.2
>>>>>>
>>>>>> Dec 2023: Camel 4.3 LTS
>>>>>>
>>>>>> The plan is to start working on Camel 4 after the next Camel 3 LTS
>>>> release,
>>>>>> e.g. 3.20 which is planned for next month (December 2022).
>>>>>>
>>>>>> For Camel 3 then we slow down in releases and provide 2 LTS
>> releases
>>>> per
>>>>>> year.
>>>>>>
>>>>>> For example a scheduled could look as follows:
>>>>>>
>>>>>> Dec 2022: Camel 3.20 LTS
>>>>>>
>>>>>> Jun 2023: Camel 3.21 LTS
>>>>>>
>>>>>> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
>> Dec
>>>> 2024)
>>>>>> ???
>>>>>>
>>>>>> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
>> Dec
>>>> 2025)
>>>>>> ????
>>>>>>
>>>>>> Each Camel 3 LTS release will likely also contain less new
>> features and
>>>>>> improvements as previously, as our focus and work shifts to Camel
>> v4
>>>>>> instead.
>>>>>>
>>>>>> As a recipient of an email from Talend, your contact personal data
>>>> will be
>>>>>> on our systems. Please see our privacy notice. <
>>>>>> https://www.talend.com/privacy/>
>>>>>>
>>>>>>
>>>>>>
--
--
François
Re: Camel 4 roadmap and affect on Camel 3
Posted by Andrea Cosentino <an...@gmail.com>.
It's just my point of view. There are a lot of active contributors on Camel
and we need to gather more opinions as possible.
Let's see.
Il giorno lun 28 nov 2022 alle ore 11:18 Jean-Baptiste Onofré <
jb@nanthrax.net> ha scritto:
> Hi Andrea,
>
> Fair comment. Then, if your proposal is just to retire camel-karaf, go
> for it and start a vote. I agree with you and I will support this.
> Maybe, we can just propose to maintain as best effort, but without
> strong commitment in terms of releases, etc (like we do on
> camel-extra).
>
> Regards
> JB
>
> On Mon, Nov 28, 2022 at 11:04 AM Andrea Cosentino <an...@gmail.com>
> wrote:
> >
> > 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é <
> > jb@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 <an...@gmail.com>
> > > wrote:
> > > >
> > > > Hello
> > > >
> > > > I'll come back for other questions. Let me just say that camel-karaf
> is
> > > too
> > > > hard to maintain today. If it won't be released because of
> misalignments,
> > > > it should be aligned by some volunteers or community member and
> released
> > > > later. Active contributors are not really focused on Karaf runtime
> and we
> > > > cannot do everything. This doesn't mean we won't release camel Karaf
> > > > anymore. It only means it could be released later on. Even after the
> core
> > > > camel and SB part have been released.
> > > >
> > > > In more than one situation aligning OSGi stuff have been really hard.
> > > Less
> > > > and less community members are helping on the Karaf side and
> releasing
> > > > sometimes have been slow down by these troubles. Also OSGi have been
> drop
> > > > in a lot of 3rd party libraries.
> > > >
> > > > So I'm +1 with this approach.
> > > >
> > > > I'll continue the discussion in the next days for the other points.
> > > >
> > > > Cheers
> > > >
> > > >
> > > > Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> > > scritto:
> > > >
> > > > > Hi Claus,
> > > > >
> > > > > That sounds like a good plan, here are the first questions that I
> have
> > > in
> > > > > mind:
> > > > >
> > > > > * Why do we need to keep on releasing new LTS versions of
> Camel 3?
> > > > > * Why not simply consider 3.20 as the last LTS version of
> Camel 3
> > > and
> > > > > only maintain it?
> > > > > * What kind of features/improvements do you want to add to
> Camel 3
> > > > > after releasing 3.20?
> > > > > * If camel-karaf is released independently, when will it be
> > > released?
> > > > > My fear is that it will be desynchronized with Camel very quickly.
> > > > > *
> > > > >
> > > > > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean
> 4
> > > LTS
> > > > > versions to support at the same time, don't you think that it is
> too
> > > many?
> > > > >
> > > > > I'm wondering if it is not a good opportunity to rethink our LTS
> > > version
> > > > > policy. Could you please remind me why we decided to have this
> policy
> > > (2
> > > > > LTS versions per year supported for one year)?
> > > > >
> > > > > I would personally prefer to have:
> > > > >
> > > > > * only one LTS version per year (or 2 if we keep on releasing
> LTS
> > > > > versions of Camel 3) but supported for at least 2 years instead of
> one
> > > > > otherwise Camel users are less inclined to migrate to the latest
> LTS
> > > > > version because 1 year of support doesn't really worth the
> migration
> > > > > effort, especially for big projects where the migration takes
> several
> > > > > months.
> > > > > * only propose milestone versions or equivalent between 2 LTS
> > > versions
> > > > > for early adopters to add more clarity on which versions are LTS.
> > > Indeed,
> > > > > for example, the next LTS version will be 3.20 while we could
> expect
> > > 3.22
> > > > > to be the next one after 3.14 and 3.18. With this logic, instead of
> > > > > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19,
> it
> > > would
> > > > > then be obvious to the Camel users that only 3.19 is an LTS
> version as
> > > all
> > > > > final versions would then be LTS versions.
> > > > >
> > > > > What do you think of it?
> > > > >
> > > > > Regards,
> > > > > Nicolas
> > > > > ________________________________
> > > > > From: Claus Ibsen <cl...@gmail.com>
> > > > > Sent: Friday, November 25, 2022 11:42
> > > > > To: dev <de...@camel.apache.org>
> > > > > Subject: Camel 4 roadmap and affect on Camel 3
> > > > >
> > > > > Hi
> > > > >
> > > > > This is a proposal for a plan for Apache Camel 4 and how this can
> > > affect
> > > > > Camel 3.
> > > > >
> > > > > Summary
> > > > >
> > > > > =======
> > > > >
> > > > > The overall scope is that the leap from Camel 3 to 4 is a lot less
> than
> > > > > going from Camel 2 to 3.
> > > > >
> > > > > And that we have a timebox approach where we aim for a 6 month
> period
> > > of
> > > > > work.
> > > > >
> > > > > The need for Camel v4 is mainly driven by Java open source projects
> > > > > migrating to jakarta APIs,
> > > > >
> > > > > and to keep up with popular runtimes a la Spring Boot and Quarkus,
> and
> > > to
> > > > > jump to the next major Java version.
> > > > >
> > > > > Goals
> > > > >
> > > > > =====
> > > > >
> > > > > a) Primary Goals
> > > > >
> > > > > 1) Migrate from javax -> jakarta (JEE 10)
> > > > >
> > > > > 2) Java 17 as base line
> > > > >
> > > > > 3) Spring Framework 6
> > > > >
> > > > > 4) Spring Boot 3
> > > > >
> > > > > 5) Quarkus 3
> > > > >
> > > > > b) Release Goals
> > > > >
> > > > > 6) Release only what is ready (JEE10 / Java17 etc)
> > > > >
> > > > > This means that Camel components that are not ready (yet) will
> be
> > > > > dropped in a release until they are ready.
> > > > >
> > > > > 7) Release core + spring boot together
> > > > >
> > > > > 8) Release camel-karaf independently (like we do for other Camel
> > > projects)
> > > > >
> > > > > c) Major Goals
> > > > >
> > > > > 9) Support Java 17 features such as records, multiline strings, and
> > > what
> > > > > else
> > > > >
> > > > > 10) EIP model without JAXB dependency
> > > > >
> > > > > 11) Endpoint URI parsing (do not use java.net.URI)
> > > > >
> > > > > 12) Deprecate message.getIn()
> > > > >
> > > > > use getMessage() instead
> > > > >
> > > > > 13) Deprecate camel-cdi
> > > > >
> > > > > 14) Deprecate/Remove MDC logging (complex and buggy and does not
> fit
> > > modern
> > > > > app development)
> > > > >
> > > > > d) Minor Goals
> > > > >
> > > > > 15) Remove MEP InOptionalOut (not in use)
> > > > >
> > > > > 16) Remove JUnit 4 support
> > > > >
> > > > >
> > > > > Timeline
> > > > >
> > > > > =======
> > > > >
> > > > > The timelines are ESTIMATES and the number of releases can vary
> > > depending
> > > > > on need and how far we are in the process
> > > > >
> > > > > Feb 2023: Camel 4.0 milestone 1
> > > > >
> > > > > Mar 2023: Camel 4.0 milestone 2
> > > > >
> > > > > Apr 2023: Camel 4.0 RC1
> > > > >
> > > > > May 2023: Camel 4.0
> > > > >
> > > > > Aug 2023: Camel 4.1 LTS
> > > > >
> > > > > Oct 2023: Camel 4.2
> > > > >
> > > > > Dec 2023: Camel 4.3 LTS
> > > > >
> > > > > The plan is to start working on Camel 4 after the next Camel 3 LTS
> > > release,
> > > > > e.g. 3.20 which is planned for next month (December 2022).
> > > > >
> > > > > For Camel 3 then we slow down in releases and provide 2 LTS
> releases
> > > per
> > > > > year.
> > > > >
> > > > > For example a scheduled could look as follows:
> > > > >
> > > > > Dec 2022: Camel 3.20 LTS
> > > > >
> > > > > Jun 2023: Camel 3.21 LTS
> > > > >
> > > > > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
> Dec
> > > 2024)
> > > > > ???
> > > > >
> > > > > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
> Dec
> > > 2025)
> > > > > ????
> > > > >
> > > > > Each Camel 3 LTS release will likely also contain less new
> features and
> > > > > improvements as previously, as our focus and work shifts to Camel
> v4
> > > > > instead.
> > > > >
> > > > > As a recipient of an email from Talend, your contact personal data
> > > will be
> > > > > on our systems. Please see our privacy notice. <
> > > > > https://www.talend.com/privacy/>
> > > > >
> > > > >
> > > > >
> > >
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Andrea,
Fair comment. Then, if your proposal is just to retire camel-karaf, go
for it and start a vote. I agree with you and I will support this.
Maybe, we can just propose to maintain as best effort, but without
strong commitment in terms of releases, etc (like we do on
camel-extra).
Regards
JB
On Mon, Nov 28, 2022 at 11:04 AM Andrea Cosentino <an...@gmail.com> wrote:
>
> 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é <
> jb@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 <an...@gmail.com>
> > wrote:
> > >
> > > Hello
> > >
> > > I'll come back for other questions. Let me just say that camel-karaf is
> > too
> > > hard to maintain today. If it won't be released because of misalignments,
> > > it should be aligned by some volunteers or community member and released
> > > later. Active contributors are not really focused on Karaf runtime and we
> > > cannot do everything. This doesn't mean we won't release camel Karaf
> > > anymore. It only means it could be released later on. Even after the core
> > > camel and SB part have been released.
> > >
> > > In more than one situation aligning OSGi stuff have been really hard.
> > Less
> > > and less community members are helping on the Karaf side and releasing
> > > sometimes have been slow down by these troubles. Also OSGi have been drop
> > > in a lot of 3rd party libraries.
> > >
> > > So I'm +1 with this approach.
> > >
> > > I'll continue the discussion in the next days for the other points.
> > >
> > > Cheers
> > >
> > >
> > > Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> > scritto:
> > >
> > > > Hi Claus,
> > > >
> > > > That sounds like a good plan, here are the first questions that I have
> > in
> > > > mind:
> > > >
> > > > * Why do we need to keep on releasing new LTS versions of Camel 3?
> > > > * Why not simply consider 3.20 as the last LTS version of Camel 3
> > and
> > > > only maintain it?
> > > > * What kind of features/improvements do you want to add to Camel 3
> > > > after releasing 3.20?
> > > > * If camel-karaf is released independently, when will it be
> > released?
> > > > My fear is that it will be desynchronized with Camel very quickly.
> > > > *
> > > >
> > > > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
> > LTS
> > > > versions to support at the same time, don't you think that it is too
> > many?
> > > >
> > > > I'm wondering if it is not a good opportunity to rethink our LTS
> > version
> > > > policy. Could you please remind me why we decided to have this policy
> > (2
> > > > LTS versions per year supported for one year)?
> > > >
> > > > I would personally prefer to have:
> > > >
> > > > * only one LTS version per year (or 2 if we keep on releasing LTS
> > > > versions of Camel 3) but supported for at least 2 years instead of one
> > > > otherwise Camel users are less inclined to migrate to the latest LTS
> > > > version because 1 year of support doesn't really worth the migration
> > > > effort, especially for big projects where the migration takes several
> > > > months.
> > > > * only propose milestone versions or equivalent between 2 LTS
> > versions
> > > > for early adopters to add more clarity on which versions are LTS.
> > Indeed,
> > > > for example, the next LTS version will be 3.20 while we could expect
> > 3.22
> > > > to be the next one after 3.14 and 3.18. With this logic, instead of
> > > > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
> > would
> > > > then be obvious to the Camel users that only 3.19 is an LTS version as
> > all
> > > > final versions would then be LTS versions.
> > > >
> > > > What do you think of it?
> > > >
> > > > Regards,
> > > > Nicolas
> > > > ________________________________
> > > > From: Claus Ibsen <cl...@gmail.com>
> > > > Sent: Friday, November 25, 2022 11:42
> > > > To: dev <de...@camel.apache.org>
> > > > Subject: Camel 4 roadmap and affect on Camel 3
> > > >
> > > > Hi
> > > >
> > > > This is a proposal for a plan for Apache Camel 4 and how this can
> > affect
> > > > Camel 3.
> > > >
> > > > Summary
> > > >
> > > > =======
> > > >
> > > > The overall scope is that the leap from Camel 3 to 4 is a lot less than
> > > > going from Camel 2 to 3.
> > > >
> > > > And that we have a timebox approach where we aim for a 6 month period
> > of
> > > > work.
> > > >
> > > > The need for Camel v4 is mainly driven by Java open source projects
> > > > migrating to jakarta APIs,
> > > >
> > > > and to keep up with popular runtimes a la Spring Boot and Quarkus, and
> > to
> > > > jump to the next major Java version.
> > > >
> > > > Goals
> > > >
> > > > =====
> > > >
> > > > a) Primary Goals
> > > >
> > > > 1) Migrate from javax -> jakarta (JEE 10)
> > > >
> > > > 2) Java 17 as base line
> > > >
> > > > 3) Spring Framework 6
> > > >
> > > > 4) Spring Boot 3
> > > >
> > > > 5) Quarkus 3
> > > >
> > > > b) Release Goals
> > > >
> > > > 6) Release only what is ready (JEE10 / Java17 etc)
> > > >
> > > > This means that Camel components that are not ready (yet) will be
> > > > dropped in a release until they are ready.
> > > >
> > > > 7) Release core + spring boot together
> > > >
> > > > 8) Release camel-karaf independently (like we do for other Camel
> > projects)
> > > >
> > > > c) Major Goals
> > > >
> > > > 9) Support Java 17 features such as records, multiline strings, and
> > what
> > > > else
> > > >
> > > > 10) EIP model without JAXB dependency
> > > >
> > > > 11) Endpoint URI parsing (do not use java.net.URI)
> > > >
> > > > 12) Deprecate message.getIn()
> > > >
> > > > use getMessage() instead
> > > >
> > > > 13) Deprecate camel-cdi
> > > >
> > > > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
> > modern
> > > > app development)
> > > >
> > > > d) Minor Goals
> > > >
> > > > 15) Remove MEP InOptionalOut (not in use)
> > > >
> > > > 16) Remove JUnit 4 support
> > > >
> > > >
> > > > Timeline
> > > >
> > > > =======
> > > >
> > > > The timelines are ESTIMATES and the number of releases can vary
> > depending
> > > > on need and how far we are in the process
> > > >
> > > > Feb 2023: Camel 4.0 milestone 1
> > > >
> > > > Mar 2023: Camel 4.0 milestone 2
> > > >
> > > > Apr 2023: Camel 4.0 RC1
> > > >
> > > > May 2023: Camel 4.0
> > > >
> > > > Aug 2023: Camel 4.1 LTS
> > > >
> > > > Oct 2023: Camel 4.2
> > > >
> > > > Dec 2023: Camel 4.3 LTS
> > > >
> > > > The plan is to start working on Camel 4 after the next Camel 3 LTS
> > release,
> > > > e.g. 3.20 which is planned for next month (December 2022).
> > > >
> > > > For Camel 3 then we slow down in releases and provide 2 LTS releases
> > per
> > > > year.
> > > >
> > > > For example a scheduled could look as follows:
> > > >
> > > > Dec 2022: Camel 3.20 LTS
> > > >
> > > > Jun 2023: Camel 3.21 LTS
> > > >
> > > > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
> > 2024)
> > > > ???
> > > >
> > > > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
> > 2025)
> > > > ????
> > > >
> > > > Each Camel 3 LTS release will likely also contain less new features and
> > > > improvements as previously, as our focus and work shifts to Camel v4
> > > > instead.
> > > >
> > > > As a recipient of an email from Talend, your contact personal data
> > will be
> > > > on our systems. Please see our privacy notice. <
> > > > https://www.talend.com/privacy/>
> > > >
> > > >
> > > >
> >
Re: Camel 4 roadmap and affect on Camel 3
Posted by Andrea Cosentino <an...@gmail.com>.
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é <
jb@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 <an...@gmail.com>
> wrote:
> >
> > Hello
> >
> > I'll come back for other questions. Let me just say that camel-karaf is
> too
> > hard to maintain today. If it won't be released because of misalignments,
> > it should be aligned by some volunteers or community member and released
> > later. Active contributors are not really focused on Karaf runtime and we
> > cannot do everything. This doesn't mean we won't release camel Karaf
> > anymore. It only means it could be released later on. Even after the core
> > camel and SB part have been released.
> >
> > In more than one situation aligning OSGi stuff have been really hard.
> Less
> > and less community members are helping on the Karaf side and releasing
> > sometimes have been slow down by these troubles. Also OSGi have been drop
> > in a lot of 3rd party libraries.
> >
> > So I'm +1 with this approach.
> >
> > I'll continue the discussion in the next days for the other points.
> >
> > Cheers
> >
> >
> > Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha
> scritto:
> >
> > > Hi Claus,
> > >
> > > That sounds like a good plan, here are the first questions that I have
> in
> > > mind:
> > >
> > > * Why do we need to keep on releasing new LTS versions of Camel 3?
> > > * Why not simply consider 3.20 as the last LTS version of Camel 3
> and
> > > only maintain it?
> > > * What kind of features/improvements do you want to add to Camel 3
> > > after releasing 3.20?
> > > * If camel-karaf is released independently, when will it be
> released?
> > > My fear is that it will be desynchronized with Camel very quickly.
> > > *
> > >
> > > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4
> LTS
> > > versions to support at the same time, don't you think that it is too
> many?
> > >
> > > I'm wondering if it is not a good opportunity to rethink our LTS
> version
> > > policy. Could you please remind me why we decided to have this policy
> (2
> > > LTS versions per year supported for one year)?
> > >
> > > I would personally prefer to have:
> > >
> > > * only one LTS version per year (or 2 if we keep on releasing LTS
> > > versions of Camel 3) but supported for at least 2 years instead of one
> > > otherwise Camel users are less inclined to migrate to the latest LTS
> > > version because 1 year of support doesn't really worth the migration
> > > effort, especially for big projects where the migration takes several
> > > months.
> > > * only propose milestone versions or equivalent between 2 LTS
> versions
> > > for early adopters to add more clarity on which versions are LTS.
> Indeed,
> > > for example, the next LTS version will be 3.20 while we could expect
> 3.22
> > > to be the next one after 3.14 and 3.18. With this logic, instead of
> > > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it
> would
> > > then be obvious to the Camel users that only 3.19 is an LTS version as
> all
> > > final versions would then be LTS versions.
> > >
> > > What do you think of it?
> > >
> > > Regards,
> > > Nicolas
> > > ________________________________
> > > From: Claus Ibsen <cl...@gmail.com>
> > > Sent: Friday, November 25, 2022 11:42
> > > To: dev <de...@camel.apache.org>
> > > Subject: Camel 4 roadmap and affect on Camel 3
> > >
> > > Hi
> > >
> > > This is a proposal for a plan for Apache Camel 4 and how this can
> affect
> > > Camel 3.
> > >
> > > Summary
> > >
> > > =======
> > >
> > > The overall scope is that the leap from Camel 3 to 4 is a lot less than
> > > going from Camel 2 to 3.
> > >
> > > And that we have a timebox approach where we aim for a 6 month period
> of
> > > work.
> > >
> > > The need for Camel v4 is mainly driven by Java open source projects
> > > migrating to jakarta APIs,
> > >
> > > and to keep up with popular runtimes a la Spring Boot and Quarkus, and
> to
> > > jump to the next major Java version.
> > >
> > > Goals
> > >
> > > =====
> > >
> > > a) Primary Goals
> > >
> > > 1) Migrate from javax -> jakarta (JEE 10)
> > >
> > > 2) Java 17 as base line
> > >
> > > 3) Spring Framework 6
> > >
> > > 4) Spring Boot 3
> > >
> > > 5) Quarkus 3
> > >
> > > b) Release Goals
> > >
> > > 6) Release only what is ready (JEE10 / Java17 etc)
> > >
> > > This means that Camel components that are not ready (yet) will be
> > > dropped in a release until they are ready.
> > >
> > > 7) Release core + spring boot together
> > >
> > > 8) Release camel-karaf independently (like we do for other Camel
> projects)
> > >
> > > c) Major Goals
> > >
> > > 9) Support Java 17 features such as records, multiline strings, and
> what
> > > else
> > >
> > > 10) EIP model without JAXB dependency
> > >
> > > 11) Endpoint URI parsing (do not use java.net.URI)
> > >
> > > 12) Deprecate message.getIn()
> > >
> > > use getMessage() instead
> > >
> > > 13) Deprecate camel-cdi
> > >
> > > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit
> modern
> > > app development)
> > >
> > > d) Minor Goals
> > >
> > > 15) Remove MEP InOptionalOut (not in use)
> > >
> > > 16) Remove JUnit 4 support
> > >
> > >
> > > Timeline
> > >
> > > =======
> > >
> > > The timelines are ESTIMATES and the number of releases can vary
> depending
> > > on need and how far we are in the process
> > >
> > > Feb 2023: Camel 4.0 milestone 1
> > >
> > > Mar 2023: Camel 4.0 milestone 2
> > >
> > > Apr 2023: Camel 4.0 RC1
> > >
> > > May 2023: Camel 4.0
> > >
> > > Aug 2023: Camel 4.1 LTS
> > >
> > > Oct 2023: Camel 4.2
> > >
> > > Dec 2023: Camel 4.3 LTS
> > >
> > > The plan is to start working on Camel 4 after the next Camel 3 LTS
> release,
> > > e.g. 3.20 which is planned for next month (December 2022).
> > >
> > > For Camel 3 then we slow down in releases and provide 2 LTS releases
> per
> > > year.
> > >
> > > For example a scheduled could look as follows:
> > >
> > > Dec 2022: Camel 3.20 LTS
> > >
> > > Jun 2023: Camel 3.21 LTS
> > >
> > > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec
> 2024)
> > > ???
> > >
> > > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec
> 2025)
> > > ????
> > >
> > > Each Camel 3 LTS release will likely also contain less new features and
> > > improvements as previously, as our focus and work shifts to Camel v4
> > > instead.
> > >
> > > As a recipient of an email from Talend, your contact personal data
> will be
> > > on our systems. Please see our privacy notice. <
> > > https://www.talend.com/privacy/>
> > >
> > >
> > >
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <an...@gmail.com> wrote:
>
> Hello
>
> I'll come back for other questions. Let me just say that camel-karaf is too
> hard to maintain today. If it won't be released because of misalignments,
> it should be aligned by some volunteers or community member and released
> later. Active contributors are not really focused on Karaf runtime and we
> cannot do everything. This doesn't mean we won't release camel Karaf
> anymore. It only means it could be released later on. Even after the core
> camel and SB part have been released.
>
> In more than one situation aligning OSGi stuff have been really hard. Less
> and less community members are helping on the Karaf side and releasing
> sometimes have been slow down by these troubles. Also OSGi have been drop
> in a lot of 3rd party libraries.
>
> So I'm +1 with this approach.
>
> I'll continue the discussion in the next days for the other points.
>
> Cheers
>
>
> Il ven 25 nov 2022, 15:06 Nicolas Filotto <nf...@talend.com> ha scritto:
>
> > Hi Claus,
> >
> > That sounds like a good plan, here are the first questions that I have in
> > mind:
> >
> > * Why do we need to keep on releasing new LTS versions of Camel 3?
> > * Why not simply consider 3.20 as the last LTS version of Camel 3 and
> > only maintain it?
> > * What kind of features/improvements do you want to add to Camel 3
> > after releasing 3.20?
> > * If camel-karaf is released independently, when will it be released?
> > My fear is that it will be desynchronized with Camel very quickly.
> > *
> >
> > With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4 LTS
> > versions to support at the same time, don't you think that it is too many?
> >
> > I'm wondering if it is not a good opportunity to rethink our LTS version
> > policy. Could you please remind me why we decided to have this policy (2
> > LTS versions per year supported for one year)?
> >
> > I would personally prefer to have:
> >
> > * only one LTS version per year (or 2 if we keep on releasing LTS
> > versions of Camel 3) but supported for at least 2 years instead of one
> > otherwise Camel users are less inclined to migrate to the latest LTS
> > version because 1 year of support doesn't really worth the migration
> > effort, especially for big projects where the migration takes several
> > months.
> > * only propose milestone versions or equivalent between 2 LTS versions
> > for early adopters to add more clarity on which versions are LTS. Indeed,
> > for example, the next LTS version will be 3.20 while we could expect 3.22
> > to be the next one after 3.14 and 3.18. With this logic, instead of
> > releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it would
> > then be obvious to the Camel users that only 3.19 is an LTS version as all
> > final versions would then be LTS versions.
> >
> > What do you think of it?
> >
> > Regards,
> > Nicolas
> > ________________________________
> > From: Claus Ibsen <cl...@gmail.com>
> > Sent: Friday, November 25, 2022 11:42
> > To: dev <de...@camel.apache.org>
> > Subject: Camel 4 roadmap and affect on Camel 3
> >
> > Hi
> >
> > This is a proposal for a plan for Apache Camel 4 and how this can affect
> > Camel 3.
> >
> > Summary
> >
> > =======
> >
> > The overall scope is that the leap from Camel 3 to 4 is a lot less than
> > going from Camel 2 to 3.
> >
> > And that we have a timebox approach where we aim for a 6 month period of
> > work.
> >
> > The need for Camel v4 is mainly driven by Java open source projects
> > migrating to jakarta APIs,
> >
> > and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
> > jump to the next major Java version.
> >
> > Goals
> >
> > =====
> >
> > a) Primary Goals
> >
> > 1) Migrate from javax -> jakarta (JEE 10)
> >
> > 2) Java 17 as base line
> >
> > 3) Spring Framework 6
> >
> > 4) Spring Boot 3
> >
> > 5) Quarkus 3
> >
> > b) Release Goals
> >
> > 6) Release only what is ready (JEE10 / Java17 etc)
> >
> > This means that Camel components that are not ready (yet) will be
> > dropped in a release until they are ready.
> >
> > 7) Release core + spring boot together
> >
> > 8) Release camel-karaf independently (like we do for other Camel projects)
> >
> > c) Major Goals
> >
> > 9) Support Java 17 features such as records, multiline strings, and what
> > else
> >
> > 10) EIP model without JAXB dependency
> >
> > 11) Endpoint URI parsing (do not use java.net.URI)
> >
> > 12) Deprecate message.getIn()
> >
> > use getMessage() instead
> >
> > 13) Deprecate camel-cdi
> >
> > 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
> > app development)
> >
> > d) Minor Goals
> >
> > 15) Remove MEP InOptionalOut (not in use)
> >
> > 16) Remove JUnit 4 support
> >
> >
> > Timeline
> >
> > =======
> >
> > The timelines are ESTIMATES and the number of releases can vary depending
> > on need and how far we are in the process
> >
> > Feb 2023: Camel 4.0 milestone 1
> >
> > Mar 2023: Camel 4.0 milestone 2
> >
> > Apr 2023: Camel 4.0 RC1
> >
> > May 2023: Camel 4.0
> >
> > Aug 2023: Camel 4.1 LTS
> >
> > Oct 2023: Camel 4.2
> >
> > Dec 2023: Camel 4.3 LTS
> >
> > The plan is to start working on Camel 4 after the next Camel 3 LTS release,
> > e.g. 3.20 which is planned for next month (December 2022).
> >
> > For Camel 3 then we slow down in releases and provide 2 LTS releases per
> > year.
> >
> > For example a scheduled could look as follows:
> >
> > Dec 2022: Camel 3.20 LTS
> >
> > Jun 2023: Camel 3.21 LTS
> >
> > Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
> > ???
> >
> > Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
> > ????
> >
> > Each Camel 3 LTS release will likely also contain less new features and
> > improvements as previously, as our focus and work shifts to Camel v4
> > instead.
> >
> > As a recipient of an email from Talend, your contact personal data will be
> > on our systems. Please see our privacy notice. <
> > https://www.talend.com/privacy/>
> >
> >
> >
Re: Camel 4 roadmap and affect on Camel 3
Posted by Andrea Cosentino <an...@gmail.com>.
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 <nf...@talend.com> ha scritto:
> Hi Claus,
>
> That sounds like a good plan, here are the first questions that I have in
> mind:
>
> * Why do we need to keep on releasing new LTS versions of Camel 3?
> * Why not simply consider 3.20 as the last LTS version of Camel 3 and
> only maintain it?
> * What kind of features/improvements do you want to add to Camel 3
> after releasing 3.20?
> * If camel-karaf is released independently, when will it be released?
> My fear is that it will be desynchronized with Camel very quickly.
> *
>
> With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean 4 LTS
> versions to support at the same time, don't you think that it is too many?
>
> I'm wondering if it is not a good opportunity to rethink our LTS version
> policy. Could you please remind me why we decided to have this policy (2
> LTS versions per year supported for one year)?
>
> I would personally prefer to have:
>
> * only one LTS version per year (or 2 if we keep on releasing LTS
> versions of Camel 3) but supported for at least 2 years instead of one
> otherwise Camel users are less inclined to migrate to the latest LTS
> version because 1 year of support doesn't really worth the migration
> effort, especially for big projects where the migration takes several
> months.
> * only propose milestone versions or equivalent between 2 LTS versions
> for early adopters to add more clarity on which versions are LTS. Indeed,
> for example, the next LTS version will be 3.20 while we could expect 3.22
> to be the next one after 3.14 and 3.18. With this logic, instead of
> releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19, it would
> then be obvious to the Camel users that only 3.19 is an LTS version as all
> final versions would then be LTS versions.
>
> What do you think of it?
>
> Regards,
> Nicolas
> ________________________________
> From: Claus Ibsen <cl...@gmail.com>
> Sent: Friday, November 25, 2022 11:42
> To: dev <de...@camel.apache.org>
> Subject: Camel 4 roadmap and affect on Camel 3
>
> Hi
>
> This is a proposal for a plan for Apache Camel 4 and how this can affect
> Camel 3.
>
> Summary
>
> =======
>
> The overall scope is that the leap from Camel 3 to 4 is a lot less than
> going from Camel 2 to 3.
>
> And that we have a timebox approach where we aim for a 6 month period of
> work.
>
> The need for Camel v4 is mainly driven by Java open source projects
> migrating to jakarta APIs,
>
> and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
> jump to the next major Java version.
>
> Goals
>
> =====
>
> a) Primary Goals
>
> 1) Migrate from javax -> jakarta (JEE 10)
>
> 2) Java 17 as base line
>
> 3) Spring Framework 6
>
> 4) Spring Boot 3
>
> 5) Quarkus 3
>
> b) Release Goals
>
> 6) Release only what is ready (JEE10 / Java17 etc)
>
> This means that Camel components that are not ready (yet) will be
> dropped in a release until they are ready.
>
> 7) Release core + spring boot together
>
> 8) Release camel-karaf independently (like we do for other Camel projects)
>
> c) Major Goals
>
> 9) Support Java 17 features such as records, multiline strings, and what
> else
>
> 10) EIP model without JAXB dependency
>
> 11) Endpoint URI parsing (do not use java.net.URI)
>
> 12) Deprecate message.getIn()
>
> use getMessage() instead
>
> 13) Deprecate camel-cdi
>
> 14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
> app development)
>
> d) Minor Goals
>
> 15) Remove MEP InOptionalOut (not in use)
>
> 16) Remove JUnit 4 support
>
>
> Timeline
>
> =======
>
> The timelines are ESTIMATES and the number of releases can vary depending
> on need and how far we are in the process
>
> Feb 2023: Camel 4.0 milestone 1
>
> Mar 2023: Camel 4.0 milestone 2
>
> Apr 2023: Camel 4.0 RC1
>
> May 2023: Camel 4.0
>
> Aug 2023: Camel 4.1 LTS
>
> Oct 2023: Camel 4.2
>
> Dec 2023: Camel 4.3 LTS
>
> The plan is to start working on Camel 4 after the next Camel 3 LTS release,
> e.g. 3.20 which is planned for next month (December 2022).
>
> For Camel 3 then we slow down in releases and provide 2 LTS releases per
> year.
>
> For example a scheduled could look as follows:
>
> Dec 2022: Camel 3.20 LTS
>
> Jun 2023: Camel 3.21 LTS
>
> Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
> ???
>
> Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
> ????
>
> Each Camel 3 LTS release will likely also contain less new features and
> improvements as previously, as our focus and work shifts to Camel v4
> instead.
>
> As a recipient of an email from Talend, your contact personal data will be
> on our systems. Please see our privacy notice. <
> https://www.talend.com/privacy/>
>
>
>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Nicolas Filotto <nf...@talend.com>.
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 <cl...@gmail.com>
Sent: Friday, November 25, 2022 11:42
To: dev <de...@camel.apache.org>
Subject: Camel 4 roadmap and affect on Camel 3
Hi
This is a proposal for a plan for Apache Camel 4 and how this can affect
Camel 3.
Summary
=======
The overall scope is that the leap from Camel 3 to 4 is a lot less than
going from Camel 2 to 3.
And that we have a timebox approach where we aim for a 6 month period of
work.
The need for Camel v4 is mainly driven by Java open source projects
migrating to jakarta APIs,
and to keep up with popular runtimes a la Spring Boot and Quarkus, and to
jump to the next major Java version.
Goals
=====
a) Primary Goals
1) Migrate from javax -> jakarta (JEE 10)
2) Java 17 as base line
3) Spring Framework 6
4) Spring Boot 3
5) Quarkus 3
b) Release Goals
6) Release only what is ready (JEE10 / Java17 etc)
This means that Camel components that are not ready (yet) will be
dropped in a release until they are ready.
7) Release core + spring boot together
8) Release camel-karaf independently (like we do for other Camel projects)
c) Major Goals
9) Support Java 17 features such as records, multiline strings, and what
else
10) EIP model without JAXB dependency
11) Endpoint URI parsing (do not use java.net.URI)
12) Deprecate message.getIn()
use getMessage() instead
13) Deprecate camel-cdi
14) Deprecate/Remove MDC logging (complex and buggy and does not fit modern
app development)
d) Minor Goals
15) Remove MEP InOptionalOut (not in use)
16) Remove JUnit 4 support
Timeline
=======
The timelines are ESTIMATES and the number of releases can vary depending
on need and how far we are in the process
Feb 2023: Camel 4.0 milestone 1
Mar 2023: Camel 4.0 milestone 2
Apr 2023: Camel 4.0 RC1
May 2023: Camel 4.0
Aug 2023: Camel 4.1 LTS
Oct 2023: Camel 4.2
Dec 2023: Camel 4.3 LTS
The plan is to start working on Camel 4 after the next Camel 3 LTS release,
e.g. 3.20 which is planned for next month (December 2022).
For Camel 3 then we slow down in releases and provide 2 LTS releases per
year.
For example a scheduled could look as follows:
Dec 2022: Camel 3.20 LTS
Jun 2023: Camel 3.21 LTS
Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until Dec 2024)
???
Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until Dec 2025)
????
Each Camel 3 LTS release will likely also contain less new features and
improvements as previously, as our focus and work shifts to Camel v4
instead.
As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our privacy notice. <https://www.talend.com/privacy/>
Re: Camel 4 roadmap and affect on Camel 3
Posted by Otavio Rodolfo Piske <an...@gmail.com>.
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 <cl...@gmail.com> 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
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Dec 9, 2022 at 2:06 PM Otavio Rodolfo Piske <an...@gmail.com>
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 <cl...@gmail.com> 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 <cl...@gmail.com>
> > 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
>
--
Claus Ibsen
-----------------
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel 4 roadmap and affect on Camel 3
Posted by Otavio Rodolfo Piske <an...@gmail.com>.
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 <cl...@gmail.com> 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 <cl...@gmail.com>
> 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
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> 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