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é <
j...@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 <anco...@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é <
j...@nanthrax.net> ha scritto:
Hi guys,
I understand that Karaf/OSGi is not in the Camel community target
anymore, and it makes sense.
I proposed a time ago to refactor the approach of Camel components for
Karaf, using special packaging (embedded the deps as private to avoid
to have bunch of SMX bundles deps), etc.
Even at Karaf, there are discussions about the next step in the
project decoupled from OSGi (see Minho).
I would split the discussion in two parts:
- In terms of the roadmap/Camel future, I don't think it's worth it
for Camel community to maintain OSGi/Karaf support anymore. It's
always possible to wrap Camel routes in an uber jar and deploy in
Karaf.
- In terms of community/maintenance, I think camel-karaf could be part
of the Karaf community. We had a similar discussion about jclouds: the
jclouds community didn't want to maintain jclouds-karaf anymore (for
the same reasons as the Camel community). The jclouds community asked
the karaf community if they were interested in maintaining and
managing jclouds-karaf. So we can do the same for camel-karaf: the
karaf community can take the lead there and maintain it.
Thoughts ?
Regards
JB
On Sat, Nov 26, 2022 at 9:51 AM Andrea Cosentino <anco...@gmail.com>
wrote:
Hello
I'll come back for other questions. Let me just say that camel-karaf
is
too
hard to maintain today. If it won't be released because of
misalignments,
it should be aligned by some volunteers or community member and
released
later. Active contributors are not really focused on Karaf runtime
and we
cannot do everything. This doesn't mean we won't release camel Karaf
anymore. It only means it could be released later on. Even after the
core
camel and SB part have been released.
In more than one situation aligning OSGi stuff have been really hard.
Less
and less community members are helping on the Karaf side and
releasing
sometimes have been slow down by these troubles. Also OSGi have been
drop
in a lot of 3rd party libraries.
So I'm +1 with this approach.
I'll continue the discussion in the next days for the other points.
Cheers
Il ven 25 nov 2022, 15:06 Nicolas Filotto <nfilo...@talend.com> ha
scritto:
Hi Claus,
That sounds like a good plan, here are the first questions that I
have
in
mind:
* Why do we need to keep on releasing new LTS versions of
Camel 3?
* Why not simply consider 3.20 as the last LTS version of
Camel 3
and
only maintain it?
* What kind of features/improvements do you want to add to
Camel 3
after releasing 3.20?
* If camel-karaf is released independently, when will it be
released?
My fear is that it will be desynchronized with Camel very quickly.
*
With 2 LTS of Camel 3 and 2 LTS of Camel 4 per year, it would mean
4
LTS
versions to support at the same time, don't you think that it is
too
many?
I'm wondering if it is not a good opportunity to rethink our LTS
version
policy. Could you please remind me why we decided to have this
policy
(2
LTS versions per year supported for one year)?
I would personally prefer to have:
* only one LTS version per year (or 2 if we keep on releasing
LTS
versions of Camel 3) but supported for at least 2 years instead of
one
otherwise Camel users are less inclined to migrate to the latest
LTS
version because 1 year of support doesn't really worth the
migration
effort, especially for big projects where the migration takes
several
months.
* only propose milestone versions or equivalent between 2 LTS
versions
for early adopters to add more clarity on which versions are LTS.
Indeed,
for example, the next LTS version will be 3.20 while we could
expect
3.22
to be the next one after 3.14 and 3.18. With this logic, instead of
releasing 3.19 and 3.20, we could have released 3.19 M1 and 3.19,
it
would
then be obvious to the Camel users that only 3.19 is an LTS
version as
all
final versions would then be LTS versions.
What do you think of it?
Regards,
Nicolas
________________________________
From: Claus Ibsen <claus.ib...@gmail.com>
Sent: Friday, November 25, 2022 11:42
To: dev <dev@camel.apache.org>
Subject: Camel 4 roadmap and affect on Camel 3
Hi
This is a proposal for a plan for Apache Camel 4 and how this can
affect
Camel 3.
Summary
=======
The overall scope is that the leap from Camel 3 to 4 is a lot less
than
going from Camel 2 to 3.
And that we have a timebox approach where we aim for a 6 month
period
of
work.
The need for Camel v4 is mainly driven by Java open source projects
migrating to jakarta APIs,
and to keep up with popular runtimes a la Spring Boot and Quarkus,
and
to
jump to the next major Java version.
Goals
=====
a) Primary Goals
1) Migrate from javax -> jakarta (JEE 10)
2) Java 17 as base line
3) Spring Framework 6
4) Spring Boot 3
5) Quarkus 3
b) Release Goals
6) Release only what is ready (JEE10 / Java17 etc)
This means that Camel components that are not ready (yet) will
be
dropped in a release until they are ready.
7) Release core + spring boot together
8) Release camel-karaf independently (like we do for other Camel
projects)
c) Major Goals
9) Support Java 17 features such as records, multiline strings, and
what
else
10) EIP model without JAXB dependency
11) Endpoint URI parsing (do not use java.net.URI)
12) Deprecate message.getIn()
use getMessage() instead
13) Deprecate camel-cdi
14) Deprecate/Remove MDC logging (complex and buggy and does not
fit
modern
app development)
d) Minor Goals
15) Remove MEP InOptionalOut (not in use)
16) Remove JUnit 4 support
Timeline
=======
The timelines are ESTIMATES and the number of releases can vary
depending
on need and how far we are in the process
Feb 2023: Camel 4.0 milestone 1
Mar 2023: Camel 4.0 milestone 2
Apr 2023: Camel 4.0 RC1
May 2023: Camel 4.0
Aug 2023: Camel 4.1 LTS
Oct 2023: Camel 4.2
Dec 2023: Camel 4.3 LTS
The plan is to start working on Camel 4 after the next Camel 3 LTS
release,
e.g. 3.20 which is planned for next month (December 2022).
For Camel 3 then we slow down in releases and provide 2 LTS
releases
per
year.
For example a scheduled could look as follows:
Dec 2022: Camel 3.20 LTS
Jun 2023: Camel 3.21 LTS
Dec 2023: Camel 3.22 LTS (last Camel v3 release, supported until
Dec
2024)
???
Jun 2024: Camel 3.23 LTS (last Camel v3 release, supported until
Dec
2025)
????
Each Camel 3 LTS release will likely also contain less new
features and
improvements as previously, as our focus and work shifts to Camel
v4
instead.
As a recipient of an email from Talend, your contact personal data
will be
on our systems. Please see our privacy notice. <
https://www.talend.com/privacy/>
--
--
François
