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/> > > > > > > > > > > > > > > > > > > >
