Sounds good, makes sense. Thanks, Matt
> On Sep 14, 2023, at 11:29 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > I agree and that's ActiveMQ 5.x stays with javax.jms and ActiveMQ 6.x > changes to jakarta.jms. > > So we are fully aligned and it shows that ActiveMQ 6.x is cleaner. > If users want to still use javax.jms then they will use ActiveMQ 5.x, > if they want to use jakarta.jms, they will use ActiveMQ 6.x. > > It's clear like this imho. > > Regards > JB > > On Thu, Sep 14, 2023 at 5:57 PM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: >> >> In ActiveMQ 5.x the broker itself uses all the JMS messages etc on the >> broker side and also uses the same classes as the client for various >> stuff, so it has to be fully converted so you can use broker + client >> in the same application/test without resorting to containers etc. The >> 5.x javax broker and jakarta client simply cant be used in the same >> classloader. >> >> 5.x also uses Spring for various bits and a jakarta conversion means >> using Spring 6, which requires Java 17 as you noted (related aside: 17 >> wont be the current LTS as of next week, with Java 21 >> releasing...which has effectively been finalised for a month now since >> there was no RC2). >> >> So essentially it is not as simple to have 'javax modules' and >> 'jakarta modules' in the same tree for 5.x like it was for the Artemis >> codebase back in February 2021 when that was originally done. That >> made a lot of sense at the time since noone was really using them back >> then. Going forward, I do think having 2 versions is actually >> preferable, and thats what I choose to do elsewhere, and what I'd say >> most (but, not all) projects are doing at this later point. It does >> mean backporting things if supporting both, but also means a simpler >> build and a nicer testing situation etc, and slightly less user change >> (just updating the version, not knowing new -jakarta dep exists and >> also updating version). >> >> On Thu, 14 Sept 2023 at 16:16, Justin Bertram <jbert...@apache.org> wrote: >>> >>> I don't have a deep familiarity with the internals here so some of the >>> fundamentals behind the changes aren't clear to me. >>> >>> Is the move to JDK 17 prompted by the fact that Spring 6 requires it? How >>> tightly is "Classic" coupled with Spring? >>> >>> Is the coupling with Spring also why the code-base is being moved >>> whole-sale to Jakarta? It's been a little while now, but when Artemis >>> implemented Jakarta support back in early 2021 I don't recall any >>> disruption for current users and no major version change was needed. Both >>> Java EE and Jakarta EE implementations are based on the same code-base. Is >>> something like that not possible here? It would simplify maintenance a lot >>> since fixes/features wouldn't have to be back-ported. >>> >>> >>> Justin >>> >>> On Mon, Sep 11, 2023 at 4:22 PM Christopher Shannon < >>> christopher.l.shan...@gmail.com> wrote: >>> >>>> First, I realize that this thread is likely to cause a fight based on past >>>> history and probably not go anywhere, but with the work being done >>>> with Jakarta for AMQ 5.x I think it's time to at least bring up the >>>> ActiveMQ 6.0 discussion. >>>> >>>> With all the breaking changes currently targeted for version 5.19.x, such >>>> as the Jakarta switch from javax, requiring JDK 17, major Spring and Jetty >>>> upgrades and now potentially major OSGi changes, it makes zero sense to me >>>> to have this next AMQ version as version 5.19.0 as it's completely >>>> incompatible with the previous version 5.18.x. Users are likely going to be >>>> in for a rude awakening when trying to upgrade and will be quite confused >>>> as to why so much is different. >>>> >>>> The Jakarta changes should really be a major version upgrade so that it's >>>> much more clear to users that it's very different from the previous >>>> version. Another major benefit of going with version 6.0 is that it frees >>>> up the previous javax releases to continue on with 5.19 or 5.20 because we >>>> will likely need to support the older javax releases for quite a while. >>>> >>>> Also, from my point of view it seems pretty clear that the original goal >>>> for Artemis to become AMQ 6.0.0 is never going to happen. Artemis has had >>>> its own branding and versioning for several years now and will likely >>>> continue that way and not change so I don't really see that as a reason to >>>> not bump AMQ 5.x to 6.x with all the major breaking changes. >>>> >>>> Anyways, I figure there won't be much agreement here but thought I should >>>> at least throw it out there before we go and release 5.19.x with such major >>>> breaking changes. >>>>
