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 <mattr...@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.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 > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>> > >>>>>> > >>>> > >> >
