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é < j...@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 <fpa...@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é < > > > 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 > > >
