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 <[email protected]> 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é < > > [email protected]> 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 <[email protected]> > >> 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é < > >>> [email protected]> 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 <[email protected]> > >>>> 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 <[email protected]> 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 <[email protected]> > >>>>>> Sent: Friday, November 25, 2022 11:42 > >>>>>> To: dev <[email protected]> > >>>>>> 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 >
