I had assumed you would use Spring 6 on the Jakarta branch, though still targeting 11 with the client etc, but requiring 17 for build and using those modules with spring 6 requirement (im not clear which bits those are...but sounds like its more widespread than I thought it was).
On Wed, 5 Apr 2023 at 15:21, Christopher Shannon <christopher.l.shan...@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.gemm...@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.shan...@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é <j...@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.shan...@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 <mattr...@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.gemm...@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 <jbert...@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.shan...@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 < > > mattr...@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.shan...@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 < > > > > en...@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é < > > > > > > j...@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 < > > > > mattr...@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 > > > > > > >>>>>>> > > > > > > >>>>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > > > > >
