Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
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 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 > 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 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 > 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
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
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 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 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 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. > > > org.apache.activemq > activemq-broker-javax > 5.19.0 > > > > org.apache.activemq > activemq-broker-jakarta > 5.19.0 > > > *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
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
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 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 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. > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker-javax > > > > 5.19.0 > > > > > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker-jakarta > > > > 5.19.0 > > > > > > > > > > > > *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. > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker > > > > 5.19.0 > > > > javax > > > > > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker >
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
Thanks for the input Justin, that makes sense to not require existing users to change GAV (at least not yet until we drop javax). I think we are heading down that path with new modules for jakarta based on what Matt started doing so that is in line with what Artemis did and it would be good to be consistent. On Mon, Apr 3, 2023 at 10:04 AM Justin Bertram 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 > 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. > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker-javax > > > > 5.19.0 > > > > > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker-jakarta > > > > 5.19.0 > > > > > > > > > > > > *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. > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker > > > > 5.19.0 > > > > javax > > > > > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker > > > > 5.19.0 > > > > jakarta > > > > > > > > > > > > *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. > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker > > > > 5.19.0-javax > > > > > > > > > > > > > > > > org.apache.activemq > > > > activemq-broker > > > > 5.19.0-jakarta > > > > > > > > > > > > > > > > On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik > > > 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 > > >
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
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 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. > > > > > > > > > org.apache.activemq > > > activemq-broker-javax > > > 5.19.0 > > > > > > > > > > > > org.apache.activemq > > > activemq-broker-jakarta > > > 5.19.0 > > > > > > > > > *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. > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0 > > > javax > > > > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0 > > > jakarta > > > > > > > > > *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. > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0-javax > > > > > > > > > > > > org.apache.activemq > > > activemq-broker > > > 5.19.0-jakarta > > > > > > > > > > > > On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik > > 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é > > > >> 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 > > >> wrote: > > > > Hello All- > > > > I started building a jakarta-based broker for ActiveMQ 5.x and > propose
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
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 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. > > > > > > org.apache.activemq > > activemq-broker-javax > > 5.19.0 > > > > > > > > org.apache.activemq > > activemq-broker-jakarta > > 5.19.0 > > > > > > *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. > > > > > > org.apache.activemq > > activemq-broker > > 5.19.0 > > javax > > > > > > > > org.apache.activemq > > activemq-broker > > 5.19.0 > > jakarta > > > > > > *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. > > > > > > org.apache.activemq > > activemq-broker > > 5.19.0-javax > > > > > > > > org.apache.activemq > > activemq-broker > > 5.19.0-jakarta > > > > > > > > On Thu, Mar 30, 2023 at 4:06 PM Endre Stølsvik > 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é > >> 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 > >> 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,
