[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
From:       Jean-Baptiste_Onofré <jb () nanthrax ! net>
Date:       2023-04-12 14:56:09
Message-ID: CAB8EV3T38CmmsdiaGr+_qi5x3qi8zQW8h+jh1fJp6MciyZ1o+A () mail ! gmail ! com
[Download RAW message or body]

Yup. I propose to update the website with a table with different
versions (as we do in Karaf).

Regards
JB

On Wed, Apr 12, 2023 at 4:08 PM Christopher Shannon
<christopher.l.shannon@gmail.com> wrote:
>
> Yep, this seems like a good plan to me. If people want to upgrade to
> Jakarta we will have to require Spring 6 (due to the configuration) which
> requires JDK 17 and I think requiring JDK 17 is reasonable for that version
> as JDK 21 is almost out.
>
> I also want to add that we should upgrade 5.18.x to Jetty 10.x and 5.19.x
> can be Jetty 11/12
>
> On Wed, Apr 12, 2023 at 9:58 AM Matt Pavlovich <mattrpav@gmail.com> wrote:
>
> > Hi Robbie-
> >
> > Yep, I'm back to agreeing with planning to move forward with the two
> > separate versions is the way to go. Chris Shannon has the jetty
> > continuation thing resolved, so that was the only potential snag for back
> > porting.
> >
> > Proposed plan for 5.19.x and to LTS-ify 5.18.x:
> >
> > 5.18.x LTS - JDK 11 + javax broker   + Spring 5 + activemq-client-jakarta
> > 5.19.x        - JDK 17 + jakarta broker + Spring 6
> >
> > Thanks,
> > Matt Pavlovich
> >
> > > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell <robbie.gemmell@gmail.com>
> > wrote:
> > >
> > > I dont really understand what your table of combinations entries say,
> > > and so why Option 1 would be to support "3 (or more)" LTS branches but
> > > the other only 2, so its hard to reply specifically around that.
> > >
> > > Adding -javax modules on a new branch thats primary-jakarta just
> > > doesnt really make sense to me if still supporting an older version
> > > that is actually primary-javax. There may be something obvious I'm
> > > missing, but it seems more likely the people who are not updating APIs
> > > also wont typically want to change all their dependencies in order to
> > > not-update their usage. Theyll just use the older still-supported
> > > primary-javax version. Same way they often use absolutely ancient
> > > versions now already.
> > >
> > > Adding -javax modules to a primary-jakarta version might make sense to
> > > me as a final fallback when otherwise dropping support for all
> > > primary-javax versions, when at that point either the user would have
> > > to either update the API they use or have to rework their dependencies
> > > in order to not update the API. Personally I think it would be simpler
> > > just supporting an existing primary-javax version (or even make a
> > > newer one), or to decide you have actually finally dropped javax
> > > support.
> > >
> > > It would seem easy enough to continue targeting JDK 11 on a new branch
> > > with the client at least, even if needing 17 for the broker, if
> > > wanting to support Jakarta client-only users on JDK11 but taking the
> > > rest up to 17 to bring in Spring 6 ?
> > >
> > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich <mattrpav@gmail.com> wrote:
> > >>
> > >> I agree w/ Chris. I don't think there is harm in keeping a -jakarta
> > client module in 5.18.x. It provides runway for users that lag on JDK
> > adoption and are not using Spring 6.
> > >>
> > >> A couple of technical notes to keep in mind about JDK-Spring-Jakarta
> > coupling *specific* to ActiveMQ 5:
> > >>
> > >> 1. Spring 6 support is needed to address user demand for Spring Boot
> > Starter
> > >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency
> > >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache
> > runtime distribution
> > >> 4. All the other modules can be compiled JDK 11 for users with custom
> > assemblies
> > >>
> > >>
> > >> Based on my previous repackaging and the inflight Jakarta PR work, I
> > think back porting patches b/w Jakarta and non-Jakarta isn't going to
> > require too much heavy lifting.
> > >>
> > >> a.  javax vs jakarta change is isolated to import lines, which should
> > rarely be in the patch diffs
> > >> b.  *-web modules don't change frequently
> > >> c.  jetty-continuation (discontinued) to jakarta.servlet async is the
> > biggest _coding_ change required, and we could do that in a javax-based LTS
> > tree as well
> > >>
> > >>
> > >> Based on the above:
> > >>
> > >> i. I don't see a huge win with for Jakarta broker without Spring 6
> > (since we require spring-web) we'd have jakarta for some modules and javax
> > for Servlet
> > >> Ii. Providing *-javax modules would be a way to simplify managing a
> > Spring 6 + JDK 17 + javax build without a separate branch and set of
> > releases
> > >>
> > >> A table of potential combinations:
> > >>
> > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker)
> > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only)
> > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker)
> > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker)
> > >>
> > >>
> > >> Based on all the above, I think the discussion could be reduced to a
> > couple practical options:
> > >>
> > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not
> > do  -javax modules in 5.19.x
> > >>
> > >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches
> > >>
> > >> Thanks,
> > >> Matt Pavlovich
> > >>
> > >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon <
> > christopher.l.shannon@gmail.com> wrote:
> > >>>
> > >>> All fair points Robbie. I'd still like to leave the jakarta client in
> > >>> 5.18.x just as it gives some compatibility for clients only even if
> > it's
> > >>> going to go away in 5.19.x.
> > >>>
> > >>> So how about the following:
> > >>>
> > >>> 5.18.x - Still javax support with just a jakarta client. This can be a
> > long
> > >>> term LTS, at least for bug fixes. We will probably want to backport
> > some
> > >>> features too for a while.
> > >>> 5.19.x - Becomes Jakarta API only. Still support JDK 11 and by default
> > >>> would still have Spring 5.3.x but will be of course compatible with
> > Spring
> > >>> 6 and Spring boot 3, etc.
> > >>> 5.20.x - By this release JDK 21 LTS should be out so I say we bump to
> > >>> require JDK 17 (we can bump other things like Jetty/Spring 6 at the
> > same
> > >>> time)
> > >>>
> > >>> We could also bump to JDK 17 for 5.19.x if it's too much of a pain to
> > >>> support JDK 11 but I think it should be doable.
> > >>>
> > >>> In terms of which features are actually supported/implemented for the
> > new
> > >>> APIs is another discussion. Obviously each release would add more. I
> > >>> haven't had time yet to look more into shared subscriptions but likely
> > we'd
> > >>> leverage the existing composite destination/virtual topics that exist
> > in
> > >>> the broker to support it but I'm not sure if it would be client/broker
> > side
> > >>> etc.
> > >>>
> > >>> Thoughts?
> > >>>
> > >>> On Wed, Apr 5, 2023 at 8:59 AM Robbie Gemmell <
> > robbie.gemmell@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> No extra -javax client module module. People wanting Jakarta client
> > >>>> support would use 5.19.x. People wanting javax client support would
> > >>>> just use 5.18.x as they would today. I'd even consider removing the
> > >>>> extra 5.18.x -jakarta client module personally (could be super nice
> > >>>> and add a maven relocation for it to the initial 5.19.0 release to
> > >>>> point them back to the normal client module, though as its not in
> > >>>> widespread use and doesnt even work yet, a need for that is unclear).
> > >>>>
> > >>>> I dont particularly care what version it is called. However I will say
> > >>>> I dont think it would particularly be any more unusual to call it
> > >>>> 5.19.x vs 5.18.x than it was with many other more impactful changes
> > >>>> that have been made in 5.n -> 5.n+1 releases in the past ~15 years.
> > >>>> While awkward in some ways, its actually probably a more trivial
> > >>>> change in the end compared to many prior changes in that time. Folks
> > >>>> that want to update their stuff to the new API make a trivial version
> > >>>> number update. Folks that dont, will not. Actual implementation
> > >>>> behaviours would remain the same, unlike with many 5.x bumps. Could
> > >>>> jump it to 5.30.x to separate and align with supporting Jakarta
> > >>>> Messaging 3 ;)
> > >>>>
> > >>>> On Wed, 5 Apr 2023 at 12:31, Christopher Shannon
> > >>>> <christopher.l.shannon@gmail.com> wrote:
> > >>>>>
> > >>>>> So if 5.19.x just becomes Jakarta API (and not new modules) then I
> > assume
> > >>>>> we would just have an extra client module for javax? Basically the
> > >>>> inverse
> > >>>>> of 5.18.x (where we primarily use javax and have a jakarta client
> > module)
> > >>>>>
> > >>>>> I guess that will be fine but it is pretty unusual to make such a
> > large
> > >>>>> breaking API change without bumping major versions. I would argue
> > that
> > >>>>> should really be a 6.0 release but everyone knows how that
> > conversation
> > >>>>> would go with versioning so I guess we are stuck on 5.19.x
> > >>>>>
> > >>>>> On Wed, Apr 5, 2023 at 5:17 AM Jean-Baptiste Onofré <jb@nanthrax.net
> > >
> > >>>> wrote:
> > >>>>>
> > >>>>>> Hi
> > >>>>>>
> > >>>>>> Agree, it was basically my proposal in a previous email: I would not
> > >>>>>> use different artifacts, just change to the major version (5.19.x).
> > If
> > >>>>>> people still want to use javax.jms, then he can use 5.18.x (that we
> > >>>>>> can "flag" as LTS).
> > >>>>>>
> > >>>>>> Regards
> > >>>>>> JB
> > >>>>>>
> > >>>>>> On Mon, Apr 3, 2023 at 10:20 PM Christopher Shannon
> > >>>>>> <christopher.l.shannon@gmail.com> wrote:
> > >>>>>>>
> > >>>>>>> Based on what Robbie is saying we wouldn't have any new modules at
> > >>>> all. I
> > >>>>>>> would just be different versions, one version is javax and one is
> > >>>> jakarta
> > >>>>>>> which is what Qpid JMS did. (Jakarta is 2.x and javax is 1.x)
> > >>>>>>>
> > >>>>>>> On Mon, Apr 3, 2023 at 1:32 PM Matt Pavlovich <mattrpav@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Yeah, I agree w/ Robbie. I think this makes the most sense
> > >>>> considering
> > >>>>>>>> Jakarta namespace will be default going forward for all new apps.
> > >>>>>>>>
> > >>>>>>>> When migrating existing apps, it'll most likely be all javax deps
> > >>>> to
> > >>>>>>>> jakarta, so that makes for a nice clean version-number-only
> > change.
> > >>>>>>>>
> > >>>>>>>> For example, 'spring-web' v6 w/ Jakarta artifactId is still just
> > >>>>>>>> 'spring-web'.
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>> Matt Pavlovich
> > >>>>>>>>
> > >>>>>>>>> On Apr 3, 2023, at 11:53 AM, Robbie Gemmell <
> > >>>>>> robbie.gemmell@gmail.com>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Though that was over 2 years ago, and at the time having the
> > >>>> separate
> > >>>>>>>>> -jakarta modules was probably the most obvious way to go given
> > >>>> very
> > >>>>>>>>> few were likely going to actually use those new modules at the
> > >>>> time,
> > >>>>>>>>> with the prior/existing stuff clearly still being the focus for
> > >>>>>> almost
> > >>>>>>>>> everyone, and thus making it harder to justify alternatives like
> > >>>> e.g
> > >>>>>>>>> maintaining separate branches for both spec impls back then. Now,
> > >>>>>>>>> usage will probably be a fair bit more bifurcated from newer
> > >>>>>> framework
> > >>>>>>>>> versions having updated to the new specs and various users either
> > >>>>>>>>> updating to use them or else just using them for any new dev
> > >>>> stuff,
> > >>>>>>>>> but still many users that dont update their stuff.
> > >>>>>>>>>
> > >>>>>>>>> More recently, I'd say most projects I see making similar
> > >>>> transitions
> > >>>>>>>>> are using their existing modules for the new specs just with a
> > >>>> new
> > >>>>>>>>> version, and if they want to support the old specs then doing so
> > >>>> by
> > >>>>>>>>> maintaining a previous version stream, having each stream be
> > >>>> targeted
> > >>>>>>>>> to one spec and 'fully tested'. That is what I chose to do for
> > >>>>>>>>> qpid-jms last year, and what I would currently choose if deciding
> > >>>>>>>>> again just now.
> > >>>>>>>>>
> > >>>>>>>>> On Mon, 3 Apr 2023 at 15:04, Justin Bertram <jbertram@apache.org
> > >>>>>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> For what it's worth Artemis created new coordinates for the
> > >>>> Jakarta
> > >>>>>>>> modules
> > >>>>>>>>>> and left the existing ones the same. Folks who are migrating are
> > >>>>>>>> actually
> > >>>>>>>>>> touching their applications in most (if not all) circumstances.
> > >>>> It
> > >>>>>> makes
> > >>>>>>>>>> sense to require them to change the GAV.
> > >>>>>>>>>>
> > >>>>>>>>>> In my opinion folks who just want to upgrade their existing
> > >>>> (i.e.
> > >>>>>> javax)
> > >>>>>>>>>> systems shouldn't have to change anything but the version
> > >>>> number.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Justin
> > >>>>>>>>>>
> > >>>>>>>>>> On Mon, Apr 3, 2023 at 6:20 AM Christopher Shannon <
> > >>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Matt,
> > >>>>>>>>>>>
> > >>>>>>>>>>> My main concern with that is with new -javax modules everyone
> > >>>> has
> > >>>>>> to
> > >>>>>>>> change
> > >>>>>>>>>>> to new GAV and then they have to change GAV again if we drop
> > >>>> the
> > >>>>>> javax.
> > >>>>>>>>>>>
> > >>>>>>>>>>> But this might just be the way it is and users will have to
> > >>>> make
> > >>>>>>>> changes to
> > >>>>>>>>>>> their build that is more than just a version change.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Fri, Mar 31, 2023 at 2:17 PM Matt Pavlovich <
> > >>>> mattrpav@gmail.com
> > >>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi Christopher-
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> After taking yesterday to get most of the way through the
> > >>>> jakarta
> > >>>>>>>>>>>> conversion, I think we can go without the version gap.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think option #1 gives us the best approach. After a period
> > >>>> of
> > >>>>>> time
> > >>>>>>>> we
> > >>>>>>>>>>>> can just ‘drop' the javax modules and not have to cause users
> > >>>> to
> > >>>>>>>> change
> > >>>>>>>>>>>> anything else back to have clean GAV coordinates.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>> Matt Pavlovich
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mar 30, 2023, at 3:49 PM, Christopher Shannon <
> > >>>>>>>>>>>> christopher.l.shannon@gmail.com> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks Matt for bringing this up. We definitely need to
> > >>>> figure
> > >>>>>> out a
> > >>>>>>>>>>> path
> > >>>>>>>>>>>>> forward as there is a lot of confusion about this still and
> > >>>>>> users are
> > >>>>>>>>>>>>> getting bit by it when trying to upgrade to Spring 6 and
> > >>>> Spring
> > >>>>>> boot
> > >>>>>>>> 3.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Ultimately I think we will need to support both javax and
> > >>>>>> jakarta for
> > >>>>>>>>>>>> quite
> > >>>>>>>>>>>>> a while because while some users are going to want to use
> > >>>> newer
> > >>>>>>>>>>>>> technologies that require jakarta (like Spring 6 ) others
> > >>>> will be
> > >>>>>>>> happy
> > >>>>>>>>>>>> to
> > >>>>>>>>>>>>> stay on the old APIs for a while. So the question becomes
> > >>>> what
> > >>>>>> is the
> > >>>>>>>>>>>> best
> > >>>>>>>>>>>>> way to do that. I do think that some sort of repackaging is
> > >>>>>> probably
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>> way to go like we did for the client but to do it for all the
> > >>>>>>>> relevant
> > >>>>>>>>>>>>> modules and release both.  We can keep 5.18.x as a long
> > >>>> running
> > >>>>>>>> branch
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>> back port but it would still be nice if the latest worked for
> > >>>>>> either
> > >>>>>>>>>>> API
> > >>>>>>>>>>>>> (ie 5.19.x). I'm thinking more about it and we can probably
> > >>>> just
> > >>>>>> do
> > >>>>>>>> it
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> 5.19.x and don't need a gap version.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I can see 3 ways to release both:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> *1) Create duplicate modules (like we did with  the client
> > >>>> for
> > >>>>>>>> jakarta
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> 5.18.x). *This works but means a lot of extra modules to
> > >>>>>> maintain but
> > >>>>>>>>>>> is
> > >>>>>>>>>>>>> probably the most flexible as you can do custom things in
> > >>>> each
> > >>>>>> module
> > >>>>>>>>>>>>> easily. We could create BOM files for people to use to
> > >>>> import the
> > >>>>>>>> right
> > >>>>>>>>>>>>> things to keep things consistent.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker-javax</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0</version>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker-jakarta</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0</version>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> *2) Don't add new modules, just keep the same ones but have
> > >>>> each
> > >>>>>>>> module
> > >>>>>>>>>>>>> build 2 jars using classifiers. *We could just have each
> > >>>> module
> > >>>>>>>> build 2
> > >>>>>>>>>>>>> jars and repackage.  My primary concern about sharing the
> > >>>> same
> > >>>>>> module
> > >>>>>>>>>>> for
> > >>>>>>>>>>>>> both APIs would be if the Jakarta API becomes different
> > >>>> enough
> > >>>>>> that
> > >>>>>>>>>>>>> repackaging doesn't work due to changes between it and javax
> > >>>> but
> > >>>>>> we
> > >>>>>>>>>>> might
> > >>>>>>>>>>>>> still be able to make this work by having each classified jar
> > >>>>>> only
> > >>>>>>>> pull
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>>> certain things.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0</version>
> > >>>>>>>>>>>>> <classifier>javax</classifier>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0</version>
> > >>>>>>>>>>>>> <classifier>jakarta</classifier>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> *3) Just build with a different version (this is what Guava
> > >>>> does
> > >>>>>> with
> > >>>>>>>>>>> jre
> > >>>>>>>>>>>>> and android). *This is probably the most annoying as you
> > >>>> would
> > >>>>>> need
> > >>>>>>>> to
> > >>>>>>>>>>>>> re-package and then I guess use a different version when
> > >>>>>> building.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0-javax</version>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> <dependency>
> > >>>>>>>>>>>>> <groupId>org.apache.activemq</groupId>
> > >>>>>>>>>>>>> <artifactId>activemq-broker</artifactId>
> > >>>>>>>>>>>>> <version>5.19.0-jakarta</version>
> > >>>>>>>>>>>>> </dependency>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik <
> > >>>>>> Endre@stolsvik.com>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> From a lurker position here, I just wanted to point out that
> > >>>>>> Jetty
> > >>>>>>>> is
> > >>>>>>>>>>>>>> evidently making a version 12 which will support both
> > >>>> javax. and
> > >>>>>>>>>>>> jakarta.
> > >>>>>>>>>>>>>> in the same server.
> > >>>>>>>>>>>>>> https://www.eclipse.org/jetty/download.php
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Kind regards,
> > >>>>>>>>>>>>>> Endre
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Mar 30, 2023 at 9:54 PM Jean-Baptiste Onofré <
> > >>>>>>>> jb@nanthrax.net
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I agree with the plan but why not keep 5.19.0-SNAPSHOT on
> > >>>> main
> > >>>>>> ?
> > >>>>>>>>>>>>>>> We have the activemq-5.18.x branch already that could be
> > >>>> LTS
> > >>>>>> where
> > >>>>>>>> we
> > >>>>>>>>>>>>>>> keep javax namespace.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Regards
> > >>>>>>>>>>>>>>> JB
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Thu, Mar 30, 2023 at 7:54 PM Matt Pavlovich <
> > >>>>>> mattrpav@gmail.com
> > >>>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Hello All-
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I started building a jakarta-based broker for ActiveMQ
> > >>>> 5.x and
> > >>>>>>>>>>> propose
> > >>>>>>>>>>>>>>> the following steps to manage the change.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Background:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Jakarta support in ActiveMQ 5.x is going to pull in JDK
> > >>>> 17,
> > >>>>>> Spring
> > >>>>>>>>>>> 6,
> > >>>>>>>>>>>>>>> Jakarta EE 9, Servlet 5.x, and Jetty 11. That is quite a
> > >>>> bit of
> > >>>>>>>>>>> change,
> > >>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> I suggest we leave a ‘gap version' in case we need to make
> > >>>> any
> > >>>>>>>>>>>>>> incremental
> > >>>>>>>>>>>>>>> updates to 5.18.x series along the way.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 1. Rename main to 5.20.0-SNAPSHOT
> > >>>>>>>>>>>>>>>> 2. Commit broker-related jakarta, servlet, jetty, spring,
> > >>>> etc
> > >>>>>>>>>>> changes
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>> main
> > >>>>>>>>>>>>>>>> 3. Create new ‘-javax' broker modules to support a
> > >>>>>>>>>>>>>>> apache-activemq-javax-5.20.0-bin.tar.gz package using
> > >>>>>> re-packaging
> > >>>>>>>> of
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>>>> jakarta artifacts.
> > >>>>>>>>>>>>>>>> 4. Leave 5.19.x as a ‘gap version' in case it is needed
> > >>>> for
> > >>>>>> 5.18.x
> > >>>>>>>>>>>>>>> changes
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>> Matt Pavlovich
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> >
> >
[prev in list] [next in list] [prev in thread] [next in thread]