This would become something karaf-camel is responsible for.
Il giorno mer 30 nov 2022 alle ore 13:49 fpapon <fpa...@apache.org> ha scritto: > Hi, > > For this point "Camel v4 core and component JARs will no longer generate > OSGi MANIFEST.MF" I'm not sure that removing the generation from the > core Camel is a good thing... > > regards, > > François > > On 30/11/2022 10:44, Claus Ibsen wrote: > > 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/> > >>>> > >>>> > >>>> > > > -- > -- > François > >
