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 > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >>>> > > > >>> > > > > > > >
