Hi all, I updated ActiveMQ main branch to 6.0.0-SNAPSHOT version (including schemas update, etc).
I will now move forward on the related changes. Thanks all, Regards JB On Fri, Sep 15, 2023 at 3:27 PM Matt Pavlovich <mattr...@gmail.com> wrote: > > 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. > >>>> >
