Hi
On Mon, Nov 28, 2022 at 10:40 AM Jean-Baptiste Onofré <j...@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 <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/> > > > > > > > > > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
